Så testar du om DNS orsakar anslutningsfel i Immich

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 Test Whether DNS Is Causing Immich Connection Failures - Zima Store Online

DNS är en sannolik orsak till Immich-problem endast när den klient som misslyckas inte kan översätta det exakta Immich-värdnamnet till den adress som ska hantera det, eller när svaret ändras mellan resolvrar, nätverk eller över tid.

Testa namnupplösning separat från applikationens nåbarhet. En lyckad anslutning på IP-nivå kan visa att en väg och port finns, men den bevisar inte att HTTPS, omvänd proxy-routing, certifikat eller värdnamnsbaserade regler fungerar utan värdnamnet. Det säkraste arbetsflödet är att dokumentera det exakta namnet som misslyckas, slå upp det från den berörda klienten, jämföra resolvrar och sedan upprepa den ursprungliga Immich-åtgärden efter en ändring i DNS-lagret.

Definiera det exakta värdnamnet och felvägen

Dokumentera det värdnamn som den Immich-klient som misslyckas faktiskt använder, vilket nätverk den är ansluten till, tidpunkten för felet och om felet påverkar webbappen, mobilappen eller båda. Börja inte med ett generiskt test, till exempel att slå upp en orelaterad offentlig domän, eftersom det bara visar att någon DNS-väg fungerar.

Jämför samma värdnamn från en fungerande klient och den klient som misslyckas. Dokumentera alla A- och AAAA-svar, vilken resolver som svarade och om klienten finns i hemnätverket, använder mobildata eller är bakom ett VPN. Olika svar kan vara avsiktliga vid split-DNS, men de måste ändå leda varje klient till en nåbar slutpunkt.

Testa som kontroll om den förväntade serveradressen och porten kan nås utan att förlita dig på den normala DNS-frågan. Betrakta detta endast som en avgränsning av nätverksvägen: HTTPS-certifikat, SNI, omvända proxyservrar och virtuella värdar kan fortfarande avvisa en IP-baserad begäran även när tjänsten fungerar.

Fråga DNS från klienten som misslyckas, inte bara från servern

Kör en DNS-fråga på den enhet eller i den miljö där felet faktiskt uppstår. Om Immich-klienten finns bakom ett VPN, en privat DNS-profil, en containerstub eller en routertillhandahållen resolver kan en fråga från själva servern använda en annan resolverväg och dölja problemet.

Fråga först efter det felande värdnamnet via klientens standardresolver och fråga sedan uttryckligen via en känd jämförelseresolver eller den avsedda interna resolvern. En riktad dig-fråga visar det returnerade svaret, den svarande servern, statusen och frågetiden, så att du kan se om felet följer en viss resolver.

Upprepa frågan flera gånger i stället för att lita på ett enda lyckat resultat. Dokumentera NXDOMAIN, SERVFAIL, tidsgränsöverskridningar, gamla adresser eller inkonsekventa A-/AAAA-svar. Ett stabilt och korrekt svar flyttar misstanken från grundläggande DNS-upplösning till routing, proxy, TLS, brandvägg eller applikationskonfiguration.

Jämför resolverresultat och feltyper

Tolka svarskoden innan du ändrar inställningar. NXDOMAIN betyder att det efterfrågade namnet inte finns enligt den resolvern; SERVFAIL betyder att upplösningen inte kunde slutföras; en timeout betyder att resolvern inte svarade i tid. Ett syntaktiskt giltigt svar kan fortfarande vara fel om det pekar på en gammal routeradress eller en slutpunkt som inte kan nås.

Fel där namnet inte hittas och tillfälliga resolverfel är olika grenar. Använd skillnader mellan namnupplösningsfel för att avgöra om du ska åtgärda en saknad post, en resolver som inte kan nås eller en instabil DNS-väg, i stället för att behandla alla uppslagsfel som samma problem.

Om endast hemnätverkets resolver returnerar den gamla eller felaktiga adressen medan en annan resolver returnerar det avsedda offentliga värdet, bör du kontrollera lokala åsidosättningar, split-DNS-poster, DNS som tillhandahålls via DHCP, filtreringstjänster och cacheminnen. Om alla resolvrar returnerar samma korrekta adress ska du sluta ändra DNS och gå vidare till tjänstevägen.

Featured

ZimaCube 2 personlig molnhem NAS

ZimaCube2

Använd en kontrollerad förbikoppling för att bevisa eller avfärda DNS

Skapa en tillfällig och reversibel kontroll som endast ändrar namnupplösningen för klienten som misslyckas. Du kan till exempel fråga en annan resolver direkt eller använda en tillfällig post i hosts-filen som mappar det exakta Immich-värdnamnet till den kända avsedda slutpunkten. Spara de ursprungliga inställningarna så att testet omedelbart kan återställas.

Om det ursprungliga Immich-arbetsflödet börjar fungera medan värdnamnet förblir identiskt och endast dess upplösningsväg har ändrats, är DNS starkt misstänkt. Om samma värdnamn fortfarande misslyckas efter att det upplöses till den verifierade slutpunkten ligger felet efter DNS, och du bör kontrollera proxyrouting, certifikat, NAT, brandväggsregler eller själva Immich-tjänsten.

Om en enda ren fråga inte kan återskapa problemet i hushållets felperiod bör du jämföra tillståndet för värd, container, lokal resolver, uppströmsresolver, DHCP, VPN och cache över tid. En kontroll av DNS-fel i flera lager hjälper dig att upptäcka intermittenta fall som försvinner vid ett engångstest.

Rensa rätt cache och testa det ursprungliga Immich-arbetsflödet igen

När du har korrigerat en DNS-post, resolver, DHCP-inställning, split-DNS-regel eller lokal åsidosättning bör du, när det är praktiskt möjligt, endast rensa den berörda klientens eller resolverns cache. Rensa inte upprepade gånger alla lager utan att dokumentera vad som ändrades, eftersom det kan göra en tillfällig framgång omöjlig att förklara.

Slå upp värdnamnet igen från den berörda klienten och verifiera det avsedda A-/AAAA-svaret, resolvern och svarstiden. Öppna sedan Immich via det normala värdnamnet, läs in äldre objekt, sök och genomför en säker uppladdning eller annan skrivåtgärd, så att testet omfattar mer än bara inloggningssidan.

Upprepa kontrollen från det nätverkstillstånd där felet ursprungligen uppstod, till exempel mobildata, hemmets Wi-Fi, Wi-Fi med aktivt VPN eller efter en förnyelse av router/DHCP. DNS kan avföras som grundorsak först när det normala värdnamnet förblir korrekt genom den utlösande situation som tidigare orsakade felet. Annars ska du bevara den nya informationen och fortsätta till nästa nätverkslager.