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!

3 Likes

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

2 Likes

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.

3 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

@damencho
Hey there! First, thanks for being so active on this forum - many of your answers have helped me get off the ground.

I have a self-hosted jitsi server on digital ocean, and things look good for almost all clients. However, sometimes, I’m getting errors like

2020/08/13 08:11:19 [error] 3250#3250: *796 recv() failed (104: Connection reset by peer) while proxying and reading from upstream, client: 65.96.73.175, server: 0.0.0.0:443, upstream: "127.0.0.1:5349", bytes from/to client:759/3624, bytes from/to upstream:3624/1276
2020/08/13 08:15:10 [error] 3250#3250: *1229 recv() failed (104: Connection reset by peer) while proxying and reading from upstream, client: 152.22.34.25, server: 0.0.0.0:443, upstream: "127.0.0.1:5349", bytes from/to client:3146/1044, bytes from/to upstream:1044/3700

In my nginx error log. I’m wondering, if I make the change detailed above to stop routing traffic to my turn server (in production), am I preventing access for some users? If so, is there a better way to solve this?

So to solve this you need to move turn to another machine or to attach a second public address and make turn listen there and setup a dns (can be just a subdomain) and certs for that ip and use that, basically do not use the multiplexing of traffic and separate nginx and turnserver under different domains …
Turn will be used in case in p2p mode 2 participants cannot establish a direct connection and someone using the bridge is in restricted network where udp is disabled and only ssl on port 443 is allowed.

Another option is to move turn on standard ports not 443, this will prevent only those users which have the “restricted network where udp is disabled and only ssl on port 443 is allowed” and those with just udp blocked it will work

Thanks for the response! I think this makes sense, but I’m not quite sure how to implement it.
Say I have jitsi.example.com and jitsi2.example.com, with the first one intended for nginx and the second for turn:

I imagine I should change /etc/nginx/modules-enabled/60-jitsi-meet.conf to set default web. Then, what do I need to change in /etc/turnserver.conf (or elsewhere) to make the turn server listen separately?

Finally, I’m using the iframe external api - where would I put the jitsi2 address for turn?

I do want to make sure everyone - or as many people as possible - can use this. Many of my customers will be behind corporate or school firewalls

The address jitsi2 must be configure in your prosody config. Clients are querying for that the xmpp service.

I see. so all I have to do is replace all instances of jitsi.domain.com in /etc/prosody/conf.d/jitsi.domain.com.cfg.lua with jisti2.domain.com and restart prosody?

How would I go about testing that my turn server works correctly - these failures have only been reproducible by customer devices so far.

Hello @sudssm,

The posts on Coturn chronicles may be helpful

Thanks! That plus Can't get jitsi-meet to work with TURN (solved) helped me a lot. Things are working now; I really appreciate it!