Please help: Running Jitsi inside Docker on Plesk behind NGINX reverse proxy fails

[enwikuna]

Hi there,

after 5 hours of spending time to configure Jitsi on my Plesk server inside Docker, I need to give up and ask you — sorry for that.

First, I've followed the tutorial here: https://jitsi.github.io/handbook/docs/devops-guide/devops-guide-docker

I've created a custom subdomain on my server meet.my-domain.de and downloaded the latest release: https://github.com/jitsi/docker-jitsi-meet/archive/refs/tags/stable-9955.zip

I've unziped it and created a .env from the template. I've executed the script to set a password and changed the following values:

HTTP_PORT=8000
HTTPS_PORT=8448
PUBLIC_URL=https://meet.my-domain.de:${HTTPS_PORT}
DISABLE_HTTPS=1
ENABLE_HTTP_REDIRECT=0
ENABLE_LETSENCRYPT=0

Since I handle SSL inside Plesk by a reverse proxy, I've followed this tutorial to disable HTTPS inside the .env: https://jitsi.github.io/handbook/docs/devops-guide/devops-guide-docker/#running-behind-a-reverse-proxy

Also, I needed to change the composer file because the port 8080 is reserved by ruby in my system:

# Video bridge
    jvb:
        image: jitsi/jvb:${JITSI_IMAGE_VERSION:-stable-9955}
        restart: ${RESTART_POLICY:-unless-stopped}
        ports:
            - '${JVB_PORT:-10000}:${JVB_PORT:-10000}/udp'
            - '127.0.0.1:${JVB_COLIBRI_PORT:-8085}:8080' <- Changed port 
        volumes:

Finally, I've set the following reverse proxy inside NGINX directive settings of my subdomain (server block not needed inside Plesk, just fyi):

# Proxy Web (HTTP/HTTPS)
location / {
	proxy_pass http://127.0.0.1:8000; # Replace with the Jitsi web service port
	proxy_set_header Host $host;
	proxy_set_header X-Real-IP $remote_addr;
	proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
	proxy_set_header X-Forwarded-Proto $scheme;
	proxy_http_version 1.1;
	proxy_set_header Upgrade $http_upgrade;
	proxy_set_header Connection "upgrade";
}

# Proxy WebSocket connections for Jitsi Meet
location /xmpp-websocket {
	proxy_pass http://127.0.0.1:8448/xmpp-websocket; # Replace with Jitsi WebSocket path
	proxy_http_version 1.1;
	proxy_set_header Upgrade $http_upgrade;
	proxy_set_header Connection "upgrade";
	proxy_set_header Host $host;
	proxy_set_header X-Real-IP $remote_addr;
	proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
	proxy_set_header X-Forwarded-Proto $scheme;
}

# Proxy Colibri Stats (if needed)
location /colibri {
	proxy_pass http://127.0.0.1:8085; # Proxy to JVB Colibri (default port 8080)
	proxy_set_header Host $host;
	proxy_set_header X-Real-IP $remote_addr;
	proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
	proxy_set_header X-Forwarded-Proto $scheme;
}

After running the composer stack, I've checked the logs and fond something sus inside the JVB container:

MucClient.lambda$getConnectAndLoginCallable$9#697: Error connecting:
org.jivesoftware.smack.SmackException$EndpointConnectionException: The following addresses failed: 'RFC 6120 A/AAAA Endpoint + [xmpp.meet.jitsi:5222] (xmpp.meet.jitsi/172.19.0.2:5222)' failed because: java.net.ConnectException: Connection refused
	at org.jivesoftware.smack.SmackException$EndpointConnectionException.from(SmackException.java:334)
	at org.jivesoftware.smack.tcp.XMPPTCPConnection.connectUsingConfiguration(XMPPTCPConnection.java:664)
	at org.jivesoftware.smack.tcp.XMPPTCPConnection.connectInternal(XMPPTCPConnection.java:849)
	at org.jivesoftware.smack.AbstractXMPPConnection.connect(AbstractXMPPConnection.java:525)
	at org.jitsi.xmpp.mucclient.MucClient.lambda$getConnectAndLoginCallable$9(MucClient.java:689)
	at org.jitsi.retry.RetryStrategy$TaskRunner.run(RetryStrategy.java:167)
	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
	at java.base/java.lang.Thread.run(Thread.java:840)
JVB 2025-01-17 10:56:05.539 WARNING: [27] [hostname=xmpp.meet.jitsi id=shard0] MucClient.setPresenceExtensions#519: Cannot set presence extension: not connected.
JVB 2025-01-17 10:56:05.740 INFO: [26] [hostname=xmpp.meet.jitsi id=shard0] MucClient$2.connected#338: Connected. isSmEnabled:false isSmAvailable:false isSmResumptionPossible:false
JVB 2025-01-17 10:56:05.741 INFO: [26] [hostname=xmpp.meet.jitsi id=shard0] MucClient.lambda$getConnectAndLoginCallable$9#703: Logging in.
JVB 2025-01-17 10:56:05.839 INFO: [26] [hostname=xmpp.meet.jitsi id=shard0] MucClient$2.authenticated#351: Authenticated, resumed=false
JVB 2025-01-17 10:56:05.856 INFO: [26] [hostname=xmpp.meet.jitsi id=shard0] MucClient$MucWrapper.join#826: Joined MUC: [email protected]

Everything else looked fine. So I've opened meet.my-domain.de and was able to initiate a new meeting but instantly got an error:

Inside the console, I can see this error:

devtools-overlay.js:1 Uncaught TypeError: Cannot read properties of null (reading 'key')
    at devtools-overlay.js:1:295

strophe.stream-management.js:224 WebSocket connection to 'wss://meet.my-domain.de:8448/xmpp-websocket?room=libs' failed: 
strophe.util.js:84 2025-01-17T11:10:01.969Z [modules/xmpp/strophe.util.js] <Dl.Ii.Strophe.log>:  Strophe: Websocket error {"isTrusted":true} Websocket error {"isTrusted":true}

Any idea what I am missing here?

[enwikuna]

Just found the solution myself! I would suggest that you guys change the environment variables a bit. Let me explain the issue! Because I have Plesk running on port 8443, I needed to change the port to 8448 as you can see above. But in your env, you write the following text:

Keep in mind that if you use a non-standard HTTPS port, it has to appear in the public URL

But here the problem begins! This tells me to add the SSL port to my URL:

PUBLIC_URL=https://meet.example.com:${HTTPS_PORT}

Generally, this works BUT NOT if you use a NGINX reverse proxy like I do! Because in this case, Jitsi tries to connect to the Websocket running on port 8448 which is not exposed since NGINX uses 443 as SSL port and does the redirect internally. So maybe you change the description of your documentation or env example a bit to give clarity so that the next guy don't need to spend a whole working day trying to understand everything.