Why Does Jellyfin Login Fail After a Reverse Proxy Restart?
If Jellyfin still accepts a direct local login after the reverse proxy restarts, treat the proxy path as the fault boundary; if direct login fails too, stop changing proxy settings.
A restarted proxy can reload an old upstream port, lose websocket or forwarded-header settings, or present a different hostname and cookie scope. Test the direct Jellyfin URL, then compare proxy logs and authentication requests, changing one layer at a time and avoiding full URL logging that could expose credentials.
Prove Whether Jellyfin Itself Still Accepts Login
Proxy login fails immediately after restart. Begin with the least invasive check: Open the direct local Jellyfin address from the LAN and sign in with the same account.
The useful observation is specific: direct login passes, direct login returns 401, direct URL is unreachable. Record the result before changing another variable. direct-versus-proxy test
Interpret the branch instead of guessing. If direct login passes, keep credentials unchanged and inspect proxy layers; if it fails, read Jellyfin logs and stop proxy edits; if unreachable, fix service or mount health first.
Check Upstream, Port, and Websocket State
Direct login works, or the proxy is the only unreachable path. Begin with the least invasive check: Read the proxy upstream configuration and access log, then request the Jellyfin login endpoint through the proxy.
The useful observation is specific: 502 or connection refused, login page loads but POST fails, websocket errors during playback. Record the result before changing another variable. Known Proxies setting
Interpret the branch instead of guessing. If upstream is refused, repair address or port; if page loads but POST fails, inspect headers and scheme; if only playback websockets fail, keep login changes separate.
Inspect Known Proxies, Headers, Cookies, and DNS
The proxy reaches Jellyfin but authentication still fails or loops. Begin with the least invasive check: Compare one successful direct request and one failed proxied request in redacted logs and browser tools.
The useful observation is specific: Jellyfin sees proxy IP as client, redirect hostname changes, cookie is rejected. Record the result before changing another variable.
Interpret the branch instead of guessing. If Known Proxies or forwarded headers differ, correct only that setting; if cookie or hostname differs, clear only affected site data; if DNS differs, repair the record or port 443 path.
Reload One Layer and Confirm Local and Remote Login
A proxy, header, cookie, or DNS change has been made. Begin with the least invasive check: Reload the proxy once, sign in locally and remotely, restart the proxy again, and confirm one playback session. proxy playback path
The useful observation is specific: both paths pass twice, local passes but remote fails, login passes but playback fails. Record the result before changing another variable.
Interpret the branch instead of guessing. If both login paths pass after a second restart, stop; if only remote fails, stay in proxy or router scope; if playback fails, repair websocket or streaming routing separately.
Recommended products
Support & Tips
More to Read
Can Jellyfin Safely Share a GPU or Accelerator With Another Container?
GPU sharing is conditional: verify device visibility and driver support, then run both workloads and watch for software fallback.
How to Tell Whether a Jellyfin Error Comes From the Client or Server
A Jellyfin error belongs to the client when it follows one device; it belongs to the server when multiple clients fail under the same...
How to Configure Jellyfin Cache and Temporary Storage
Separate durable state, rebuildable cache, and temporary transcode storage, then verify capacity and permissions with a real playback test.
