Immich-nätverk: Hur upptäckt, DNS och routing skapar åtkomlighet

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 Networking: How Discovery, DNS, and Routing Produce Reachability

Resultat för Immichs nåbarhet följer en ordnad kedja: val av slutpunkt, DNS-upplösning, paketdirigering, proxy- eller NAT-vidarebefordran och applikationssvar.

En telefon kan nå Immich via lokal IP-adress medan samma värdnamn misslyckas på Wi‑Fi, eller fungera på distans men ta en längre väg hemma. Dessa resultat orsakas av olika beslut om namn och rutter, inte av ett enda universellt tillstånd för att ”nätverket är uppe”.

Nåbarheten börjar med den slutpunkt klienten väljer

En klient kan inte dirigera trafik till ”Immich” som en abstrakt tjänst; den använder ett schema, ett värdnamn eller en adress, en port och ibland en sökväg. Naturliga applikationer, webbläsare, bokmärken och delade länkar kan lagra olika slutpunkter. Deras nåbarhet kan skilja sig redan innan något paket når servern.

En tråd i communityt om att exponera Immich lokalt och på distans beskriver svårigheter när en router inte kan tillhandahålla split-horizon-beteende och klienten saknar automatisk växling till lokal slutpunkt. Fallet visar att val av slutpunkt och lokal DNS-kapacitet tillsammans avgör vilken väg en hemklient försöker använda.

Skriv ned den exakta URL som används av varje klient och notera om den skrevs in, upptäcktes via en länk eller sparades tidigare. Jämför schema, värd, port och sökväg. Slå inte ihop en fungerande lokal IP-adress och ett felande offentligt värdnamn till ett enda resultat; de är olika destinationskontrakt.

DNS väljer en adress, inte en fungerande tjänst

DNS omvandlar det valda värdnamnet till en adress. Offentliga och lokala resolvrar kan avsiktligt returnera olika svar, medan gamla cacheposter kan bevara en tidigare router- eller serveradress. Ett korrekt svar identifierar bara en destination; det bevisar inte att porten, proxyn, certifikatet eller applikationen är tillgänglig där.

Ett fall i Caddy-communityt beskriver hur Immich fungerar via lokal IP-adress medan en lokal sökväg baserad på DuckDNS misslyckas och väcker frågor om hairpin-NAT. Detaljerna är miljöspecifika, men de visar att namnupplösning och routerns returvägar kan skilja sig även i samma hemnätverk.

Fråga värdnamnet från det berörda telefon- eller webbläsarnätverket och jämför det med den förväntade lokala eller offentliga adressen. Upprepa via mobildata. Om svaren skiljer sig avsiktligt, dokumentera split DNS. Om de skiljer sig oväntat, korrigera den auktoritativa posten eller cachen innan du ändrar Immich-containrar.

Dirigering, NAT och proxyer slutför leveranskedjan

Efter DNS behöver klienten en rutt. Fjärrtrafik kan passera en internetleverantör, router, portvidarebefordran, tunnel eller omvänd proxy; lokal trafik kan gå direkt eller gå via den offentliga kanten. Varje lager måste leverera rätt port och bevara den begärandekontext som applikationen förväntar sig.

Artikeln om Immichs datasökväg på ZimaSpace skiljer mellan klient-, nätverks-, applikations-, databas- och medieberoenden. Den lagerindelade modellen förhindrar ett vanligt misstag: att starta om Immich när applikationen redan svarar lokalt och det första trasiga beroendet finns utanför containern.

Följ sökvägen i ordning: adress, rutt, lyssnande port, proxymål, TLS-namn och applikationssvar. En lyckad ping räcker inte, eftersom webb- eller API-porten fortfarande kan vara blockerad. På samma sätt bevisar en målsida från proxyn inte att begäranden når Immich-tjänsten.

Featured

ZimaCube 2 personlig molnhem NAS

ZimaCube2

Använd en lagerindelad spårning av nåbarheten

Skapa två kolumner för Wi‑Fi hemma och mobildata. Anteckna i varje kolumn vald URL, DNS-svar, rutt eller gateway, TCP-anslutning, TLS-resultat, HTTP-status och ett autentiserat svar från Immichs API. Använd samma konto och medieobjekt så att identitet eller behörigheter inte förändrar nätverksjämförelsen.

En guide om Immich på hemserver visar DNS-dirigering som en förutsättning före stegen för certifikat och applikationsåtkomst. Ordningen stöder den diagnostiska regeln: senare lager kan inte kompensera för en felaktig mappning mellan namn och adress, medan korrekt DNS i sig inte kan validera vidarebefordran eller applikationens hälsa.

Stanna vid det första lagret där det observerade värdet skiljer sig från den förväntade sökvägen. Korrigera endast det lagret och upprepa båda kolumnerna, eftersom en fjärrkorrigering kan bryta lokal hairpin-funktion. Nåbarhet är bekräftad när båda avsedda vägarna slutför samma applikationsbegäran, inte bara när ett värdnamn kan lösas.