Jitsi behind nginx reverse proxy - 502 bad gateway

Hello,
jitsi works fine for me behind a natting router, when I forward tcp 80, 443 and udp 10000 directly to the machine running jitsi. As I have only one external ip and several machines, I need to use a reverse proxy. Unfortunately I always get a 502 error bad gateway when trying to access jitsi via that proxy. On the jitsi machine I see the following nginx logs, but I am unsure about their meanings.

2020/04/19 10:36:49 [error] 715#715: *5 recv() failed (104: Connection reset by peer) while proxying and reading from upstream, client: 192.168.7.44, server: 0.0.0.0:443, upstream: “127.0.0.1:4445”, bytes from/to client:563/172, bytes from/to upstream:172/949
192.168.7.44 is the machine running the nginx reverse proxy.

Any idea?
Thanks Norbert

If your use case is simple - only ONE jitsi server - using a nginx proxy server should be straightforward if you forward UDP port 10000 to the jitsi server, then just reverse proxy to the jitsi system. I have disabled TLS on the jitsi system so I forward https to nginx on http in the easiest way (… server_name meet.myurl.mytld; …proxy_pass http://jitsi:80)
It will not be so simple if you have clients behind a corporate firewall but if it was the case your current setup would not work anyway.

Port 10000/udp is forwarded to the jitsi server. 443 to the nginx rev. proxy and there I proxy to the jitsi server:

server {
listen 192.168.7.44:443;
server_name meet.mydom.de;
location / {
proxy_pass https://192.168.7.39:443;
}
}

This config results in the bad gateway error.
The jitsi server is unchanged and when I forward 443 to the jitsi server, everything works as expected.
So do I have to modify something on the jitsi server too, when it is reached via nginx reverse proxy?

I’m no great expert in nginx lore, I’d expect such setup to fail because nginx pxoxy would address a https server through an IP address and not it’s internet address (that is the name on the certificate), although I admit again not knowing much about nginx proxying.
Anyway, I have disabled encryption on the nginx jitsi server (not the proxy, the one that comes with jitsi itself) so that it can be addressed on port 80 like any old http server, I’m managing encryption/certificates at the proxy level and it works.

Thanks, that sounds reasonable.
I still can’t overlook the complex configuration of all the jitsi components. Could you please briefly summarize, which changes are necessary for disabling encryption on the jtsi server without destroying functionality?

Not if you use turnserver, I have decided to not look at this feature at the moment.
If you don’t have it installed, it’s pretty straightforward nginx config, it’s mostly removing everything ssl related

--- meet.example.com.conf.ori	2020-03-31 14:37:08.243580585 +0200
+++ meet.example.com.conf	2020-04-04 23:19:46.704388196 +0200
@@ -2,34 +2,10 @@
 
 server {
     listen 80;
-    listen [::]:80;
     server_name meet.example.com;
 
-    location ^~ /.well-known/acme-challenge/ {
-       default_type "text/plain";
-       root         /usr/share/jitsi-meet;
-    }
-    location = /.well-known/acme-challenge/ {
-       return 404;
-    }
-    location / {
-       return 301 https://$host$request_uri;
-    }
-}
-server {
-    listen 443 ssl;
-    listen [::]:443 ssl;
-    server_name meet.example.com;
-
-    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
-    ssl_prefer_server_ciphers on;
-    ssl_ciphers "EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA256:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EDH+aRSA+AESGCM:EDH+aRSA+SHA256:EDH+aRSA:EECDH:!aNULL:!eNULL:!MEDIUM:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4:!SEED";
-
     add_header Strict-Transport-Security "max-age=31536000";
 
-    ssl_certificate /etc/ssl/meet.example.com.crt;
-    ssl_certificate_key /etc/ssl/meet.example.com.key;
-
     root /usr/share/jitsi-meet;
 
     # ssi on with javascript for multidomain variables in config.js