Så avgör du om ett Immich-fel kommer från klienten eller servern

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.

How to Tell Whether an Immich Error Comes From the Client or Server - Zima Store Online

Avgör om ett Immich-fel är klient- eller serverbaserat genom att återskapa samma åtgärd med en variabel ändrad och följa den misslyckade begäran genom hela kedjan.

En mobilbanner som säger ”serverfel” kan fortfarande ha sitt ursprung i klienttillstånd, TLS, en omvänd proxy eller en begäran som servern korrekt avvisade. På samma sätt bevisar ett fel som bara uppstår i webbläsaren inte att webbläsaren är trasig. Lås fast kontot, mediefilen och åtgärden; jämför klienter och anslutningsvägar; använd sedan statuskoder och synkroniserade loggar för att hitta det första lagret där felet uppstår.

Återskapa samma åtgärd på en andra klient

Välj en deterministisk åtgärd, till exempel att logga in, öppna en känd mediefil, ladda upp samma lilla foto eller köra samma sökning. Upprepa den med samma konto i en webbläsare och en mobilklient utan att ändra nätverksvägen. Notera exakt tid och resultat för båda försöken.

En aktuell Immich-rapport där en Android-klient misslyckades medan andra åtkomstvägar testades visar värdet av att jämföra klienter. Orsaken i en enskild tråd kan inte generaliseras, men ett klientspecifikt resultat begränsar kraftigt var du bör undersöka härnäst.

Om alla klienter misslyckas med samma åtgärd vid samma tidpunkt hamnar server, databas, lagring eller en gemensam nätverksväg högre upp på listan. Om bara en klient misslyckas medan en annan lyckas via samma slutpunkt bör du kontrollera klientversion, cachat tillstånd, behörigheter, lokal certifikatverifiering och den exakta begäran som skiljer sig.

Ändra anslutningsvägen utan att ändra konto eller mediefil

Jämför sedan en betrodd lokal anslutningsväg med den vanliga vägen via omvänd proxy, VPN, tunnel eller fjärranslutning. Använd samma konto och åtgärd. Om det fungerar lokalt men inte på distans pekar det bort från själva medieposten och mot lager för DNS, TLS, proxy, brandvägg eller vidarebefordran till uppströmsservern.

ZimaSpaces guide om diagnostik av lokala och fjärranslutna vägar förklarar varför framgång på LAN och framgång via internet är olika bevis. Tillämpa den gränsdragningen på Immich innan du installerar om en mobilapp eller bygger om servern.

Om båda vägarna misslyckas på samma sätt bör du sluta ändra proxyinställningar och i stället granska begäran på applikationssidan. Om bara proxyvägen misslyckas, samla in proxyns status, TLS-resultat, uppströmsserverns svar och tidsgräns. Denna jämförelse med en enda ändrad variabel hindrar ett klientmeddelande från att leda felsökningen till fel lager.

Använd statuskoder som ledtrådar, inte som slutgiltiga besked

HTTP-statusklasser hjälper dig att avgöra var du bör leta, men identifierar inte automatiskt den komponent som orsakade tillståndet. En 4xx-kod betyder ofta att begäran, autentiseringen eller behörigheten inte godkändes; en 5xx-kod visar att en serverkomponent inte kunde slutföra begäran. Proxys kan generera båda klasserna innan Immich ens ser begäran.

Fältguiden för åtkomstloggar lyfter fram statuskod, URL-sökväg, begärans tidpunkt, fjärrvärd och begärans-ID som användbara felsökningsfält. Samla in dessa värden för den enda åtgärd som misslyckas i stället för att skanna tusentals orelaterade rader.

Om proxyn loggar en 502:a eller en tidsgräns utan någon motsvarande Immich-begäran ska du följa uppströmsvägen. Om Immich loggar en begäran och returnerar en deterministisk 4xx-kod bör du granska autentisering, behörigheter eller begärans innehåll. Om klienten rapporterar ett fel men alla lager på serversidan visar 2xx bör du granska klientens tolkning, lokala cache eller efterföljande begäranden.

Featured

ZimaCube 2 personlig molnhem NAS

ZimaCube2

Samordna felfrekvens, fördröjning och serverloggar vid samma tidpunkt

En misslyckad begäran kan vara ett avvikande fall. Återskapa åtgärden fem till tio gånger och notera lyckandefrekvens och fördröjning medan du övervakar relevanta server- och proxyloggar. Om felen ökar vid resursbrist eller kötoppar kan servern vara tillfälligt otillgänglig även om ett andra försök lyckas.

Better Stacks översikt över fel och fördröjning som tjänstesignaler skiljer felfrekvens från fördröjning och trafik. Den modellen hjälper dig att skilja en enstaka felaktigt utformad klientbegäran från en serverväg som försämras först under belastning.

Om serverloggarna innehåller samma undantag för flera klienter bör du betrakta felet som serverbaserat tills motsatsen bevisats. Om servern aldrig ser den misslyckade begäran ska du spåra DNS, TLS, proxy och klientens nätverk. Om bara en klient genererar en annan begärandeform bör du uppdatera eller återställa den klienten efter att ha bevarat tillräckligt med bevis för att bekräfta skillnaden.

Fatta det slutliga beslutet med ett två gånger två-test

Använd två klienter och två anslutningsvägar: webbläsare-lokalt, webbläsare-fjärranslutet, mobil-lokalt och mobil-fjärranslutet. Behåll samma konto och testa samma mediefil. Denna matris skiljer klientspecifika fel från vägspecifika fel och från serverfel som påverkar varje kombination.

En klientorsak stöds när en klient misslyckas på båda vägarna medan en annan fungerar. En vägsorsak stöds när båda klienterna bara misslyckas via en viss väg. En serverorsak stöds när alla fyra kombinationerna återskapar samma applikationsfel och serverloggarna visar samma misslyckade operation.

När du har åtgärdat det identifierade lagret kör du om alla fyra kombinationerna och startar om den berörda komponenten en gång. Avsluta när den ursprungligen felande kombinationen fungerar utan att kontrollfallen slutar fungera. Eskalera med matrisen, tidsstämplarna, HTTP-statusarna, utdrag ur proxy- och serverloggar, klientversioner och en reproducerbar begäran i stället för en generell skärmbild.