Only certain users have Channel closed: 1006


We have deployed a Docker version and Ubuntu version of Jitsi meet following the official guides. It works well, but have recently run into an issue on one particular device which we have not been able to solve.

The problem:
The client connects to a room and can see/hear himself, but has a black screen where other participants’ cameras are with no audio from anyone else. The error in the browser logs is below

The device can see when others are muting/unmuting themselves but still no audio.

The device is running Windows 10(tried Firefox, Chrome, Edge). This device works fine on, which is confusing. has this in logs:

Our deployment has this:

Thanks in advance for any tips/advice


After doing more testing, we have figured out that it is a network/firewall issue.

What we still cannot figure out is what the difference is between (where everything works, no matter the network used) and the Jitsi Docker and Jitsi Ubuntu(where the network is an issue).

Maybe some revert proxy setting fronting the docker/ubuntu deployment …


Thanks for the feedback. We have tested the Docker/Ubuntu deployments on AWS and another datacentre with no Linux(UFW) or external firewall(simply on an open public IP).

With the Docker deployment, everything is kept in docker, in the .env file the HTTPS port is changed from 8443 to 443, so the “web” Docker serves the end client. Meaning that there is no Nginx/Apache reverse proxy happening on the Linux host.

Do you have any other suggestions perhaps? Are you aware of any difference between the self-hosted(Docker/Ubuntu) versions of Jitsi and what is on


I know such problems were fixed for people with jitsi-meet/jitsi-meet.example at 687106818a0c4d92c50029759129d9e71325d96f · jitsi/jitsi-meet · GitHub
But this is already available for the debian install, not sure whether it is in docker though.

I noticed the same problem after moving from one bare-metal server to a cloud infrastructure with multiple machines. Maybe it has something to do with it

This line already exists in the docker images:

proxy_set_header Upgrade $http_upgrade;

Hi there, i am also affected by this problem.
Although i am not sure if this can be broken down to certain users, as recently a group of users was affected that before was working.

This means that the setup sometimes/often works for 12+ users just fine, on other days not at all.

I would rather say it happens on “certain times”.
This setup is for a school and the random issues with broken video, which comes along with this error, are a bigger problem… and until now there is no clear way to reproduce the error, except that the session has to be important.

The setup is using docker and the upgrade header is set in the reverse proxy.

        location /xmpp-websocket  {
               proxy_pass; # docker-jitsi-meet_web_1
               proxy_http_version 1.1;
               proxy_set_header Upgrade $http_upgrade;
               proxy_set_header Connection "Upgrade";
               proxy_set_header Host $host;
        location /colibri-ws  {
               #proxy_pass; # docker-jitsi-meet_web_1
               proxy_pass$1/$2$is_args$args; # changed to this after my reply here
               proxy_http_version 1.1;
               proxy_set_header Upgrade $http_upgrade;
               proxy_set_header Connection "Upgrade";
               proxy_set_header Host $host;

As described in Self-Hosting Guide - Docker · Jitsi Meet Handbook, DOCKER_HOST_ADDRESS is set to the static, public IP, however some participants connect from the local network.

The issue, when occurring, seems to match ICE / WebSocket Repeated Connection Failures on Vanilla Jitsi Installation · Issue #815 · jitsi/docker-jitsi-meet · GitHub.


Thanks for the suggestions so far. Unfortunately still no luck - we are experiencing the exact same issue on more and more clients now who are connecting from their office networks.

What we have tried to solve by doing the following:

  1. Nginx config to be as follows:
  2. Follwed this guide - [How To] How to enable websockets (xmpp-websocket) and smacks for Prosody
  3. Updated this variable in .env ENABLE_XMPP_WEBSOCKET=1 and to 0
  4. We have tried AWS and a different hosting provider that provides a plain public IP.

After many different tests again with Docker-Jitsi and Jitsi on Ubuntu it seems that the issue has been tracked down to the JVB. Here is a screenshot where you can see what happens when a client who does not have an issue connects to the JVB:

Compared to when a user who has no video or audio connects(you notice that this client never switches to a public IP, but rather remains on their private subnet)

Below are some screenshots from the client having issues(note that the two black images at the top are able to see and hear each other perfectly)

Here the “finished” sockets are getting 403’s from Nginx

Nginx is getting this error:

Any chance anyone has a tip on this? Have not managed to solve it yet…