Jitsi is disconnecting when accessed through a proxy

I am attempting to provide a level of security by accessing my Jitsi server through a proxy. Currently, I am running a Docker- based Jitsi installation that has a valid cert. I can access Jitsi meet directly without problemsand can start a meeting that has very good video quality.

Unfortunately, when accessing my Jitsi installation through the proxy, I can get the front page that allows me to start a meeting, but when I attempt to start a meeting I get a page showing a continuous display that says I have been “disconnected”, that I should check my network connection, and that I will be “reconnected” in 25 seconds. Every 25 seconds, a reconnection attempt is made, and the “You have been disconnected” page redisplays.

I have monitored output from the proxy server, and note that apparently a number of javascript files are loaded, along with some mp3 files and some other files with odd suffixes. I presume that these files support the streaming of the video once a meeting is established, but I do not know why the connection keeps being broken. This only happens when my Jitsi installation is running behind a proxy server.

Is there some configuration needed (or misconfiguraration to change) that will stop this continued Jitsi disconnection? How can I get Jitsi to operate correctly behind a proxy???

  • UDP/10000 must be accessible

  • websocket forwarding needs some extra configurations

  • SSL termination

  • special configuration if TURN works on TCP/443

In my opion, no need to the proxy for extra security if the server is configured correctly


Thanks for the info, but some clarification is needed.

  1. My port 10000 is already open on the server. What other measures are required to make it accessible?

  2. Please specify the “extra configurations” required for websocket.

  3. My proxy is already configured to handle SSL. If it wasn’t, I would not get the Jitsi home page which is accessed over SSL. What else is needed for “SSL Termination”?

  4. Please specify the “special configuration” required for TURN servers working on port 443.

search for “udp/10000 connectivity

check Jitsi’s Nginx config. Location blocks for http and websocket are different. The same is needed on proxy too

then this step is OK in your case

TURN traffic must be redirected at stream layer.
Use TURN server on port 443


Thanks for the information you provided. It has helped me a great deal in figuring out what was not wrong in my setup.

I believe I figured out the basic problem: it was the proxy server I was using.

I am actually working on writing software that has proxying capabilities, but which also performs some specific security processes when an application behind it is accessed. The problem was that the proxy part of the application was not properly processing all requests to the Jitsi server.

I fixed the bug that was killing the software process. I can now connect to my Jitsi Meet server. My only problem now is that I cannot get the video stream. I connect, but when two people connect to a Jitsi meeting, I get no video.

I am looking at configuration considerations to see if there is anything I need to set up in order for the video to work, and I am also making sure that there are no other bugs in my proxy code. I may ask some questions about configuration and how the video works, but if I do I will be asking them in another topic.

Again: thanks for your help. I would not have found my solution without it.

Do you connect to the server (when Jitsi is behind the proxy) using the same FQDN used during installation?

Yes, I am connecting to the same domain name (fully qualified).

What appears to be happening is that Jitsi is showing that the remote camera and audio is off on both sides of the communication. In other words, if I connect Machine A and Machine B to a meeting named “meeting” and have the camera and audio on on both machines, Machine A shows Machine B’s camera and audio as off, while Machine B shows Machine A’s camera and audio as off. No video or sound is transmitted between any of them.

The machines communicate with each other without problems when not going through the proxy. Something in the proxy appears to be blocking the audio and video.