This long support thread covers many beginner topics, but its most useful searchable outcome appears on page 3: a Jellyfin server worked locally, DuckDNS resolved, and an SSL certificate existed, yet the public domain returned 502 Bad Gateway. The community eventually separated the problem into three layers: Nginx Proxy Manager reaching Jellyfin, TLS configuration, and router ownership of port 443.
The final breakthrough came when the user disabled the router's own NAS service on port 443. After that, both HTTP and HTTPS reached Jellyfin.
A 502 Error Meant the Proxy Could Not Reach Jellyfin
The community troubleshooting first focused on Nginx Proxy Manager's upstream target. Jellyfin's normal HTTP service was on port 8096; the proxy needed to forward to the Jellyfin container over HTTP rather than treating Jellyfin's optional HTTPS port as the upstream.
Current Jellyfin guidance uses the same model: its Nginx reverse-proxy examples forward normal traffic and WebSockets to Jellyfin on port 8096.
The Proxy and Jellyfin Need a Reachable Docker Path
At one stage, using the container name did not work, so the community helper switched the proxy to Jellyfin's internal Docker address. That made the HTTP path begin working.
Using a container's changing internal IP is less robust than placing both services on a controlled shared Docker network with stable service-name resolution. The source thread documents what worked in that installation, not an ideal Compose design for every server.
Fix HTTP Routing Before Adding SSL
A major source of confusion was changing TLS options while the proxy still could not reach Jellyfin. The community sequence temporarily removed SSL from the proxy host, verified plain HTTP routing first, and only then restored the certificate and forced HTTPS.
This troubleshooting order is more valuable than copying any one IP address: prove upstream routing first, then diagnose TLS.
The Router Was Consuming Port 443
After HTTP finally opened Jellyfin, turning HTTPS back on sent the user to the router's login page. That was the strongest clue in the thread: inbound port 443 was being handled by the router's own NAS/management feature instead of being forwarded to Nginx Proxy Manager.
The user disabled the router's internal NAS service on port 443 and then confirmed that HTTPS worked.
Remote HTTPS Working Did Not Guarantee Local App Discovery
The thread later explored Roku and phone clients. Browser access through the public domain worked, but local auto-discovery and hairpin/NAT-loopback behavior remained inconsistent. The community eventually used DLNA as a practical Roku workaround.
That follow-up should not be mixed with the solved 502/HTTPS path. Remote reverse-proxy routing and local device discovery are separate network behaviors.
This Was Community Networking Help, Not an IceWhale Security Recipe
The detailed reverse-proxy steps came from community participants. Exposing Jellyfin through a domain requires careful router, TLS, authentication, and update practices. Do not publish unrelated ZimaOS administrative services just because port 443 is forwarded to a reverse proxy.
Jellyfin NPM FAQ
What caused the 502 Bad Gateway?
Nginx Proxy Manager could not initially reach the Jellyfin upstream correctly. Once routing was corrected, Jellyfin loaded over HTTP.
Why did HTTPS open the router login page?
The router itself was using port 443. Disabling or moving that router service allowed port 443 to reach Nginx Proxy Manager.
Should NPM proxy Jellyfin over HTTP or HTTPS internally?
The successful thread configuration and Jellyfin's current Nginx examples use HTTP to the Jellyfin service on port 8096, with TLS terminated at the reverse proxy.
Does remote HTTPS make Jellyfin auto-discover on Roku?
No. Client discovery, Wi-Fi isolation, Docker networking, and NAT loopback are separate issues.
