Can Jitsi Meet be used behind an Nginx reverse proxy without breaking the Android app?

Is there a known configuration recipe that will prevent the Android app from throwing a sulking fit if it is asked to connect to a Meet server that is behind an Nginx reverse proxy?

I can get the Android app to talk to a Meet server that is directly exposed to the Internet, but if I put the same server behind Nginx – using the same certificates for TLS termination – the app immediately claims (lies) that it has been disconnected. Access via browsers, including browsers on Android, continues to work correctly.

Do I need to enable some combination of insecure TLS features (such as TLS 1.0) to placate the app’s idiosyncrasies, or is there a more fundamental problem with the app, such as a lack of SNI support?

This is the relevant server block of my Nginx config:

server {
    server_name  jitsi.EXAMPLE.COM;

    location / {
        ssi on;
        proxy_pass https://localhost:8443/;
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_set_header Host $http_host;
    }
    # BOSH
    location /http-bind {
        proxy_pass http://localhost:8443/http-bind;
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_set_header Host $http_host;
    }
    location /xmpp-websocket {
        proxy_pass https://localhost:8443;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
    location /colibri-ws {
        proxy_pass https://localhost:8443;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }

    listen [::]:443 ssl;
    listen 443 ssl;
    
    ssl_session_cache shared:le_nginx_SSL:10m;
    ssl_session_timeout 1440m;
    ssl_session_tickets off;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers off;

    ssl_ciphers "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384";
    
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

    ssl_certificate /jitsi/.jitsi-meet-cfg/web/acme-certs/jitsi.EXAMPLE.COM/fullchain.pem;
    ssl_certificate_key /jitsi/.jitsi-meet-cfg/web/acme-certs/jitsi.EXAMPLE.COM/key.pem;
}

This configuration, and its certificates, scores an A+ rating from SSL Labs and whatsmychaincert.com reports a correct certificate chain. This is unsurprising as everything works, using the same certificates, without nginx.

Update: use of Nginx debug logging reveals no TLS issues. Rather, the Android client attempts to POST to the BOSH endpoint but the Jitsi Meet server rejects the request with HTTP 400.

Android client request as seen by Nginx:

2021/09/16 06:52:38 [debug] 57499#57499: *4 http request line: "POST /http-bind?room=cpwk HTTP/1.1"
2021/09/16 06:52:38 [debug] 57499#57499: *4 http uri: "/http-bind"
2021/09/16 06:52:38 [debug] 57499#57499: *4 http args: "room=cpwk"
2021/09/16 06:52:38 [debug] 57499#57499: *4 http exten: ""
2021/09/16 06:52:38 [debug] 57499#57499: *4 http process request header line
2021/09/16 06:52:38 [debug] 57499#57499: *4 http header: "Content-Type: text/xml; charset=utf-8"
2021/09/16 06:52:38 [debug] 57499#57499: *4 http header: "Content-Length: 214"
2021/09/16 06:52:38 [debug] 57499#57499: *4 http header: "Host: jitsi.EXAMPLE.COM"
2021/09/16 06:52:38 [debug] 57499#57499: *4 http header: "Connection: Keep-Alive"
2021/09/16 06:52:38 [debug] 57499#57499: *4 http header: "Accept-Encoding: gzip"
2021/09/16 06:52:38 [debug] 57499#57499: *4 http header: "User-Agent: okhttp/3.12.1"

Request generated by Nginx and sent to the Jitsi Meet Docker container:

2021/09/16 06:52:38 [debug] 57499#57499: *4 http proxy header:
"POST /http-bind?room=cpwk HTTP/1.0
X-Forwarded-For: 2607:----:----:----:----:----:----:----
Host: jitsi.EXAMPLE.COM
Connection: close
Content-Length: 214rm
Content-Type: text/xml; charset=utf-8
Accept-Encoding: gzip
User-Agent: okhttp/3.12.1

"

HTTP 400 response received by Nginx from the Jitsi Meet Docker container:

2021/09/16 06:52:38 [debug] 57499#57499: *4 http proxy status 400 "400 Bad Request"
2021/09/16 06:52:38 [debug] 57499#57499: *4 http proxy header: "Server: nginx"
2021/09/16 06:52:38 [debug] 57499#57499: *4 http proxy header: "Date: Thu, 16 Sep 2021 06:52:38 GMT"
2021/09/16 06:52:38 [debug] 57499#57499: *4 http proxy header: "Content-Type: text/html"
2021/09/16 06:52:38 [debug] 57499#57499: *4 http proxy header: "Connection: close"
2021/09/16 06:52:38 [debug] 57499#57499: *4 http proxy header: "Strict-Transport-Security: max-age=63072000"

Following the Prosody BOSH reverse proxy documentation – which calls for adding additional headers to proxied requests – did not correct the issue.

Is there any feasible way to extract debug-level logging for BOSH requests from inside the Docker container?