Why Does Plex Lose Sessions After a Proxy or DNS Change?
Plex can lose sessions after a proxy or DNS change when clients reconnect through a different hostname, route, certificate, or cached endpoint.
Keep the server and media unchanged while testing the connection path. Existing sessions may survive longer than new ones because clients cache addresses and authentication state differently. Reproduce one local and one proxied session, then compare DNS resolution, redirects, websocket behavior, and the address the client actually uses.
Confirm Direct Plex Access Still Works
A proxy problem is much easier to isolate when the backend is proven healthy. Test the same account and media directly on the LAN before changing certificates or database state.
The backend can be tested separately from the public hostname when a Plex reverse-proxy route keeps those two paths distinct.
Open Plex directly, play a known item, and record the server address. If direct access fails too, leave DNS and proxy rules unchanged until the backend works.
Check DNS Before Authentication
A new hostname or address can send clients to the wrong endpoint even though the login error looks like an account problem. Compare what each client resolves, especially when caches or split DNS are involved.
Interface route metrics can also change which network path is used after a DNS update, so verify both resolution and route selection.
Resolve the public and local names from affected and working clients. Flush only the failing client cache after you have captured the wrong result.
Verify Proxy Rewrites and Websocket Paths
Subpath rewrites, headers, redirects, and websocket upgrades can break sessions after a proxy change while a simple web page still loads. The full client flow must be tested.
A proxy change can affect root-relative assets and integrity behavior when Plex proxy path rewriting is involved, so it is more than a basic port forward.
Watch browser network errors and proxy logs during login and playback. If the proxied path fails while direct access works, fix the proxy layer before resetting users. After the proxy is stable, verify the same remote Plex streaming path from an external network and keep that result as the baseline for future DNS or edge changes.
Re-Test With One Known Session Path
After DNS and proxy behavior are stable, create a fresh session and confirm the client stays on the intended hostname. That prevents a cached old route from making a broken configuration look healthy.
An otherwise valid service connection can fail when reply traffic leaves through the VPN route instead of the interface that received the request.
Test from one external network and one local network with the same account. If only one path drops sessions, continue with routing and edge policy rather than server state.
Recommended products
Support & Tips
More to Read
Should You Back Up Jellyfin Live or Stop the Service First?
Prefer stopped-service backups for simplicity; use live snapshots only when application state is captured consistently and restores are tested.
Why Does Jellyfin Run Hot or Noisy When Nobody Is Streaming?
Idle heat usually means background work or a shared-host workload, so identify the active process and scheduled task before changing cooling or hardware.
When Should You Rebuild Instead of Repairing Jellyfin?
Choose rebuild over repair when runtime drift is the problem and persistent state is backed up; do not “rebuild” by deleting the only good...
