Why Does a Private Cloud Login Loop Appear Only Outside the Home Network?
An outside-only login loop usually means the remote proxy path changes the scheme, hostname, cookie, callback, or session information seen by the app.
Inside the home, a browser may connect directly to the private-cloud service over its local address, while remote users enter through public DNS, TLS termination, a reverse proxy, forward-auth layer, tunnel, or identity provider. The credentials can be accepted correctly yet the next request returns to the login page because the session cookie is not stored or returned, the backend thinks HTTPS is HTTP, the callback URL differs from the registered value, or the application generates redirects for its internal hostname.
Capture the Exact Redirect Loop in the Browser
Open the browser network panel before logging in from outside the home. Preserve the request log and record each status code, Location header, Set-Cookie header, request hostname, and whether the session cookie appears on the next request.
A Keycloak troubleshooting guide recommends observing the full redirect chain because missing forwarded headers, cookie scope, and callbacks can all create an infinite login redirect even when the password step succeeds.
If no cookie is issued, investigate the application and proxy response. If a cookie is issued but not returned, inspect its domain, path, Secure, and SameSite attributes. If the cookie returns but the app still redirects, continue with proxy trust and session storage.
Compare the Local and Public Hostnames and Schemes
Write down the exact local URL and public URL, including http or https, hostname, port, and subpath. Test whether the application has one configured canonical or external base URL.
A reverse-proxy WordPress analysis explains that when the backend believes the request is HTTP, it can redirect to HTTPS repeatedly while the proxy continues terminating TLS. The loop comes from incorrect HTTPS detection behind the proxy rather than from the user’s password.
Use one public hostname consistently for remote login, callbacks, and cookies. Do not mix the public domain, private IP, internal hostname, and alternate ports inside one authentication flow unless the application explicitly supports multiple trusted origins.
Verify Forwarded Host and Protocol Headers
Check the reverse proxy configuration and backend logs for X-Forwarded-Proto, X-Forwarded-Host, X-Forwarded-Port, and the original client address. Confirm the application trusts only the known proxy and reconstructs the same public URL the browser used.
A qBittorrent reverse-proxy case notes that a login page can load and accept credentials while a mismatched Host or HTTPS header prevents the authenticated session from being recognized.
If the proxy sends the correct public values but the app ignores them, configure the application’s trusted-proxy and external-URL settings. If the proxy omits them, add the narrow required headers rather than forwarding every client-supplied header unchanged.
Inspect Cookie Domain, Path, Secure, and SameSite
Compare the session cookie created locally with the one created through the public domain. A cookie scoped to an internal hostname, wrong parent domain, different subpath, or non-secure context may not accompany the redirected public request.
Outside access often adds another authentication domain or cross-site callback. SameSite restrictions and Secure requirements can therefore affect the remote flow even though a direct local login never leaves one origin.
Clear cookies only for the affected private-cloud domains, reproduce the loop, and inspect the new attributes. Correct the application or proxy’s public URL and cookie settings; do not use browser-wide cookie relaxation as a permanent server-side fix.
Check OAuth, OIDC, or Forward-Auth Callback Identity
If the private cloud uses an identity provider or forward-auth service, compare the callback URL generated by the app, registered at the provider, and reached by the browser. Scheme, hostname, port, path, and trailing slash may all need to match exactly.
An NGINX community case describes a remote login loop where TLS terminates at the proxy but the backend sees HTTP, so the application cannot maintain the expected secure external session.
Test the callback endpoint directly through the public domain and confirm it reaches the correct proxy route and backend. If authentication succeeds but the callback restarts login, inspect state, nonce, cookie persistence, clock synchronization, and the exact redirect URI.
Validate the Full Remote Session Without Bypassing the Proxy
After correcting one cause, start with a clean private window on an external network. Log in, refresh the dashboard, open a file, wait beyond the short session interval, and reconnect to confirm the session survives ordinary navigation.
The ZimaSpace guide to controlled remote NAS access provides the surrounding security boundary: fixing the loop should not require exposing the backend directly or disabling authentication.
The issue is resolved only when local and remote users reach the intended hostname, the proxy preserves public request identity, the cookie remains valid, and the complete login and callback flow succeeds repeatedly. Remove temporary bypasses and verbose authentication logs after verification.
Recommended products
Support & Tips
More to Read
Why Does a Docker Volume Restore Recreate File Contents but Drop Extended Attributes?
A volume-restore diagnosis covering xattr inventory, tar and Rsync options, namespaces, destination support, privileges, labels, app metadata, and tests.
Why Does a Running Container Keep Its Old Memory Limit After the Compose File Changes?
A memory-limit diagnosis covering live cgroups, restart versus recreation, Compose fields, hard and soft limits, parent scopes, swap, and runtime heaps.
Why Does Restarting a Reverse Proxy Invalidate Every Session for One Self-Hosted App?
A session-loss diagnosis covering restart scope, cookie ownership, secret rotation, cache-backed sessions, sticky routing, auth gateways, and recovery.
