Immich-inloggningen misslyckas efter att reverse proxyn startas om

Eva Wong

IceWhale author

Eva Wong är Teknisk skribent och den boende fixaren på ZimaSpace. En livslång nörd med en passion för hemma-labb och öppen källkod, hon specialiserar sig på att översätta komplexa tekniska koncept till tillgängliga, praktiska guider. Eva tror att självhosting ska vara roligt, inte skrämmande. Genom sina handledningar ger hon gemenskapen verktyg att avmystifiera hårdvaruinstallationer, från att bygga sin första NAS till att bemästra Docker-containrar.

Immich Login Fails After the Reverse Proxy Restarts - Zima Store Online

Om Immich-inloggningen misslyckas först efter att reverse proxyn har startats om, bör du först fastställa om proxyvägen slutade fungera medan Immich-applikationen och kontot fortfarande fungerar direkt.

En omstart kan synliggöra gamla upstream-adresser, saknat medlemskap i ett gemensamt nätverk, ändrade headers, förändrat cookie-beteende eller en proxyprocess som startade innan dess beroenden var tillgängliga. Testa samma konto via Immichs lokala slutpunkt och det vanliga offentliga värdnamnet och följ sedan det första lagret där de två vägarna skiljer sig åt.

Använd direktåtkomst för att skilja autentiseringsfel från proxyfel

Testa ett känt konto mot Immich-servern via en betrodd lokal väg som kringgår reverse proxyn. Om direktinloggningen lyckas medan det offentliga värdnamnet laddar utan slut, omdirigerar eller returnerar ett upstream-fel, är användarposten och den centrala autentiseringsvägen sannolikt intakta. Begränsa då undersökningen till proxy, TLS, routing och webbläsartillstånd.

Ett communityfall där direktåtkomst fungerade medan proxad inloggning misslyckades illustrerar denna isoleringsmetod. Rapporten gäller en specifik version, så använd den som stöd för att jämföra vägarna i stället för att anta samma grundorsak.

Om både direkt och proxad inloggning misslyckas ska du sluta ändra proxyinställningarna. Kontrollera i stället Immich-tjänstens status, databasanslutningen, kontots tillstånd och serverloggarna. En proxyomstart som inträffade nära felet kan vara en tillfällighet; bypass-testet förhindrar att tidssambandet blir en diagnos utan stöd.

Kontrollera att proxyn når den aktuella upstream-tjänsten för Immich

Efter att proxyn har startats om ska du bekräfta att den kan slå upp och ansluta till Immichs upstream från sitt eget nätverksnamnområde. I Docker är en upstream med tjänstenamn i ett gemensamt användardefinierat nätverk i regel stabilare än en manuellt kopierad container-IP som ändras när en container återskapas.

En diskussion om ett reverse-proxyavbrott med fokus på anslutning mellan proxy och Immich visar varför upstream-nåbarhet och proxykonfiguration med WebSocket-stöd bör kontrolleras innan du återställer konton. Betrakta den exakta konfigurationen som ett anekdotiskt exempel, inte som en mall för alla proxyer.

Starta om proxyn ensam två gånger och kontrollera om dess upstream slås upp till samma tjänst varje gång. Testet är godkänt om anslutningen lyckas direkt utan att adresser redigeras. Om namnupplösning, nätverksmedlemskap eller målport ändras efter återskapandet ska du rätta Compose-nätverksdefinitionen i stället för att starta om stacken upprepade gånger.

Granska vidarebefordrade headers, TLS och cookie-beteende

Inloggningen kan misslyckas även när proxyn returnerar Immich-sidan, eftersom autentiseringen är beroende av hela HTTP-vägen. Jämför proxykonfigurationen före och efter omstarten, inklusive vidarebefordran av värdnamn och schema, HTTPS-terminering, omdirigeringar, eventuell omskrivning av cookies och om ytterligare en proxy eller tunnel också ändrar svaret.

En Immich-diskussion i communityt beskriver ett inloggningsfall med dubbla cookies där proxyhanteringen av cookies gjorde att inloggningen hängde sig. Det är ett avgränsat fall, men påminner om att inspektera webbläsarens svar och cookies i stället för att anta att giltiga inloggningsuppgifter garanterar en lyckad proxad session.

Radera inte alla konton och återställ inte databasen bara för att en webbläsarsession verkar ha fastnat. Använd ett privat fönster eller en annan webbläsare efter att ha sparat de ursprungliga cookiesen och svaret. Om en ren klient fungerar ska du bara rensa det berörda webbplatstillståndet och rätta proxyregeln som skapade den felaktiga cookien eller omdirigeringen.

-15% OFF

ZimaBoard 2 - Minihemmserver för din stora idé

Single board computer zimaboard2

Läs proxyernas åtkomst- och felloggar vid tidpunkten för den misslyckade begäran

Återskapa ett enda inloggningsförsök och notera exakt tid, offentligt värdnamn, klient och returnerad status. Inspektera sedan proxyernas åtkomst- och felloggar runt den begäran. Skilj mellan en begäran som aldrig nådde proxyn, ett 4xx- eller 5xx-fel som skapades av proxyn, ett anslutningsfel mot upstream och en begäran som nådde Immich men fick ett applikationssvar.

Detta felsökningsflöde för NGINX-loggar visar hur status, upstream-fel, tidsmätning för begäran och riktad loggning ger betydligt starkare signaler än att uppdatera inloggningssidan upprepade gånger. Tillämpa samma princip på Caddy, Traefik eller en annan proxy.

Om proxyloggen visar ett lyckat upstream-svar medan webbläsaren inte slutför inloggningen ska du granska omdirigeringar, cookies, TLS och klientens tillstånd. Om proxyn inte kan ansluta till upstream ska du rätta routing eller tjänstens beredskap. Om Immich själv returnerar felet ska du följa motsvarande serverlogg i stället för att behandla proxyn som orsaken.

Kontrollera att åtgärden överlever den omstart som ursprungligen orsakade felet

När den bekräftade orsaken har rättats ska du upprepa den exakta utlösaren: starta bara om reverse proxyn, vänta på dess hälsokontroll och logga in via det offentliga värdnamnet. Öppna sedan en befintlig resurs, ladda upp en liten fil och håll sessionen aktiv tillräckligt länge för att verifiera normal API-trafik.

ZimaSpaces guide om kontrollerade fjärråtkomstvägar beskriver den övergripande gränsdragningen: proxyn är bara ett lager i fjärråtkomsten, så DNS, TLS, autentisering och den privata upstream-tjänsten måste förbli avsiktliga och observerbara.

Godkänn först när inloggningen överlever två proxyomstarter och samma konfiguration startar korrekt efter en fullständig omstart av stacken. Återställ de senaste proxyändringarna om en ny header- eller cookieregel skapade felet. Eskalera med diffen för proxykonfigurationen, begärans status, upstream-felet, tidsstämpeln i serverloggen och resultatet från testet med direkt respektive proxad åtkomst.