Enable websockets with reverse proxy (official documentation wrong?)

Continuing the discussion from [How To] How to enable websockets (xmpp-websocket) and smacks for Prosody:

In the above Nginx snippets, different port numbers are used than in the official documentation.

When I follow the official documentation, users cannot see each other. I guess that’s because XMPP is not working, which is the port assigned to XMPP (5280) in use in the community example. While the official docs use 8443. But this is comparing a non-Docker solution with a Docker solution and might not be required for a Docker setup.

My Nginx config looks like this:

server {
  server_name meet.tzm.community;
  ssl_certificate /etc/letsencrypt/live/meet.tzm.community/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/meet.tzm.community/privkey.pem;

  include tls_params;
  include hardening;

  add_header Content-Security_Policy "default-src 'self'; font-src 'self' https://fonts.gstatic.com; img-src 'self' data: 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; object-src 'none'";
  add_header Content-Security-Policy "frame-ancestors forum.tzm.community;";
  add_header Permissions-Policy "microphone=(self),camera=(self),fullscreen=(self)";
  add_header X-XSS-Protection "1; mode=block";
  add_header X-Frame-Options "DENY" always;
  add_header Referrer-Policy "strict-origin";

  client_max_body_size 0;

  location /xmpp-websocket {
      proxy_pass https://localhost:8443/xmpp-websocket;
      proxy_http_version 1.1;
      proxy_set_header Upgrade $http_upgrade;
      proxy_set_header Connection "upgrade";
  }
  location /colibri-ws/ {
      proxy_pass https://localhost:8443/colibri-ws/;
      proxy_http_version 1.1;
      proxy_set_header Upgrade $http_upgrade;
      proxy_set_header Connection "upgrade";
  }

  location / {
    proxy_pass https://localhost:8443;
    proxy_http_version 1.1;

    error_page 502 =502 /errorpages/generic_offline.html;
    proxy_intercept_errors on;

    include proxy_params;
  }

  location /errorpages/ {
    alias /var/www/errorpages/;
  }
}

But this only works after I disable websockets, by adding the following to my .env:

ENABLE_SCTP=1
ENABLE_COLIBRI_WEBSOCKET=0
ENABLE_XMPP_WEBSOCKET=0

When I use proxy_pass https://localhost:5280/xmpp-websocket, and remove the above .env vars, there is no difference in behavior. Users still cannot see each other.

Could someone from the Jitsi developer team provide a full Nginx example config? Because now there are some details missing, and then errors like these happen.

It seems like that the 5280 port is not used either.

[tzm-user@tzmc1 jitsi-meet ((stable-5963))]$ docker ps
CONTAINER ID   IMAGE                       COMMAND        CREATED          STATUS          PORTS                                                                                      NAMES
ab6ad219581f   jitsi/jvb:stable-5963       "/init"        35 seconds ago   Up 33 seconds   0.0.0.0:4443->4443/tcp, :::4443->4443/tcp, 0.0.0.0:10000->10000/udp, :::10000->10000/udp   jitsi-meet_jvb_1
8b8f34102dd3   jitsi/jicofo:stable-5963    "/init"        35 seconds ago   Up 33 seconds                                                                                              jitsi-meet_jicofo_1
33fd1eda769d   aqual1te/jitsi:latest       "/init"        36 seconds ago   Up 34 seconds   0.0.0.0:8000->80/tcp, :::8000->80/tcp, 0.0.0.0:8443->443/tcp, :::8443->443/tcp             jitsi-meet_web_1
40c536bfad3c   jitsi/prosody:stable-5963   "/init"        36 seconds ago   Up 34 seconds   5222/tcp, 5280/tcp, 5347/tcp                                                               jitsi-meet_prosody_1
800d72521d31   local_discourse/app         "/sbin/boot"   4 hours ago      Up 40 minutes                                                                                              app
[tzm-user@tzmc1 jitsi-meet ((stable-5963))]$ nc -v localhost 5280
localhost [127.0.0.1] 5280 (?) : Connection refused

The command ss -wantus | grep 5820 returns nothing either… This is because expose is used instead of ports in docker-compose. But this doesn’t have to be public, unless Jibri is used on a different host I guess? And ENABLE_XMPP_WEBSOCKET=0 needs to be set, otherwise users cannot see each other, also without a reverse proxy (thus directly using 8443).

When I do use the Nginx config listed at the top of this post, and set ENABLE_XMPP_WEBSOCKET=0, then users can see each other. But then the quality is super low. So I guess the reverse proxy is not really working well. Disabling websockets and using SCTP does work fine, but that’s not a recommended setup…

It would be greatly appreciated if the official docs were a bit more complete.

Please correct me if I’m wrong, but these are not relevant for a Docker setup with an Nginx reverse proxy, right? If it is, then I don’t see how, could you clarify?

Understanding how all the various parts of Jitsi are meant to be configured (ie the links I sent) can help you rectify any misconfigurations in the docker file.

Maybe this will help? Jitsi Meet in Docker Container: Websocket error

Edit: by the way, port 5280 is listed in your output of docker ps, above

Edit 2: I am using http for localhost in proxy_pass and you have https

Why did you use 8443 instead of 5280 in nginx config?

Hi Corby, that makes sense, but the internals of the containers should best be untouched. And the place for applying a fix is most likely in the Nginx on the Docker host.

The port is listed as exposed, but not publically. For that changes are needed in the docker-compose file. Which may be done with an override file. But since the official docs don’t do this, it’s a bit confusing.

Also, disabling this: Jitsi Meet in Docker Container: Websocket error - #10 by turbozv
Should probably not be needed, I guess. But also without the reverse proxy I have that disabled. otherwise it didn’t work.

The official docs use that. Do you have a reverse proxy running with Jitsi? How do you have it setup? Because it could be the official docs are wrong indeed. But then the Docker setup needs some modifications as well.

What does this give?
docker port test 5280/tcp

[kjong@tzmc1 jitsi-meet ((stable-5963))]$ docker port jitsi-meet_prosody_1 5280
Error: No public port '5280/tcp' published for jitsi-meet_prosody_1

Which makes sense, because in docker-compose expose is used, not port. But before I start changing these things, I’m interested in why the official docs use 8443. It may not be needed to expose these ports to the public Internet.

Your port didn’t be exposed

At a high level: Web traffic, on https / port 8443
(or 443 or whatever) should be listening publicly. Prosody on port 5280, should not. That is the purpose of the proxy_pass. Nginx takes web requests https://..... com/xmpp-websocket and forwards it to http on localhost (termination of SSL happens here).

1 Like

I know that :slight_smile: I also stated that in the top post. The question is more, is that really needed? Since the official docs use 8443. And the examples are not Docker setups. So I first want to understand, before I start changing these things.

Please share your docker-compose file. There seems to be error.

Why exactly? Because you think port 5280 must be public? expose is used, but not ports, then these ports are not publically available to the internet. So this is by design correct. The goal should not be to recreate a non-Docker setup, but to try and find the solution for a Docker setup + a reverse proxy. :slight_smile:

The “public” means between the host machine and inside the container.
Not between outside host machine and host machine.

nc -v localhost 5280
You said this didn’t work, then how nginx can work??
Ngnix is not container.

Please, check the official documentation, there Nginx doesn’t use 5280. And that’s why I would like to hear some feedback from the Jitsi devs.

Also ENABLE_XMPP_WEBSOCKET=0 is set, otherwise Jitsi doesn’t work either. That probably disables the XMPP port listener as well. This is with or without a reverse proxy, more info: Jitsi Meet in Docker Container: Websocket error - #10 by turbozv

If port is not exposed publicly, how nginx can access that port of container?