.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
Jellyseerr is the request layer most Jellyfin households eventually add, and "Unable to connect to Jellyfin server" during its setup is close to a universal experience. The error is honest but vague; underneath it are four distinct failures, and which one you have is determined almost entirely by how the two apps are deployed. Find your setup shape below, apply its fix, done in ten minutes.
First, understand what Jellyseerr needs
During setup, Jellyseerr asks for your Jellyfin URL and then connects to it server-to-server; your browser is not in that conversation. This is the misunderstanding behind half the failures: the address that works in your browser proves nothing about what the Jellyseerr process can reach from where it runs. The URL it needs is one that resolves and routes from Jellyseerr's own network position, plus a Jellyfin account to authenticate with (use an admin account for setup, per the official Seerr docs, which also let you set a friendlier external URL for users separately).
Shape 1: Both in Docker (the big one)
Two containers, and you typed http://localhost:8096 or http://127.0.0.1:8096 into Jellyseerr. Inside a container, localhost means that container, not the host machine, so Jellyseerr is knocking on its own empty port 8096. The clean fix is a shared Docker network with container names as hostnames:
services:
jellyfin:
image: jellyfin/jellyfin
networks: [media]
# ...
jellyseerr:
image: ghcr.io/seerr-team/seerr:latest
networks: [media]
# ...
networks:
media:
driver: bridgeThen the URL in Jellyseerr is simply http://jellyfin:8096; Docker's internal DNS resolves the container name and the connection stays off the public network entirely. Same compose file gets this for free (compose puts services on a shared default network); split compose files need the explicit named network in both. The second-best fix, pointing Jellyseerr at the host's LAN IP (http://192.168.1.20:8096), also works and breaks the day your DHCP lease moves; container names don't move, which is why they're the answer I give.
Shape 2: Jellyseerr in Docker, Jellyfin on the host
Same localhost trap, one different fix: the container needs a route to its host. Use the LAN IP, or Docker's magic hostname for exactly this, http://host.docker.internal:8096, adding the small compose stanza Linux requires:
extra_hosts:
- "host.docker.internal:host-gateway"One more Linux-specific trap here: a host firewall that allows LAN traffic can still block the Docker bridge subnet. If the URL is right and connections still refuse, ufw allow from 172.16.0.0/12 to any port 8096 is the missing rule more often than not.
Shape 3: Different machines entirely
Jellyseerr on a VPS, Jellyfin at home, or the reverse. Now it's ordinary networking: the URL must be reachable across the internet or a VPN, so a LAN address in the URL field guarantees the error. Point it at your public Jellyfin address (reverse-proxied HTTPS, exactly what our Jellyfin remote access guide builds) or put both machines on a shared tailnet and use the VPN address. If Jellyfin sits behind HTTPS, tick Jellyseerr's SSL option and use port 443 rather than 8096, another classic mismatch: https://...:8096 fails because 8096 speaks plain HTTP. Which port carries what is the Jellyfin ports guide's whole subject.
Shape 4: The URL is fine and auth fails anyway
Different error texture: Jellyseerr reaches the server and the credentials step fails. Three causes cover it. The account is signed in with the wrong username shape (use the Jellyfin username, not an email, unless your login is genuinely an email). The account is disabled or has a policy restriction in Jellyfin's user settings.
Or a reverse proxy in the middle strips headers or applies an auth wall (Cloudflare Access and friends) that the API call can't answer; test against the direct internal URL to convict the proxy layer. For proxy-fronted setups, connecting Jellyseerr to Jellyfin's internal address and reserving the fancy public URL for the "external URL" field is both faster and more reliable.
Verify and lock it in
The setup wizard's connection test going green is the proof, followed by libraries appearing on the next settings page; select them and run the initial scan. Then one durability habit: whatever URL worked, write it into a comment in your compose file. Six months from now, when a container rename or IP change resurfaces the error, the comment turns an evening of rediscovery into a thirty-second fix. Speaking from experience there, unfortunately.
If you're building this stack fresh rather than debugging it, our Jellyfin install guide starts at zero and this whole article becomes the ten-minute add-on it should be, and the Docker VPS template gives the pair a home with compose preinstalled.
