Why Does Home Assistant Lose Sessions After a Proxy or DNS Change?
Session loss after a proxy or DNS change usually comes from a mismatch between the URL origin the client uses and the route Home Assistant now sees, not from damaged user accounts.
A browser may still hold cookies and frontend state for the old hostname while a phone resolves the new address, or the proxy may serve the login page but fail the authenticated WebSocket. Start with one private browser window and one direct-LAN test, record the exact scheme and hostname for each result, and avoid deleting all sessions until the failing layer is identified.
Separate One-Client State From a Shared Path Failure
Open Home Assistant in a private window using the intended final URL, then compare it with the affected browser and mobile app. Record whether login completes, whether the dashboard stays connected for five minutes, and whether a page refresh preserves the session. This reversible comparison tests stale client state without changing the server.
A proxy can return the login page while the authenticated frontend later reports an inability to connect. This login-success connection failure demonstrates why rendering HTML is not proof that the whole session path works.
If only the old browser fails and the private window remains stable, remove site data for the old and new Home Assistant origins on that client, then sign in again. If every client fails on the proxy URL but direct LAN access works, preserve client state and move to the proxy path.
Verify WebSocket and Forwarded-Origin Handling
Inspect the browser network view or proxy log during login and watch the WebSocket upgrade, status, disconnect timing, forwarded scheme, forwarded host, and client address. The useful distinction is an HTTP page that loads versus a persistent authenticated channel that upgrades and stays open.
Home Assistant reverse-proxy troubleshooting repeatedly identifies WebSocket forwarding as a separate requirement from ordinary HTTP proxying. Use that mechanism only to interpret the upgrade path, not as proof that one Nginx configuration fits every proxy.
If the upgrade fails, correct only the proxy route, upgrade headers, forwarded scheme, or trusted-proxy boundary that the logs show is wrong. If it succeeds and stays connected, leave the proxy unchanged and investigate DNS and client origin state instead.
Compare DNS Answers and Final URLs
Resolve the Home Assistant hostname from the failing client, a working client, and the proxy host. Compare IPv4, IPv6, split-DNS answers, certificate name, redirect destination, and the URL stored in the companion app. A DNS change is complete only when clients reach the intended endpoint under the same canonical hostname.
The broader relationship between discovery, name resolution, and routing is mapped in the Home Assistant reachability model. Use it to separate a stale DNS answer from a session-layer failure.
If clients resolve different endpoints, wait for the documented TTL or clear the resolver cache on only the affected client and local resolver. Do not create competing temporary hostnames, because each additional origin creates another cookie and redirect boundary.
Retest the Original Session Path and Escalate Narrowly
Sign in through the final public or private URL, keep a live dashboard open, reload a nested view, switch networks once if remote access is part of the design, and repeat after one client restart. A pass requires the same canonical URL, stable WebSocket, and preserved session across the original trigger.
If the clean client passes but one existing client still fails, repair only that client profile or app connection. If all proxy clients fail with the same upgrade or redirect evidence, roll back the last proxy or DNS change and preserve the logs before trying another change.
Escalate with the exact failing URL class, DNS answers, proxy status codes, WebSocket result, timestamps, and client comparison. Stop when two different clients retain sessions through refresh and reconnect; additional cookie or proxy changes then add risk without diagnostic value.
Recommended products
Support & Tips
More to Read
How to Optimize Immich Database Connections for Concurrent Containers
Do not raise max_connections first. Measure Immich sessions, total every container's demand, preserve admin headroom, and tune only the proven bottleneck.
How to Prevent Duplicate Jobs or Imports in Immich
Separate repeated jobs from duplicate assets. Use one canonical ingestion path, control retries and path changes, then test re-entry on a small cohort.
How to Repair Immich After Its Database Volume Fills Up
Never delete PostgreSQL WAL to free space. Stop Immich writes, preserve database state, add safe capacity, recover PostgreSQL, then prevent recurrence.
