Why Does Jellyfin Lose Sessions After a Proxy or DNS Change?

A proxy or DNS change should not automatically destroy every Jellyfin login. Session loss usually appears when the change also alters the hostname, scheme, path, backend server identity, authentication layer, or client route that the existing login state expects.

Start by separating a simple DNS record update from an origin change. Keep one known account and device fixed, compare direct LAN access with the normal public hostname, and capture the first failed request before clearing client data. The goal is to identify which boundary changed, not to reset users until the symptom disappears.

First Decide Whether the Public Origin Actually Changed

Write down the old and new scheme, hostname, port, base path, and proxy route. A DNS A or AAAA record can point the same hostname to a different address without changing the browser origin, while moving from one hostname to another or changing an application base path creates a different client boundary. Custom-domain migrations also require the application and authentication path to agree on the new domain; a custom-domain migration checklist makes that DNS-plus-application coupling explicit.

Authentication state is sensitive to where it is presented. A useful session-cookie scope checklist starts by mapping the domain and path attached to each authentication mechanism. Jellyfin clients do not all store state in exactly the same way, so test the affected client instead of assuming browser behavior describes every app.

If the old hostname still works but the new hostname asks for login, treat that as an expected origin migration until proven otherwise. If the same hostname logs everyone out only after the proxy changes, preserve the hostname and move to upstream identity, headers, and proxy-side authentication.

Verify That DNS Still Lands on the Same Intended Jellyfin Instance

Resolve the hostname from a LAN client and, if remote access matters, from an external resolver. Confirm the returned address reaches the intended reverse proxy and that the proxy routes to the expected Jellyfin service, not an old container, test instance, restore clone, or second server with a different persistent database.

A DNS cutover can look like a session problem when it actually sends the client to a different backend. Compare a server-identifying response, user list behavior, library state, and proxy upstream target before touching authentication. If the new route reaches a fresh or restored Jellyfin instance, existing client credentials may no longer represent a valid session there.

The related ZimaSpace workflow for keeping proxy and session-state lifecycles separate is useful here: an ingress restart should not silently replace the application identity or the state that validates existing sessions.

Compare Forwarded Host, Scheme, Path, and Proxy Authentication

Capture the effective proxy configuration after the change. Compare the public Host value, forwarded scheme, client address, websocket upgrade path, redirects, and any authentication middleware with the last working setup. A redirect from HTTPS to an unexpected HTTP or alternate-host URL can make a valid login look like it vanished.

If another authentication layer sits in front of Jellyfin, keep its signing key, cookie name, cookie domain, and session store stable through proxy replacement. Load-balancer designs use sticky-session and routing state to keep a request on the intended backend; changing that layer can create a logout or loop even while Jellyfin itself remains healthy.

Do not copy headers from an unrelated proxy example blindly. Change one value only when the failed request or redirect demonstrates that the current value is wrong. The safest proxy configuration is the smallest one that preserves the public origin and reaches the correct backend consistently.

-15% OFF

ZimaBoard 2 - Mini Home Server for Your Big Idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Use a Clean Client Test Without Erasing the Original Evidence

Before clearing anything, save the failure time, browser or app version, request status, redirect chain, proxy log line, and Jellyfin log entry. Then use a private browser window or a second test device to sign in through the new route. A new login that works proves reachability; it does not explain why the old state became unusable.

Compare three paths in order: direct LAN Jellyfin address, normal hostname from the LAN, and normal hostname from outside the LAN. If direct access works while the hostname fails, keep users and database state unchanged and investigate DNS, TLS, proxy, or middleware. If all paths reject the same known-good account, the problem has moved back inside Jellyfin or its persistent state.

Only clear site-specific state on the affected client after the request-path evidence is captured. Avoid deleting every registered device or revoking all sessions as a first step because that removes the comparison that could distinguish a routing migration from a server-side authentication failure.

Validate the Change Through DNS Expiry, Proxy Restart, and Reboot

After applying the matched fix, let the previous DNS TTL window expire, restart only the proxy, then restart the Jellyfin service and finally reboot the host. Repeat login, logout, playback start, seek, and reconnect tests through the same hostname after each event.

A stable result means the hostname continues to resolve to the intended proxy, the proxy reconnects to the intended Jellyfin instance, existing sessions survive normal component restarts when they should, and a fresh login remains valid. If failures appear only during a full stack boot, use the proxy-to-upstream recovery path to separate readiness from authentication.

Record the final hostname, proxy upstream name, base path, certificate source, and any proxy-side session secret in the deployment notes. Future DNS or proxy changes can then be tested against a known identity contract instead of rediscovering it from browser symptoms.

FAQ

Does changing a DNS record by itself invalidate Jellyfin sessions?

Usually not when the same hostname, scheme, path, and Jellyfin instance remain in use. A DNS change becomes session-relevant when it sends clients to a different backend, changes the public origin, alters TLS or redirects, or changes an authentication layer in front of Jellyfin.

Should I revoke every Jellyfin session after changing a proxy?

Not as the first repair. Preserve one failing client as evidence, confirm the new route reaches the intended server, and test a fresh login separately. Revoke sessions only when you intentionally rotated credentials, suspect token exposure, or have confirmed that old client state must no longer be trusted.