Inloggen bij Immich mislukt nadat de reverse proxy opnieuw is gestart

Als het inloggen bij Immich alleen mislukt nadat de reverse proxy opnieuw is gestart, stel dan eerst vast of het proxytraject is uitgevallen terwijl de Immich-toepassing en het account rechtstreeks nog wel werken.

Een herstart kan verouderde upstreamadressen, ontbrekend lidmaatschap van een gedeeld netwerk, gewijzigde headers, ander cookiegedrag of een proxyproces aan het licht brengen dat weer beschikbaar kwam voordat de afhankelijkheden bereikbaar waren. Test hetzelfde account via het lokale Immich-eindpunt en via de normale openbare hostnaam en volg vervolgens de eerste laag waar de twee paden van elkaar afwijken.

Gebruik rechtstreekse toegang om authenticatie van een proxyprobleem te onderscheiden

Test een bekend account tegen de Immich-server via een vertrouwde lokale route die de reverse proxy omzeilt. Als rechtstreeks inloggen lukt terwijl de openbare hostnaam blijft laden, doorstuurt of een upstreamfout retourneert, zijn het gebruikersrecord en het centrale authenticatiepad waarschijnlijk intact. Richt het onderzoek dan op de proxy, TLS, routering en de browserstatus.

Een communitygeval waarin rechtstreekse toegang werkte terwijl inloggen via de proxy mislukte illustreert deze isolatiemethode. Het rapport is versiespecifiek, dus gebruik het om paden met elkaar te vergelijken en ga niet zonder meer uit van dezelfde hoofdoorzaak.

Als zowel rechtstreeks als via de proxy inloggen mislukt, stop dan met het wijzigen van proxy-instellingen. Controleer in plaats daarvan de status van de Immich-service, de databaseverbinding, de accountstatus en de serverlogboeken. Een proxystart die ongeveer samenviel met de fout kan toeval zijn; de bypass-test voorkomt dat die timing tot een ongefundeerde diagnose leidt.

Controleer of de proxy de huidige Immich-upstream kan bereiken

Controleer na het opnieuw starten van de proxy of deze de Immich-upstream vanuit zijn eigen netwerknaamruimte kan oplossen en bereiken. In Docker is een upstream met een servicenaam op een gedeeld door de gebruiker gedefinieerd netwerk doorgaans stabieler dan een handmatig gekopieerd container-IP-adres dat verandert wanneer een container opnieuw wordt aangemaakt.

Een discussie over een reverse-proxy-uitval rond connectiviteit tussen proxy en Immich laat zien waarom bereikbaarheid van de upstream en proxying met WebSocket-ondersteuning moeten worden gecontroleerd voordat je accounts gaat herstellen. Beschouw de exacte configuratie als anekdotisch bewijs, niet als sjabloon voor elke proxy.

Start de proxy twee keer afzonderlijk opnieuw en controleer telkens of de upstream naar dezelfde service wordt opgelost. Het resultaat is goed als er onmiddellijk verbinding wordt gemaakt zonder adressen te wijzigen. Als naamresolutie, netwerk lidmaatschap of de doelpoort na het opnieuw aanmaken verandert, corrigeer dan de Compose-netwerkdefinitie in plaats van de stack steeds opnieuw te starten.

Controleer doorgestuurde headers, TLS en cookiegedrag

Inloggen kan mislukken, zelfs wanneer de proxy de Immich-pagina retourneert, omdat authenticatie afhankelijk is van het volledige HTTP-pad. Vergelijk de proxyconfiguratie vóór en na de herstart, inclusief het doorsturen van host en schema, TLS-beëindiging, eventuele cookieherschrijvingen en de vraag of een tweede proxy of tunnel het antwoord ook aanpast.

Een Immich-communitydiscussie beschrijft een inloggeval met dubbele cookies waarbij cookieverwerking door de proxy het inloggen liet vastlopen. Dat is een afgebakend geval, maar het herinnert eraan dat je de browserrespons en cookies moet controleren in plaats van ervan uit te gaan dat geldige inloggegevens automatisch een succesvolle sessie via de proxy opleveren.

Verwijder niet alle accounts en reset de database niet omdat een browsersessie lijkt vast te zitten. Gebruik een privévenster of een tweede browser nadat je de oorspronkelijke cookies en respons hebt vastgelegd. Als een schone client wel werkt, wis dan alleen de status van de betreffende site en corrigeer de proxyregel die de verkeerde cookie of omleiding heeft veroorzaakt.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Lees toegangs- en foutlogboeken van de proxy rond het tijdstip van de mislukte aanvraag

Herhaal één inlogpoging en noteer het exacte tijdstip, de openbare hostnaam, de client en de geretourneerde status. Bekijk vervolgens de toegangs- en foutlogboeken van de proxy rond die aanvraag. Maak onderscheid tussen een aanvraag die de proxy nooit heeft bereikt, een door de proxy gegenereerde 4xx- of 5xx-fout, een verbindingsfout met de upstream en een aanvraag die Immich wel heeft bereikt maar een applicatierespons ontving.

De probleemoplossingsworkflow voor NGINX-logboeken laat zien hoe status, upstreamfouten, aanvraagtijd en gerichte logregistratie een veel sterker signaal opleveren dan de inlogpagina steeds opnieuw laden. Pas hetzelfde principe toe op Caddy, Traefik of een andere proxy.

Als het proxylogboek een geslaagde upstreamrespons toont terwijl de browser het inloggen niet voltooit, controleer dan omleidingen, cookies, TLS en de clientstatus. Als de proxy geen verbinding met de upstream kan maken, corrigeer dan de routering of de gereedheid van de service. Als Immich zelf de fout retourneert, volg dan het bijbehorende serverlogboek in plaats van de proxy als oorzaak te behandelen.

Toon aan dat de oplossing bestand is tegen de herstart die het probleem oorspronkelijk veroorzaakte

Herhaal na het corrigeren van de vastgestelde oorzaak exact de oorspronkelijke trigger: start alleen de reverse proxy opnieuw, wacht tot de gezondheidscontrole is geslaagd en log in via de openbare hostnaam. Open vervolgens een bestaand item, upload een klein bestand en houd de sessie lang genoeg actief om normaal API-verkeer te verifiëren.

De ZimaSpace-handleiding over gecontroleerde paden voor externe toegang geeft de bredere afbakening: de proxy is slechts één laag van externe toegang, dus DNS, TLS, authenticatie en de private upstream moeten bewust zijn ingericht en controleerbaar blijven.

De test is pas geslaagd wanneer inloggen twee proxystarts overleeft en dezelfde configuratie na een volledige stackherstart schoon opstart. Draai recente proxywijzigingen terug als een nieuwe header- of cookieregel de fout heeft veroorzaakt. Escaleer met het configuratieverschil van de proxy, de aanvraagstatus, de upstreamfout, het tijdstip in het serverlogboek en het resultaat van de rechtstreekse versus proxied test.