Jitsi Meet ports and firewall rules

Jitsi Meet needs very few open ports, and most connection problems come from one of them being closed in a place you did not look, such as a cloud security group rather than the server’s own firewall. This page lists every port, says who connects to it, and shows how to check it from outside.

The ports at a glance

Open these to the internet on the server that runs the Jitsi web app and videobridge:

The official quick install guide lists the same set: 80, 443, 10000/udp and 22, plus 3478/udp and 5349/tcp for coturn.

Open them with ufw (Ubuntu and Debian)

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow 10000/udp
sudo ufw allow from YOUR.IP.ADDRESS to any port 22 proto tcp
# Only if you run coturn on this server:
sudo ufw allow 3478/udp
sudo ufw allow 5349/tcp
sudo ufw enable
sudo ufw status verbose

Replace YOUR.IP.ADDRESS with the address you manage the server from. If your address changes often, sudo ufw allow 22/tcp works too, but keep password logins disabled.

On a cloud server there is usually a second firewall outside the machine: an AWS security group, a Google Cloud firewall rule, a Hetzner or DigitalOcean cloud firewall. Open the same ports there, or ufw alone will not help. Our Jitsi on AWS guide shows the security group rules.

Docker: different defaults

The docker-jitsi-meet setup publishes the web container on 8000 (HTTP) and 8443 (HTTPS) by default, set by HTTP_PORT and HTTPS_PORT in .env. You have two options:

• Set HTTP_PORT=80 and HTTPS_PORT=443 so the container answers on the standard ports directly.
• Keep 8000 and 8443 on localhost and put nginx, Caddy or Traefik in front on 443. See running Jitsi behind a reverse proxy.

In both cases publish 10000/udp straight to the jvb container. Media does not go through a reverse proxy. If you use Jigasi for SIP, the handbook adds 20000-20050/udp.

If the server sits behind NAT or has a private address, the bridge has to advertise its public IP, or participants receive an address they cannot reach. In Docker that is JVB_ADVERTISE_IPS in .env.

Ports that must stay closed

These services listen on the server but only talk to nginx or to each other. Never open them to the internet:

The security hardening checklist covers the rest of the server, including why the Jicofo and bridge statistics endpoints should stay private.

Multi-server setups

When you add videobridges, Jibri recorders or Jigasi on separate machines, they connect back to Prosody on the main server:

• Main server: 80/tcp and 443/tcp to the world, and 5222/tcp from your other Jitsi machines only.
• Each videobridge: 10000/udp to the world. The handbook’s scalable setup also shows 443/tcp on the bridges, for setups where browsers open the bridge WebSocket on the bridge host itself.
• Jibri: needs no inbound ports. It connects out to the main server.

Limit 5222 by source address, for example sudo ufw allow from 10.0.0.12 to any port 5222 proto tcp for each bridge. See scaling Jitsi with more videobridges.

What about port 4443?

Many older tutorials open 4443/tcp for the videobridge’s TCP fallback. Current releases of Jitsi Videobridge no longer have that TCP media port: the bridge configuration only defines the UDP port, 10000 by default. If some participants sit behind networks that block UDP, the supported answer is a TURN server on 5349/tcp, or on 443/tcp with a separate IP address. Our coturn guide walks through it. You can close 4443 unless you configured something custom on it.

Check the ports from outside

Test from a machine that is not the server, so you see what participants see.

# Web app and certificate
curl -sI https://meet.example.com | head -1

# TCP ports
nc -vz meet.example.com 443
nc -vz meet.example.com 80

UDP cannot be checked reliably with nc, because nothing answers an empty packet. Check it on the server instead, while a test meeting with three people runs:

# Is the bridge listening?
sudo ss -ulpn | grep 10000

# Do media packets arrive? (Ctrl+C to stop)
sudo tcpdump -ni any udp port 10000 -c 20

If tcpdump shows nothing while three people are in a meeting, the packets are blocked before they reach the server: look at the cloud firewall, the router’s port forward, or the advertised IP.

Common mistakes

• Opening ufw but not the cloud firewall. Most “Jitsi works for two people only” reports come from this. See video not working with 3 or more participants.
• Forwarding 10000 as TCP. Media uses UDP. A router or security group rule for TCP 10000 does nothing.
• Leaving Docker on 8443 without telling anyone. Participants then need :8443 in the link, and many company networks block it. Use 443.
• Opening 5222 to the world. It exposes Prosody’s client port for no benefit on a single server.
• Closing 80 after installing. Let’s Encrypt renewals use the HTTP challenge on port 80 by default, so certificates quietly expire 90 days later.

Sources

• Jitsi handbook: self-hosting guide for Debian and Ubuntu, “Setup and configure your firewall”
• Jitsi handbook: Docker guide, “External ports”
• Jitsi handbook: scalable setup, firewall sections
• docker-jitsi-meet env.example (HTTP_PORT, HTTPS_PORT, JVB_ADVERTISE_IPS)
• Jitsi Videobridge reference.conf (ICE UDP port 10000, private HTTP server on localhost)
• Jitsi Meet nginx example configuration (Prosody on 5280, Jicofo on 8888, bridge WebSocket on 9090)

Need a hand?

If participants still cannot connect after the ports are open, our engineers can check your firewall, NAT and TURN setup on the live server. Ask an engineer.