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!
              
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:

      github.com
    
jitsi/jitsi-meet/blob/master/doc/debian/jitsi-meet/jitsi-meet.conf#L16
upstream web {
    server 127.0.0.1:4444;
upstream turn {
    server 127.0.0.1:4445;
# since 1.13.10
map $ssl_preread_alpn_protocols $upstream {
    ~\bh2\b         web;
    ~\bhttp/1\.     web;
    default         turn;
server {
    listen 443;
    listen [::]:443;
    # since 1.11.5
    ssl_preread on;
    proxy_pass $upstream;
              
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
              
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.
              
I’ve created a PR with some of these changes to the main developer document for jitsi-meet.
      github.com/jitsi/jitsi-meet
              
@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
              
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.