Nginx, coturn & port 443

Hi, question: if I install from scratch (no nginx pre-installed), I have no problems with turn. What are the consequences of removing TURN? Isn’t it needed to relay video for people at home behind NATs?

For our setup it works even for users behind NAT firewalls.

Turn will be used in case of networks with blocked udp, or restrictive firewalls allowing only real https traffic on port 443. We used to be running jetty before, which was not able to handle the second case and it was performing bad in some cases while serving files.

Removing the turnserver works even for existing installations. After that the nginx module is gone and you can modify the nginx site configuration back to 443.
After that I can restart nginx and jitsi, accessing both websites via 443 again.

For me it’s working with using port 4444 for block server (ssl). I just wonder, why sometimes the port seems to be set automatically and why in other install I have to change it by hand? Which part of install script handle this?
Also I wonder, can we set http2 or not recommended?

Note @damencho : There is a new stable release of this morning which leads again to an more-or-less empty file /etc/prosody/prosody.cfg.lua on Debian 10.2 with two lines:

Include “conf.d/*.cfg.lua”

If I replace this tiny file with the definitions from my recent (well-working) installation, the infrastructure runs well again (still missing the load balancing feature … but that’s another story)

Hey guys!
I’ve been working on these issues for last couple days. Man, what a wreck…
I have managed to install new clean Jitsi installation on new server. Couple things:

If you are using same old Jitsi quick install guide, please note that Nginx has to be installed BEFORE Jitsi, because the Jitsi will check for Nginx before configuring its new COTURN server, and if it doesn’t find it, it wont. (I know what you thinking: Jitsi installs Nginx by itself! Well, yes, but it installs it after checking for it, and therefore NOT configuring COTURN server. Yep, geniuses… :slight_smile: )

I have a question as well. What ports should actually be opened? I have opened 80, 443 and my ssh port. But there are so many changes now, I am confused and not sure if I should open anything else, like 4444, or 4445?
And I noticed that default config now uses Jitsi STUN server. Does this installation also installs STUN server together with TURN? Can I use my own STUN server, if so then how do I set it up, what port does it use?

Please assist here.


1 Like

It’s wrote also in the quick install guide to have it before :grin:

  • 22 ssh TCP
  • 80 http TCP
  • 443 https TCP
  • 10000:20000 UDP

Be aware to not use something other that collide with actual ports in use, for example I always use Webmin and it use 10000 both TCP and UDP, in that case I needed to swith his ports from the panel before installing jitsi.

Hey Rubens!
Just to confirm:
“<…> If none of the above is found it then defaults to Nginx. If you are already running Nginx on port 443 on the same machine you better skip the turnserver configuration as it will conflict with your current port 443, so use the command apt install --no-install-recommends jitsi-meet .”

So it defaults to Nginx, meaning Nginx is installed by Jitsi, when no http server is found. But the only issue with this auto installation is that it sets up Nginx AFTER trying to configure COTURN. It doesn’t find Nginx so COTURN is left without configuring it. If only they would change it to finishing Nginx setup before setting up COTURN, then the COTURN would also be configured in that case when someone is installing Jitsi with no Nginx present.
Now, if you install Jitsi with no http server (No Nginx) present, you will get this:

Setting up nginx-full (1.14.2-2+deb10u1) ...
Setting up jitsi-meet-turnserver (1.0.3969-1) ...

turnserver not configured as no nginx found to multiplex traffic

Setting up nginx (1.14.2-2+deb10u1) ...

So ports remain all the same? Jitsi have configured Nginx (automatically) to listen for port 4444 now, instead of 443. That is confusing for me. Is this some kind of internal ports (4444, 4445) it’s listening on then?


As far as I know, NGINX isn’t installed by default but it’s used the Java webserver (really bad), the 443 collision is in chase you have nginx AND a website running on 443 :slight_smile:

In my experience (10 installs in last 3 days) I’d really suggest to install nginx before.

4444 and 4445 are used internally, doesn’t communicate with web, I guess.

Rubens: it does install Nginx by default. It says so in Quick Install guide too. I also have installed it 10 times in last couple days… :slight_smile:

Ow ok, good to know.

Video tutorial maybe it’s too old, plus I did some installs during the turnserver bug that made me crazy since on one server was working and the same stuff done on another didn’t :laughing:

1 Like

Trust me, your’e not the only one who was going crazy… :slight_smile:
I mean I do appreciate Jitsi team’s work, but releasing UNSTABLE version as STABLE, not even testing it properly is a bit lame. ;/

just a bit

when I’ve discovered why my brain said: FFFUUUUUUUU… (you know the rest)

im guessing this issue with the latest stable is why my haproxy gets a 502 when forwarding to jitsi.

the nginx log shows the web traffic from the haproxy seems to then get proxied by nginx to the 4445

from nginx error log- ( is haproxy)
2020/04/04 21:09:09 [error] 1255#1255: *2323 recv() failed (104: Connection reset by peer) while proxying and reading from upstream, client:, server:, upstream: “”, bytes from/to client:713/168, bytes from/to upstream:168/1230

would love some clear instructions on exactly how to run jitsi on ubuntu with nat via haproxy.

i have a single internet IP address, 443 is forwarded to HAPROXY which does a heap of url and path based proxying. Jitsi is on a ubuntu box. Based on that architecture:

  1. do i install nginx first?
  2. do i do a vanilla apt-get install jitsi-meet?
  3. do i only need to add videoserver settings as per
  4. what udp ports are actually in use. some doco says only 10000 some say 10k-20k.
  5. what tcp ports need to be open from the internet.
    i love the software btw, but i would also love to start using it :slight_smile:

I upgraded from jvb1 (installed by itself with jetty as server, no apache or nginx) and jitsi installed nginx by itself (‘upgraded’ jetty to nginx), so it does not seem necessary.

I had done a vanilla install of jvb1 and did a vanilla upgrade to jvb2.

this is essentially what I did, the other changes were to get additional functionality.

10000 only.

I proxy from my main nginx install on the host (having a similar role to your haproxy) to the nginx installed in the LXD jitsi container; I have edited the container nginx conf file (created by jitsi upgrade) to drop the ssl so I have a classical setup, the main nginx on the host does the ssl stuff, it has exposed its 443 port to the internet (of course) and it proxies to the container on port 80 doing simple HTTP (the container port 80 is not exposed to the internet). The host port 10000 (and only this port) is NATted to the container port 10000.
By and large I have a similar setup to the one I had with jvb1, the port 443 is managing https jitsi through a reverse proxy, and the 10000 port is directly exposed. The only change is that the jitsi container is exposing a HTTP port managed by nginx instead of jetty. It’s probably not a high performance setup but my hardware is not so great so I can’t hope to manage dozens of clients anyway.

About coturn, it seems only necessary if you can’t expose port 10000 but it’s said to be less performant and it seems a royal pain to setup so I dropped it without mercy.

Please, be patient we did fix some issues and there are few small ones to fix. We also been testing it hundred times with different scenarios, but we cannot cover all combinations of versions, different OS and different pre-existing client configs.
And mind that the installers cannot fully cover all variation of people configs.
We wanted to quickly release it so people can use it, as there are more and more people coming and want to make deployments (Last release was from December). And we already hands full of urgent issues, and if we had left it to test it further, there will be few more months to pass.
If something is not working for you, please create PR fixing it, it will help a lot more then calling our work lame.


Another big questions is … where do I run the coturn server when my videobridges are split from the Dispatcher? Directly on the JVBs? Or does all turn traffic have to run through the Dispatchers nginx?

Well, I’m usually rather surprised to get a .deb update package that seemingly wipes out my configuration. Seriously, that mustn’t happen. I’m no expert on this, but if the old config breaks the new binaries, I’m rather sure there’s a proper way to prohibit an automatic/unattended update in the .deb was of doing things? BTW, that was from deb stable/ — note the stable there?

First things first: I really appreciate the work you did with Jitsi-Meet the last years. And I accept that you’re in a difficult situation as right now the whole Internet is looking for scaleable, affordable and privacy-friendly (video-) conferencing solutions and you’re trying to fit this demand and fix issues arising.

BUT: having experienced breakage on “apt update && apt upgrade”, on the stable branch, myself, going forward the path you’re currently following you’ll end up at pinned package versions of jitsi-meet and friends that will never, ever, get updated by the users — simply because of “never touch a running Jitsi install as it can only get worse”.

I certainly admire the effort I see, but please, pretty, pretty please, increase your QA efforts on what you tag as stable. Updating stable software must not break it in random, undocumented ways. (And yes, this sucks.)

Thank you :slight_smile:

And as for TURN now relying on nginx: how is this supposed to scale? Having deployed a bunch of jvbs to scale, and the frontend on a rather low-spec’d VM, I’m feeling a bit pissed, to be honest …

This is single machine install. This is what low usage users will use. If you want to scale you will not use jitsi-meet install that installs everything on one machine. We recommend having a signalling node, a autoscaling group of bridges and a pool of turnservers. And this multiplied as many times as needed, depending on the load. Single machine with everything does not scale. It can be an example how to configure stuff and what is recommended. Many of the configs come straight from That’s why we are migrating configuration which does not wipe, but just slightly modify existing config.
And believe 2 people had done hundreds of wipes and clean installs and upgrades. And still I missed some cases, and I spent hours of helping people fix their problems.

1 Like