I'm running Nginx Proxy Manager in Docker Desktop on Windows with WSL2, while Jellyfin is installed directly on the Windows host. I'm using a DuckDNS domain and initially everything worked for about two days, but requests to the Jellyfin domain now return a 502 Bad Gateway.
Nginx Proxy Manager logs show: connect() failed (111: Connection refused) while connecting to upstream, with the upstream configured as http://192.168.x.x:8096/.
Jellyfin is running normally and works at localhost:8096 on the Windows machine. Other devices on the LAN can also reach it through the Windows computer's LAN IP and port 8096. DuckDNS resolves to the correct public address, and ports 80 and 443 are forwarded correctly. I've tried the Windows LAN IP and host.docker.internal as the proxy destination, added Windows Firewall rules for TCP 8096 on every profile, and restarted Docker, Nginx Proxy Manager, Jellyfin, and the computer.
Since the failure is a connection refusal from inside the container, what is the best way to diagnose the Docker-to-Windows connection? Are there specific Docker Desktop or WSL2 networking settings, firewall rules, or Jellyfin bind-address settings I should check?
3 Answers
The advice to restart Nginx after Jellyfin is running is not the real fix. Nginx Proxy Manager normally retries or reconnects to an upstream; a 502 here points to reachability or firewall configuration. The quickest diagnostic is to run a temporary curl container and test both `http://host.docker.internal:8096` and the host’s LAN IP. Whichever address works should be used as the proxy target. If neither works, inspect Docker Desktop’s host-gateway behavior and Windows Firewall rather than changing DuckDNS or router settings.
First test the connection from inside the Nginx Proxy Manager container rather than testing from Windows. Open a shell in the container and try the Windows host gateway and port 8096, for example with curl or wget. If host.docker.internal:8096 fails from the container, the problem is between Docker and Windows, not DuckDNS or port forwarding.
Also check that Jellyfin is listening on the Windows host’s LAN interface, not only on 127.0.0.1. Since another LAN device can connect, that part is probably already correct, but it is still worth confirming with netstat or Jellyfin’s network settings. In Nginx Proxy Manager, use host.docker.internal as the forward hostname if it resolves from the container, and use HTTP with port 8096.
Check Windows Firewall specifically for traffic coming from the Docker/WSL virtual network. A rule that works for normal LAN clients may not allow connections from Docker Desktop’s virtual adapter. Temporarily permitting TCP 8096 for private networks, or briefly disabling the firewall only as a controlled test, can confirm whether it is the cause. Re-enable it immediately and create a narrow inbound rule once confirmed.
It is also worth checking whether Jellyfin’s port changed after an update or restart and whether another process is listening on 8096. From Windows, verify the listener with a command such as `netstat -ano | findstr :8096`, then compare that with a request made from inside the container.
A 502 with connection refused means Nginx reached the point of trying to contact Jellyfin but the destination rejected or did not accept the connection. DNS for the public domain and router ports 80/443 are not involved in this internal upstream connection.