Immich Login Fails After the Reverse Proxy Restarts
If Immich login fails only after the reverse proxy restarts, first prove whether the proxy path broke while the Immich application and account still work directly.
A restart can expose stale upstream addresses, missing shared-network membership, header changes, cookie behavior, or a proxy process that came back before its dependencies were reachable. Test the same account through the local Immich endpoint and the normal public hostname, then follow the first layer where the two paths diverge.
Use Direct Access to Separate Authentication From Proxy Failure
Test a known account against the Immich server through a trusted local route that bypasses the reverse proxy. If direct login succeeds while the public hostname spins, redirects, or returns an upstream error, the user record and core authentication path are probably intact. Keep the investigation on proxy, TLS, routing, and browser state.
A community case where direct access worked while proxied login failed illustrates this isolation method. The report is version-specific, so use it to justify comparing paths rather than assuming the same root cause.
If both direct and proxied login fail, stop changing proxy settings. Check Immich service health, database connectivity, account state, and server logs instead. A proxy restart that happened near the failure can be coincidence; the bypass test prevents that timing from becoming an unsupported diagnosis.
Verify the Proxy Can Reach the Current Immich Upstream
After the proxy restarts, confirm it can resolve and connect to the Immich upstream from its own network namespace. In Docker, a service-name upstream on a shared user-defined network is generally more stable than a manually copied container IP that changes when a container is recreated.
A reverse-proxy outage discussion involving proxy-to-Immich connectivity shows why upstream reachability and WebSocket-capable proxying should be checked before account recovery. Treat the exact configuration as anecdotal evidence, not a template for every proxy.
Restart the proxy by itself twice and watch whether its upstream resolves to the same service each time. A pass is an immediate successful connection without editing addresses. If name resolution, network membership, or the target port changes after recreation, fix the Compose network definition rather than repeatedly restarting the stack.
Inspect Forwarded Headers, TLS, and Cookie Behavior
Login can fail even when the proxy returns the Immich page because authentication depends on the complete HTTP path. Compare the proxy configuration before and after the restart, including host and scheme forwarding, HTTPS termination, redirects, any cookie rewriting, and whether a second proxy or tunnel is also modifying the response.
One Immich community discussion documents a duplicate-cookie login case where proxy cookie handling produced a login hang. That is a bounded case, but it is a useful reminder to inspect the browser response and cookies instead of assuming valid credentials guarantee a successful proxied session.
Do not delete all accounts or reset the database because a browser session looks stuck. Use a private window or a second browser after recording the original cookies and response. If a clean client works, clear only the affected site state and correct the proxy rule that created the bad cookie or redirect.
Read Proxy Access and Error Logs at the Failed Request Timestamp
Reproduce one login attempt and record the exact time, public hostname, client, and returned status. Then inspect the proxy access and error logs around that request. Distinguish a request that never reached the proxy, a proxy-generated 4xx or 5xx, an upstream connection failure, and a request that reached Immich but received an application response.
The NGINX log troubleshooting workflow shows how status, upstream errors, request timing, and targeted logging provide a much stronger signal than repeatedly refreshing the login page. Apply the same principle to Caddy, Traefik, or another proxy.
If the proxy log shows a successful upstream response while the browser fails to complete login, inspect redirects, cookies, TLS, and client state. If the proxy cannot connect upstream, fix routing or service readiness. If Immich itself returns the error, follow the corresponding server log instead of treating the proxy as the cause.
Prove the Fix Survives the Restart That Originally Broke It
After correcting the confirmed cause, repeat the exact trigger: restart only the reverse proxy, wait for its health check, and log in through the public hostname. Then open an existing asset, upload a small file, and keep the session active long enough to verify normal API traffic.
The ZimaSpace guide to controlled remote-access paths provides the broader boundary: the proxy is only one layer in remote access, so DNS, TLS, authentication, and the private upstream must remain intentional and observable.
Pass only when login survives two proxy restarts and the same configuration starts cleanly after a full stack restart. Roll back recent proxy changes if a new header or cookie rule created the failure. Escalate with the proxy config diff, request status, upstream error, server log timestamp, and direct-versus-proxied test result.
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.
