Varför uppstår en inloggningsloop för privat moln endast utanför hemmets nätverk?
En inloggningsloop som endast uppstår utifrån betyder vanligtvis att den fjärrproxyvägen ändrar schema, värdnamn, cookie, callback eller sessionsinformation som appen ser.
Inomhus kan en webbläsare ansluta direkt till privatmolnstjänsten via dess lokala adress, medan fjärranvändare går in via offentlig DNS, TLS-terminering, en omvänd proxy, forward-auth-lager, tunnel eller identitetsleverantör. Uppgifterna kan accepteras korrekt men nästa förfrågan går tillbaka till inloggningssidan eftersom sessionscookien inte sparas eller returneras, backend tror att HTTPS är HTTP, callback-URL skiljer sig från det registrerade värdet eller applikationen genererar omdirigeringar för sitt interna värdnamn.
Fånga den Exakta Omdirigeringsloopen i Webbläsaren
Öppna webbläsarens nätverkspanel innan du loggar in utifrån hemmet. Spara förfrågningsloggen och registrera varje statuskod, Location-header, Set-Cookie-header, förfrågningsvärdnamn och om sessionscookien visas vid nästa förfrågan.
En felsökningsguide för Keycloak rekommenderar att observera hela omdirigeringskedjan eftersom saknade vidarebefordrade headers, cookie-omfång och callbacks alla kan skapa en oändlig inloggningsomdirigering även när lösenordssteget lyckas.
Om ingen cookie utfärdas, undersök applikationen och proxyresponsen. Om en cookie utfärdas men inte returneras, kontrollera dess domän, sökväg, Secure och SameSite-attribut. Om cookien returneras men appen ändå omdirigerar, fortsätt med proxytrust och sessionslagring.
Jämför Lokala och Offentliga Värdnamn och Scheman
Skriv ner den exakta lokala URL:en och den offentliga URL:en, inklusive http eller https, värdnamn, port och delväg. Testa om applikationen har en konfigurerad kanonisk eller extern bas-URL.
En analys av WordPress bakom en omvänd proxy förklarar att när backend tror att förfrågan är HTTP kan den omdirigera till HTTPS upprepade gånger medan proxyn fortsätter att terminera TLS. Loopen kommer från felaktig HTTPS-detektion bakom proxyn snarare än från användarens lösenord.
Använd ett offentligt värdnamn konsekvent för fjärrinloggning, callbacks och cookies. Blanda inte den offentliga domänen, privata IP, interna värdnamnet och alternativa portar inom ett autentiseringsflöde om inte applikationen uttryckligen stöder flera betrodda ursprung.
Verifiera Vidarebefordrade Host- och Protokollheaders
Kontrollera konfigurationen av den omvända proxyn och backendloggar för X-Forwarded-Proto, X-Forwarded-Host, X-Forwarded-Port och den ursprungliga klientadressen. Bekräfta att applikationen endast litar på den kända proxyn och rekonstruerar samma offentliga URL som webbläsaren använde.
En qBittorrent-fallstudie med omvänd proxy noterar att en inloggningssida kan laddas och acceptera uppgifter medan en felaktig Host- eller HTTPS-header förhindrar att den autentiserade sessionen känns igen.
Om proxyn skickar rätt offentliga värden men appen ignorerar dem, konfigurera applikationens trusted-proxy och external-URL-inställningar. Om proxyn utelämnar dem, lägg till de smala nödvändiga headers istället för att vidarebefordra varje klientlevererad header oförändrad.
Inspektera Cookie-domän, Sökväg, Secure och SameSite
Jämför sessionscookien som skapas lokalt med den som skapas via den offentliga domänen. En cookie som är begränsad till ett internt värdnamn, fel föräldradomän, annan delväg eller icke-säkert sammanhang kanske inte följer med den omdirigerade offentliga förfrågan.
Extern åtkomst lägger ofta till en annan autentiseringsdomän eller cross-site callback. SameSite-begränsningar och Secure-krav kan därför påverka det fjärrflödet även om en direkt lokal inloggning aldrig lämnar ett ursprung.
Rensa cookies endast för de berörda privatmolnsdomänerna, reproducera loopen och inspektera de nya attributen. Korrigera applikationens eller proxyns offentliga URL och cookie-inställningar; använd inte webbläsaromfattande cookie-avslappning som en permanent serverlösning.
Kontrollera OAuth-, OIDC- eller Forward-Auth Callback-Identitet
Om privatmolnet använder en identitetsleverantör eller forward-auth-tjänst, jämför callback-URL:en som genereras av appen, registreras hos leverantören och nås av webbläsaren. Schema, värdnamn, port, sökväg och avslutande snedstreck måste alla matcha exakt.
En NGINX-community-fallstudie beskriver en fjärrinloggningsloop där TLS termineras vid proxyn men backend ser HTTP, så applikationen kan inte upprätthålla den förväntade säkra externa sessionen.
Testa callback-endpointen direkt via den offentliga domänen och bekräfta att den når rätt proxyväg och backend. Om autentiseringen lyckas men callbacken startar om inloggningen, inspektera state, nonce, cookie-persistens, klocksynkronisering och den exakta omdirigerings-URI:n.
Verifiera Den Fullständiga Fjärrsessionen Utan Att Bypassa Proxyn
Efter att ha åtgärdat en orsak, börja med ett rent privat fönster på ett externt nätverk. Logga in, uppdatera instrumentpanelen, öppna en fil, vänta längre än den korta sessionsintervallet och anslut igen för att bekräfta att sessionen överlever vanlig navigering.
ZimaSpace-guiden för kontrollerad fjärråtkomst till NAS ger den omgivande säkerhetsgränsen: att fixa loopen bör inte kräva att backend exponeras direkt eller att autentisering inaktiveras.
Problemet är löst först när lokala och fjärranvändare når det avsedda värdnamnet, proxyn bevarar den offentliga förfrågningsidentiteten, cookien förblir giltig och hela inloggnings- och callback-flödet lyckas upprepade gånger. Ta bort tillfälliga omvägar och utförliga autentiseringsloggar efter verifiering.
Rekommenderade produkter
Support och tips
Mer att läsa
Varför återskapar en återställning av en Docker-volym filinnehållet men tar bort utökade attribut?
En felsökning av volymåterställning som omfattar inventering av xattr, alternativ för tar och Rsync, namnrymder, stöd för måldestinationen, behörigheter, etiketter, appmetadata och tester.
Varför behåller en körande container sin gamla minnesgräns efter att Compose-filen har ändrats?
En minnesgränsdiagnos som omfattar aktiva cgroups, omstart kontra återskapande, Compose-fält, hårda och mjuka gränser, överordnade scope, växlingsutrymme och körningsheapar.
Varför ogiltigförklarar en omstart av en omvänd proxy varje session för en självhostad app?
En sessionsförlustdiagnos som omfattar omstartens omfattning, cookie-ägarskap, rotation av hemligheter, cachebaserade sessioner, sticky routing, autentiseringsgatewayer och återställning.
