Nginx, coturn & port 443

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

The turn and nginx situation is just a replacement of what we had with jetty, but improving it. Works better. And when you deploy just turn you don’t need nginx, you need separate vm and ip address, which low scale deployments don’t even have.

Sorry if I have insulted you [damencho], that was not my intent. And I did not call Jitsi Team’s work lame, I called this situation at that point lame, but things happen. Apologies again if I did.

I have few questions though:

  1. So now Jitsi by default installs it’s own TURN server, or is it TURN and STUN together?
  2. If Jitsi installer finds Nginx configured it will not install/setup TURN. What TURN will it use then?
  3. How would this work in Matrix Synapse server, for example, where already is a TURN server running (for 1-1 calls) and Nginx, but I would like to install Jitsi (as I have now) on the same server for Synapse/Riot to use that instance for video/conference calls? What Turn would jitsi use there?
  4. What happens to that ICE thing? Is is still used? I thought that was a TURN/STUN equivalent?


Says who, where? Latest info was “just add jvb to scale”. Again, no issue with changing the basics — but, FFS, do document this in time.

Where, since when? And what do you recommend beyond the clouds? A self-hosting alternative to you-name-it that only works in the clouds is … ridiculous. If I have to rely on $cloudprovider anyway, Zoom is the answer, period.

Sorry to ask this, but, technically, how does that work? Having 10k autoscaled, i. e. independent, TURN-instances, how do connections to any of those find their conference?

That’s not how .deb works, does it? A .deb package comes with a new content, which is either accepted or denied by the local sysadmin. You simply cannot »migrate« configs in this regime (AFAIK).

Again, I do not blame you or any of the Jitsi team, I assume you’re doing your best. But, as, this obviously isn’t enough, this is leaving at least potentiall corner-cases uncovered. In that regard, I expect you to reach out for help/fix your approach.


Will skip turn configure on port 443. Good point though. Maybe we need to configure just to use another port…

No idea how is this configured and what it is using, sorry.

Nope. ICE is the protocol for establishing the connection, nothing is changing there. Not having turn running on port 443 is a problem in some enterprise networks where only SSL on port 443 is enabled and no udp is allowed and turn is the fallback. Turn is also fallback for some p2p connections.

Any help is welcome, thanks. There are community members already helping and created PRs fixing some of the problems and that helped move things faster.
Even just testing unstable packages and reporting problems will help. The packages that were pushed in stable, stayed in unstable for 3 months doing the same operations they do today in stable, whatever was reported was fixed.

You are mixing stuff here. You can do it on bare metal, no problem. But to be able to scale unlimited you need unlimited resources … that does not work it bare metal.
Anyway …

This is not how turn works. It is just a relay to a port used by JVB and it is webrtc handling that …

Ok. We as developers to move forward can also choose to stop support for components and will offer you no longer upgrades, that was another option. Just new installs. We choose to keep people deployments and not force them to start from scratch.

Hello. I still didn’t understand what TURN is Jitsi using, if it doesn’t install/configure it on finding Nginx upon installation?


There is still ongoing work around that

Just to clarify - I did manage to install Jitsi + Coturn + Nginx few days ago by default and everything seems to work fine. All i had to do is Install and Enable Nginx, delete default config BEFORE installing Jitsi. and it installed and configured everything correctly with coturn.

The question is about servers that have other instances using Nginx already with their configurations present. I have this sort of installation as well, it seems to work fine, but I don’t understand what coturn is Jitsi using at this point? STUN is enabled and there is 3 stun servers listed in Jitsi config, but TURN escapes me. :slight_smile:

Also, just for general knowledge. I see on your jitsi server you have enabled jibri feature. Does this mean, that you have multiple (hundreds, maybe thousands) of VPS’s running your jibri instances for that pool, that users get them from? If thats true, it must take loads of resources for you guys to do all this for free? ;/

That is correct.

It maybe not using any turn, it is a fallback mechanisum that is triggered only for special networks where for example udp is totally blocked.

Hmm. So what TURN was Jitsi using then until this moment when it was added to the installation? ;/