Why Does Home Assistant Login Fail After a Reverse Proxy Restart?

If Home Assistant login fails only after a reverse proxy restart, test direct LAN login first and keep the user database unchanged until the proxy path is isolated.

A proxy restart can change its container address, forwarded client information, WebSocket handling, DNS target, or upstream backend without changing any Home Assistant password. That makes account deletion and blanket session resets poor first moves. Compare the direct Home Assistant URL with the normal proxied hostname, save the browser and proxy errors, and identify whether failure occurs before authentication, during the login request, or when the frontend opens its persistent connection.

Start by Separating Home Assistant Authentication From the Proxy Path

Use the same known-good account through the direct local Home Assistant address and through the public or internal proxy hostname. If direct login works while the proxy path fails, the account and Core authentication state are probably healthy enough to leave untouched. If both paths fail, move the investigation back to Home Assistant, the restored state, or the credentials themselves.

A reverse-proxy login case showed direct behavior diverging from the Apache path until WebSocket and proxy details were corrected. That kind of direct-versus-proxy comparison is more diagnostic than repeatedly changing passwords.

Record the HTTP status, redirect chain, browser console error, proxy upstream response, and corresponding Home Assistant log timestamp before changing configuration. A 400 from an untrusted proxy, a failed WebSocket, a redirect to the wrong scheme, and an invalid password are different failures even if the screen displays the same generic inability to connect.

The Four Proxy-Side Causes Leave Different Signatures

The common branches are a changed proxy source address no longer matching the trusted-proxy rule, forwarded headers or scheme changes, broken WebSocket upgrade handling, and routing to the wrong Home Assistant backend. A proxy container recreation can alter one of these while the Home Assistant instance itself remains stable.

A recent reverse-proxy troubleshooting case shows Home Assistant rejecting forwarded traffic until the immediate proxy is placed in the correct trusted range. That trusted-proxy identity check is safer than widening the range permanently: verify which proxy address actually reaches Home Assistant and trust only that boundary.

Use the signatures below and change one branch at a time. Do not leave a broad trusted-proxy range in place after testing; it removes an important protection against spoofed forwarded client addresses.

Cause 1: The Restart Changed the Proxy Source Address

• Signature: requests are rejected immediately and Home Assistant logs identify an untrusted reverse proxy.
• Check: compare the proxy container subnet/address with the configured trusted range.
• IF–THEN: if restoring the correct narrow trusted range fixes login, keep the account and session state unchanged.

Cause 2: Forwarded Host or Scheme No Longer Matches the Public Origin

• Signature: redirects jump between HTTP/HTTPS or alternate hostnames, or cookies appear tied to an unexpected origin.
• Check: compare Host and forwarded scheme before and after restart.
• IF–THEN: if correcting those values fixes the redirect/login cycle, the failure was ingress identity rather than Home Assistant users.

Cause 3: The Login Page Loads but WebSocket Upgrade Fails

• Signature: static UI loads, then the frontend disconnects or cannot finish initialization.
• Check: inspect the browser WebSocket request and proxy upgrade headers.
• IF–THEN: if direct access keeps the WebSocket open while the hostname does not, stay in the proxy layer.

Cause 4: The Proxy Points to a Different or Fresh Backend

• Signature: the server appears newly configured, known users disappear, or server-specific state differs through the proxy.
• Check: compare upstream address, instance identity, and configuration path.
• IF–THEN: if the proxy reaches the wrong container or restored instance, fix routing before touching authentication data.

Use WebSocket Behavior to Avoid Mislabeling a Frontend Failure as Login Failure

Home Assistant's frontend depends on a persistent WebSocket connection after the initial HTTP exchange. A proxy can therefore serve the login page successfully but fail moments later when the connection upgrades or remains open. Users often describe that sequence as a login failure because it occurs immediately after credentials are submitted.

A Home Assistant reverse-proxy setup on Synology reached the login path but still failed until WebSocket upgrade handling was corrected. Checking proxied WebSocket upgrade behavior prevents wasted effort resetting users when the HTTP login path is already healthy.

If the socket fails, validate HTTP/1.1 upgrade handling, timeouts, TLS termination, hostname, and any CDN or authentication middleware in front of the proxy. Keep the change set narrow. Do not add unrelated headers copied from another proxy stack unless the failed request demonstrates why they are needed.

-15% OFF

ZimaBoard 2 - Mini Home Server for Your Big Idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Validate the Fix Through Two Proxy Restarts and a Clean Client

After the matched fix, log in and out through the normal hostname, open a dashboard long enough to confirm the WebSocket remains stable, and repeat from a private browser window or second client. Then restart the proxy twice and reboot the proxy host if its container address or network is part of the suspected cause.

ZimaSpace's comparison of LAN and remote Home Assistant paths applies the same isolation principle: preserve the healthy local application path while testing the extra DNS, TLS, proxy, and routing layers used remotely.

Pass when direct and proxied login both reach the same Home Assistant instance, the expected narrow proxy address is trusted, redirects preserve the intended scheme and host, the WebSocket survives normal use, and a proxy restart does not change the result. Escalate to Home Assistant authentication only when the same known-good account fails on the direct path as well.