Jitsi Meet in Docker Container: Websocket error

Hey, I’ve got a problem with the installation.

I’d like to set up a Jitsi Meet instance on my Debian server via Docker container. I’ve got an Apache webserver running on it and want to add the Jitsi server on a subdomain.

I followed the tutorial on how to do this and I am able to reach the site, but not to join a session:

error message

You were disconnected. Check your network connection. Connecting in 23
seconds …

I guess there is some error in the Apache configuration (see below), but I don’t really know.

There are some errors in the JS console, but the important one (I guess) is:

WebSocket connection to ‘wss://jitsi.example.com/xmpp-websocket?room=strangeshopsincorporateagain’ failed: Error during WebSocket handshake: ‘Upgrade’ header is missing

Here is my Jitsi configuration file (the important parts; I didn’t change anything else):

...
#
# Basic configuration options
#

# Directory where all configuration will be stored
CONFIG=~/.jitsi-meet-cfg

# Exposed HTTP port
HTTP_PORT=8000

# Exposed HTTPS port
HTTPS_PORT=8443

# System time zone
TZ=Europe/Berlin

# Public URL for the web service (required)
PUBLIC_URL=https://jitsi.example.com

# IP address of the Docker host
# See the "Running behind NAT or on a LAN environment" section in the Handbook:
# https://jitsi.github.io/handbook/docs/devops-guide/devops-guide-docker#running-behind-nat-or-on-a-lan-environment
DOCKER_HOST_ADDRESS=192.168.178.57
# local IP address of my server
# I tried my public IP as well, but that didn't change anything
...

Apache configuration:

<VirtualHost *:443>
        ServerName jitsi.example.com:443

        SSLEngine on
        SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem
        SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem

        AllowEncodedSlashes NoDecode

        SSLProxyEngine On
        SSLProxyVerify None
        SSLProxyCheckPeerCN Off
        SSLProxyCheckPeerName Off

        RewriteEngine on
        RewriteCond ${HTTP:UPGRADE} ^WebSocket$ [NC]
        RewriteCond ${HTTP:CONNECTION} ^Upgrade$ [NC]
        RewriteRule .* "wss://localhost:8443/$1" [P,L]

        ProxyPreserveHost On

        # i don't know exactly which of these are needed, so I used all of them
        ProxyPass /http-bind https://localhost:8443/http-bind/
        ProxyPassReverse /http-bind https://localhost:8443/http-bind/

        ProxyPass /xmpp-websocket/ wss://localhost:8443/xmpp-websocket/
        ProxyPassReverse /xmpp-websocket/ wss://localhost:8443/xmpp-websocket/

        ProxyPass / https://localhost:8443/
        ProxyPassReverse / https://localhost:8443/

        ProxyRequests off
</VirtualHost>

I don’t know what else could be important, so please tell me if anything else is needed.

Thanks in advance.

(I had to remove two pictures because I’m a new user, but I hope the question is clear without them. I also asked this question on StackOverflow (stackoverflow[DOT]com/questions/65374519) and included the pictures there.)

EDIT: Oh, and I forwarded the ports 80 (TCP), 443 (TCP) and 10000 (UDP) to the server.

while I don’t know anything about Docker and very few about Apache, I can clear at least one point: websocket is not the main issue. It’s very much possible to create meetings without working websockets. Websockets are used for signaling between meeting sessions and jvb, so some things will not work correctly without websockets and it is a problem you will have to tackle, but at the moment it can’t be the main issue.
My guess is that the bosh connection (http-bind) is not working as it should and it’s an Apache configuration problem. There was a thread recently on Apache setup less than a week ago I believe, try the forum search.

Thanks for the answer. That helps finding the error.

I searched the forum and tried different Apache configurations, but sadly was unable to find a working one.

Docker will listening on 8443 by default. Once running, it looks like this:

    Name        Command   State                       Ports
--------------------------------------------------------------------------------
jitsi-jicofo    /init     Up
jitsi-jvb       /init     Up      0.0.0.0:10000->10000/udp,
                                  0.0.0.0:4443->4443/tcp
jitsi-prosody   /init     Up      5222/tcp, 5280/tcp, 5347/tcp
jitsi-web       /init     Up      0.0.0.0:8443->443/tcp, 0.0.0.0:8000->80/tcp

Without Apache, open up the ports in the tutorial and verify Docker jitsi works correctly.

https://jitsi.example.com:8443 (maybe there will be a cert error)

Thanks for the reply and good call. It does, in fact, not work while accessing it over port 8443 (neither local network nor via the internet) or 8000.

Output docker ps

CONTAINER ID   IMAGE                  COMMAND                  CREATED        STATUS         PORTS          NAMES
1ab807916dd0   jitsi/jvb:latest       "/init"                  12 hours ago   Up 4 minutes   0.0.0.0:4443->4443/tcp, 0.0.0.0:10000->10000/udp   docker-jitsi-meet_jvb_1
81f272b3b604   jitsi/web:latest       "/init"                  38 hours ago   Up 4 minutes   0.0.0.0:8000->80/tcp, 0.0.0.0:8443->443/tcp        docker-jitsi-meet_web_1
47028c9f64f8   jitsi/jicofo:latest    "/init"                  39 hours ago   Up 4 minutes          docker-jitsi-meet_jicofo_1
28a34ebf8b65   jitsi/prosody:latest   "/init"                  39 hours ago   Up 4 minutes   5222/tcp, 5280/TCP, 5347/tcp          docker-jitsi-meet_prosody_1

So I guess the problem has nothing to do with the Apache server.

The problem is: I just tried recreating the .env file and changed nothing but the passwords (via script), the timezone, the public URL and the docker host address. From what I read it should work this way …

Is there anything else that could cause this problem? How can I check this?

Try changing the public url to have 8443 at the end in the env file. Remember to delete the .jitsi-meet-config folder after env changes.

Well, that changed something.
The error message still appears, but it happened almost immeadiately before, and now it takes about 30 seconds (both with public and private IP address and with Apache and directly).
Also, it looks like I can’t join the same session with multiple devices (it seems empty for each of them), and the chat does not work, but these might be separate issues.
EDIT: I also can’t unmute myself, so it doesn’t look like it’s working at all.

Okay: I tried setting my private or public IP as PUBLIC_URL and accessing the site directly with that IP (and port 8443) and it worked. But if I put my domain or the subdomain (which is a CNAME to the main domain) there, the error occurs.

This seems like some kind of DNS error, right? But if that was the case, I shouldn’t be able to even find the site.

Same error. Any ideas?

Fixed by adding this to .env

ENABLE_XMPP_WEBSOCKET=0

I used the following in httpd-le-ssl.conf, the “wss://” works without using “ENABLE_XMPP_WEBSOCKET=0” :slight_smile:

SSLProxyEngine on
SSLProxyVerify none
SSLProxyCheckPeerCN off
SSLProxyCheckPeerName off
SSLProxyCheckPeerExpire off
AllowEncodedSlashes NoDecode
ProxyPass / https://localhost:8443/
RewriteEngine on
RewriteCond %{HTTP:Upgrade} websocket [NC]
RewriteCond %{HTTP:Connection} upgrade [NC]
RewriteRule ^/?(.*) "wss://localhost:8443/$1" [P,L]

In case you haven’t done so already: When using /xmpp-websocket, then the PUBLIC_URL environment variable needs to be set on both the web and prosody containers.

Maybe this breaking change wasn’t documented properly.

Hey,
after I couldn’t solve the problem back in December, so I gave up and removed it from my server (I didn’t really need it, I just wanted to try it out). Therefore, I can’t try it out.
@turbozv: I don’t think this was the main problem, but thanks for the hint.
@haslersn: Thank you as well for the answer. I don’t think I did that. How/where would one do this? In the same config file? Or somehow else?

Adding that environment variable to the prosody container did fix your issue in our case. You can do so as follows: In docker-compose.yml, add PUBLIC_URL to the list services.prosody.environment, if it’s not already there. If it’s already there, then you have a different problem.

I met the same issue when I used Chrome version 76, but when I changed it to version 93, it worked fine.