How to use several Jitsi servers behind one firewall and one web server?

Hi there

I have a scenario in which I need to make NAT but the official documentation didn’t help me.

Here’s how it is:

  1. FIREWALL - a Mikrotik redirecting all TPC and UDP ports to a Web Server
  2. WEB SERVER - a Debian OS with Nginx
  3. JITSI - several servers with default Jitsi installation

Scenario A (that works - one participant cannot hear or see the other):

  • All TCP goes to the web server
  • All UDP goes to the Jitsi

Scenario B (that does not work - one participant cannot hear or see the other):

  • All packets (TPC and UDP) go to the Web Server that redirects everything to the proper Jitsi server defined by the server name.

Is scenario B even feasable?

Hope you could help with this.

Your best bet is to keep each Jitsi server with its own nginx - this is the default installation. If you have a separate web server fronting your Jitsi installations and (as your post states) your Jitsi installation is default, then you likely have two web servers to negotiate to reach each Jitsi deployment. That’s where your issue lies. Get rid of this:

Thanks for the reply @Freddie
The reason for the

is because I have multiple URLs and this server was meant to act as reverse proxy.

No I wonder if I’d use the Firewall Mikrotik as reverse proxy would be the answer.

You may use one Jitsi setup for multiple domains by cloning Nginx site config and jitsi-meet config.js

Thanks for the reply @emrah

Problem is that I have multiple Jitsi servers already working and all of them have public IPs. We’ll move to another data center with only one public IP available.

I don’t understand if the multiple domains approach would be a single Jitsi instance or if I could pass along all the packets to another server already installed with Jitsi and Nginx.

I’ve read this but couldn’t figure out if my scenario would apply to that.

I found your tutorial at emrah-buster-templates/ at master · emrahcom/emrah-buster-templates · GitHub .

Could it be possible to handle my several server names to redirect to one jitsi meet and use multiple videobridges?

I must say, I have several Jitsi servers because I handle like 7000 connections at once every day. I cannot use only one instance.

Any help would be much appreciated.


It is for one Jitsi cluster for one domain, not for multiple domains by default…

Both are possible:

  • a reverse proxy for http/https and redirecting UDPs directly to JVB
  • a Jitsi cluster for multiple domains

That’s what I first tried to do but couldn’t manage to redirect UDPs separately to each full Jitsi server.

I tried both these on my nginx domain.conf:

server {
       location / {
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
       listen [::]:10000;

        listen [::]:10000 udp;

The TCP ports worked on Nginx but the UDP didn’t. I had to redirect from the firewall to the server directly which is not a solution for me.

The multiple domains would work for only one Jitsi instance, right? I need several because of the traffic I already have.

It seems like a dead end :pensive:

Don’t redirect UDPs on the reverse proxy, redirect them on the firewall. But you should set different UDP ports for each JVB. UDP/10000 for jvb1, UDP/10001 for jvb2,…

So, at this moment, I have on my /etc/jitsi/videobridge/

If I understood you correctly, I could change it to:

In my Firewall I would:

  1. Redirect all TCP packets (80, 443) to a Nginx Reverse Proxy that would redirect then to the LAN IP based on servername like

  2. And redirect UDP packets on port 10001 to LAN IP of, if on port 10002 to LAN IP of and so on…

Is that it?

IIUC you don’t need to use NAT_HARVESTER_LOCAL_ADDRESS and NAT_HARVESTER_PUBLIC_ADDRESS and use the default value of STUN_MAPPING_HARVESTER_ADDRESSES, don’t change it.

The only change you need is SINGLE_PORT_HARVESTER_PORT.


It would then be:

On each of my Jitsi servers I would change the SINGLE_PORT_HARVESTER_PORT only.

I will definitely try this configuration today, looks promising!

Thanks @emrah

I’ll post the results later on.


Our initial tests worked!
We’ll keep testing but it looks everything is fine now.

I’ll post my configs as soon our tests end.


1 Like