.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
Every Jellyfin networking question eventually reduces to four port numbers, and most guides list them without saying which ones you can ignore. Here's the full map: what each port does, which ones deserve a firewall opening and the Docker networking wrinkle that generates that strange "published ports are discarded" warning.
The four Jellyfin default ports
Outof the box, Jellyfin touches these:
- 8096/TCP, the main one. The HTTP web interface and the API every client app talks to. When someone says "the Jellyfin port", this is it.
- 8920/TCP, the optional HTTPS version of the same thing, used only if you configure a certificate inside Jellyfin itself. Most setups never touch it, for reasons below.
- 7359/UDP, client auto-discovery. Apps on your LAN broadcast here to find servers, which is how the app magically lists your server at home. Useless across the internet, harmless on a LAN.
- 1900/UDP, DLNA discovery (SSDP), only relevant if you use DLNA to feed old TVs and consoles. The DLNA feature moved to a plugin in modern Jellyfin, so on a fresh 10.11 server this port does nothing until you add it back.
So the honest minimum is one port: 8096. On a LAN-only setup, add 7359 for the convenience of discovery. Everything else is situational.
Which ports to open where
Three scenarios cover nearly everyone.
Home server, watched only at home. Open nothing in the router. On the machine's own firewall allow 8096/TCP and 7359/UDP from the LAN. Done; this is the setup with no attack surface.
Server reachable from the internet through a reverse proxy. The public side exposes 80 and 443 only; the proxy forwards internally to 8096. In this layout 8096 should be reachable from localhost or the proxy container alone, not from the world, so a strict firewall rule there is the difference between "one login page exposed" and "login page plus raw API exposed". The proxy pattern itself is in our Jellyfin remote access guide.
Server on a VPS. Same as the proxy scenario, with one addition: VPS providers give you a cloud firewall in front of the machine (ours sits in the panel of every Jellyfin VPS plan), and the sane rule set is 443 open, 80 open for certificate renewal, 22 restricted to your IP and everything else, 8096 included, closed. Discovery ports mean nothing on a VPS; there's no LAN to discover you.
On Ubuntu the firewall side is two lines:
sudo ufw allow from 192.168.1.0/24 to any port 8096 proto tcp
sudo ufw allow from 192.168.1.0/24 to any port 7359 proto udpAdjust the subnet to yours, and on a VPS drop the LAN rules entirely in favor of the proxy-only layout.
Changing the Jellyfin port
Dashboard » Networking, and the HTTP port field is right at the top. Change 8096 to whatever you need, save, restart the server. Two warnings from experience. Every client that stored the old address needs the new port typed in; there's no push update, and the "server not found" tickets after a port change are always this. And resist moving Jellyfin to 80 or 443 directly; those belong to a reverse proxy, which brings proper HTTPS and takes the renewal problem with it.
Behind a proxy, also fill in the "Known proxies" field on the same Networking page with your proxy's IP or container name, or every viewer in your logs appears to connect from the proxy's address, which turns the security log into porridge.
Why almost nobody uses 8920...
Jellyfin's built-in HTTPS on 8920 requires you to obtain, convert and manually renew a certificate, then teach every client the nonstandard port. A reverse proxy does all of that automatically on the port browsers expect. The built-in TLS made sense in the era before Let's Encrypt automation; today it's the harder path to a worse result.
I just keep 8920 closed everywhere and have yet to regret it.
Docker port mapping + the host-network warning
In a compose file, the mapping "8096:8096" publishes container port 8096 on the host. The left number is yours to change; "9096:8096" serves Jellyfin on host port 9096 with zero changes inside the container. This is the cleanest way to run two instances or dodge a conflict.
The famous warning, "published ports are discarded when using host network mode", appears when a compose file contains both network_mode: host and a ports: section. Host mode gives the container the host's network stack directly, so there's nothing to publish; the ports list is ignored and Docker tells you so. Fix it by deleting one of the two: keep the ports mapping for the isolated default (my choice on any internet-facing box, as argued in the install guide) or keep host mode when you genuinely need LAN discovery and DLNA to work from inside a container, accepting that every port Jellyfin listens on is now open on the host.
Checking what's listening
When a client can't connect and you're not sure which layer is lying:
ss -tulpn | grep -E '8096|8920|7359|1900'shows what Jellyfin is bound to locally, and from another machine curl -I http://SERVER_IP:8096 answers with an HTTP header if the path is clear. Local yes, remote no means firewall or router; local no means Jellyfin isn't listening where you think, check Dashboard » Networking and the container mapping. That two-step test settles ninety percent of "is it the port?" mysteries before they cost an evening.
