Run Jitsi on Custom Ports

Jitsi-logoJitsi is a video conferencing system that you can install on a private host. Traffic is encrypted from client to server, but is decrypted at the server in order to relay the audio/video to conference participants. I chose to run my own server so that decrypted communication is kept on a server I control running in my garage.

Like most people, I get 1 public IP from my ISP. Since I already run stuff on TCP/443 I needed Jitsi to run on some other port. Since I could not find a step by step guide on how to so this, I worked it out and am posting this here for anyone who wants Jitsi to run on a custom port.

The basic overview on how I got this to work ran like this :
1) Switch router 80/443 ports to point to the host that will host Jitsi.
2) Run through the Jitsi Quick Install
3) Switch router 80/443 back to original host. Add port forward for 444 to Jitsi host.
4) Edit the configs for new port, restart and test.

Here are the details:

Step 1:
I found that when Jitsi installs it is expecting to have the default ports 80 and 443 available. The easiest way to handle this is to just temporarily give the Jitsi host the 80/443 that it needs. I changed my perimeter router to forward TCP/80 and TCP/443 away from the original host to the new Jitsi host. This is just for the quick install and is switched back after the install is completed. Add the additional ports Jitsi needs TCP/4443 and UDP/10000.

So for Step 1, you should have the following ports forwarded into Jitsi:

disabled TCP/80 --> original host tcp/80
disabled TCP/443 --> original host tcp/443
TCP 80 --> Jitsi host tcp/80
TCP 443 --> Jitsi host tcp/443
TCP 4443 --> Jitsi host tcp/4443
UDP 10000 --> Jitsi host udp/10000

Step 2:
The basic Jitsi setup is located here Jitsi Quick Setup. This setup gets you the default jitsi install using nginx and videobridge2. You should be able to connect to your Jitsi service on https port 443 at this point. If you can, then the default Jitsi is done.

Step 3:
Switch your router TCP/80 and TCP/443 back to the original host. Create new port forward entries for TCP/444 to the Jitsi host.
So for Step 3, you should have the following ports forwarded into Jitsi:

TCP/80 --> original host tcp/80
TCP/443 --> original host tcp/443
disabled TCP 80 --> Jitsi host tcp/80
disabled TCP 443 --> Jitsi host tcp/443
TCP 444 --> Jitsi host tcp/444
TCP 4443 --> Jitsi host tcp/4443
UDP 10000 --> Jitsi host udp/10000

Step 4:
To get the Jitsi frontend to answer on TCP/444 we need to edit the following:

Edit /etc/nginx/sites-available/yoursite.conf
Update the port 443 to 444

server {
    listen 444 ssl;
    listen [::]:444 ssl;

Edit /etc/jitsi/meet/yousite-config.js
Update the ‘bosh:’ value to include port 444

    // BOSH URL. FIXME: use XEP-0156 to discover it.
    bosh: '//yoursite:444/http-bind',

Restart nginx service
Restart jitsi-videobridge2 service.

And that’s it. Test it by hitting https://yoursite:444 and you should get the jitsi home page and be able to start a conference.

And finally the Big Problem with this:
LetsEncrypt renews the certificated using port 80 and 443. And we dont have that mapped to Jitsi anymore. So in 90 days your cert will expire. Best option is to use lets encrypt alt method for validation using

I found these alternatives:
1) Run all services on 1 host. Lets Encrypt supports SAN names so you can use nginx to proxy traffic to the correct service based on server name. You only need the 1 cert with multiple names in nginx or this to work.
2) As of Jan of 2019, Lets Encrypt shows: You can use DNS-01 challenges or you can use one of the clients that supports TLS-ALPN-01 challenges (on port 443).

Tagged , , . Bookmark the permalink.

3 Responses to Run Jitsi on Custom Ports

  1. Paul says:

    Hi Mike,
    I’ve got this working nicely in a VM on TrueNAS. My only problem is from a mobile device I can’t connect to the server.
    I’ve tried
    Any ideas?

    • Paul says:

      Ok, I worked it out by setting the server in the app settings and then just type the room name. All working now. Thank you for this article. Really useful.

  2. Paul says:

    actually I do have a small issue at the moment and my get bigger. My main server runs apache and in the log is getting colibri-ws errors in the log. Lots of them.
    GET /colibri-ws/default-id/c9fdfb71f7855f4/bc9fe39b?pwd=7pliom9s5jguj4qjpun4tu3ur HTTP/1.1

    I’m not sure if this applies but I read someone has done something in a httpd.conf file
    ProxyPassMatch ^/colibri-ws/default-id ws://localhost:9090
    ProxyPassReverse ^/colibri-ws/default-id ws://localhost:9090

Leave a Reply

Your email address will not be published. Required fields are marked *

Solve : *
8 × 16 =