Running dev server against a self hosted instance does not work - connection reset errors

I have a public Jitsi server running - call it meet.example.com. This is up to date unstable.

When doing local dev per the jitsi-meet development guide, I’m attempting to use the WEBPACK_DEV_SERVER_PROXY_TARGET environment variable to point the locahost install at my instance. This does not work, although my local instance works properly against alpha.jitsi.net with no problems.

When I access https://localhost:8080 in my browser (Chrome), I get the following:

Error occured while trying to proxy to: localhost:8080/

In the ‘make dev’ terminal, I have the following:

[HPM] Error occurred while trying to proxy request / from localhost:8080 to https://meet.example.com (ECONNRESET) (https://nodejs.org/api/errors.html#errors_common_system_errors)

And, on the server, in the nginx error logs, I see:

2020/04/12 23:36:56 [error] 7753#7753: *111 recv() failed (104: Connection reset by peer) while proxying and reading from upstream, client: [my IP address], server: 0.0.0.0:443, upstream: "127.0.0.1:4445", bytes from/to client:563/3608, bytes from/to upstream:3608/932

What am I doing wrong? I’m happy to make any config changes required, but it would be nice to be able to develop against my own instance for performance reasons.

Thanks!

1 Like

Exactly the same issue. @Syonyk

Running on AWS EC2 micro instance with a letsencrypt cert. Wondering if it could be related to the certificate.
In addition to the errors you’ve seen, I’ve also found the following errors:

Apr 13 10:55:47 ip-172-31-14-116 turnserver: 101324: IPv4. tcp or tls connected to: 127.0.0.1:56878

Apr 13 10:55:48 ip-172-31-14-116 turnserver: 101325: HTTPS connection has been disabled due Vulnerability in the Web interface !!!

Apr 13 10:55:48 ip-172-31-14-116 turnserver: 101325: session 001000000000000196: client socket to be closed in client handler: ss=0x7f3b50020be0

Apr 13 10:55:48 ip-172-31-14-116 turnserver: 101325: session 001000000000000196: closed (2nd stage), user <> realm <myactualdomainname.co> origin <>, local 127.0.0.1:4445, remote 127.0.0.1:56878, reason: general

Apr 13 10:55:48 ip-172-31-14-116 turnserver: 101325: session 001000000000000196: SSL shutdown received, socket to be closed (local 127.0.0.1:4445, remote 127.0.0.1:56878)

Apr 13 10:55:49 ip-172-31-14-116 turnserver: 101326: IPv4. tcp or tls connected to: 127.0.0.1:56880

Apr 13 10:55:50 ip-172-31-14-116 turnserver: 101327: HTTPS connection has been disabled due Vulnerability in the Web interface !!!

Apr 13 10:55:50 ip-172-31-14-116 turnserver: 101327: session 000000000000000179: client socket to be closed in client handler: ss=0x7f3b48014080

Apr 13 10:55:50 ip-172-31-14-116 turnserver: 101327: session 000000000000000179: closed (2nd stage), user <> realm <myactualdomainname.co> origin <>, local 127.0.0.1:4445, remote 127.0.0.1:56880, reason: general

Apr 13 10:55:50 ip-172-31-14-116 turnserver: 101327: session 000000000000000179: SSL shutdown received, socket to be closed (local 127.0.0.1:4445, remote 127.0.0.1:56880)

I suspect this is due to the fact the webpack dev server does not use http2 and so the requests are routed to the turnserver.
A quick workaround is to change this line:


To be default web; and will start working, restart nginx of course after the change. The file is /etc/nginx/modules-enabled/60-jitsi-meet.conf

1 Like

Brilliant @damencho that fixed it for me.

So I guess in staging environment - I should use this quick fix, but in LIVE, it’s ideal for turn to be enabled - otherwise performance will be lower?

Thanks!
Steve

turnserver is a fallback for networks with udp denied.

Thanks, I’ll try this tomorrow! Was out riding with the kid tonight.

Is the meet.jit.si/alpha.jitsi.net configuration documented anywhere? Given that webpack works fine against alpha.jitsi.net, I’d guess it has a different configuration than the documented nginx configs.

You cannot use meet.jit.si as it uses cdn and will get sources from different location and will skip the proxy.

Sure, that makes sense.

I guess my question can be phrased as, “What are the differences in configuration files between the defaults (which do not work for this use case) and alpha.jitsi.net (which does work as a dev instance)?”

Its just alpha does not have the nginx multiplexing turn and web traffic enabled.

Switching the default from “turn” to “web” fixed the first issue, but I’ve also had to add a few headers to my public instance to get around CORS errors in Chrome.

I had to add the Access-Control-Allow headers in the /http-bind section of my nginx configs as well.

    # BOSH
    location = /http-bind {
        proxy_pass      http://localhost:5280/http-bind;
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_set_header Host $http_host;
        add_header 'Access-Control-Allow-Headers' 'Content-Type';
        add_header 'Access-Control-Allow-Origin' 'https://localhost:8080';
    }

I will update the jitsi-meet developer documents with these notes as well.

2 Likes

I’ve created a PR with some of these changes to the main developer document for jitsi-meet.

1 Like

this is to be done at dev machine, i applied the same settings but still getting the same error.

It worked, thanks @damencho earlier i was editing this file on my local server my bad.

these changes should be done on remote server where you have setup jitsi meet server.

1 Like