Fungerar Immich tillförlitligt bakom CGNAT eller dubbel NAT?

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.

Does Immich Work Reliably Behind CGNAT or Double NAT?

Ja, Immich kan köras tillförlitligt bakom CGNAT eller dubbel NAT, eftersom dessa nätverkslager främst påverkar hur fjärrklienter når servern och inte den lokala Immich-bearbetningen.

Svårigheten uppstår när en familj förväntar sig att oinitierade inkommande IPv4-anslutningar ska nå en hemmaserver som inte kontrollerar den yttre adressöversättningen. Dubbel NAT kan fortfarande vara hanterbart när du kontrollerar båda routrarna; CGNAT placerar vanligtvis den yttre översättningen hos internetleverantören, så en enkel portvidarebefordran på hemroutern kan inte skapa samma direkta offentliga väg.

Lokal Immich-drift är inte beroende av nåbarhet från internet

Telefoner och webbläsare på samma hemnätverk kan nå Immich-servern via privata adresser utan någon offentlig portmappning. Uppladdningar, surfning, databasarbete, miniatyrbilder och lokal maskininlärning kan därför fortsätta fungera även när internetleverantören inte ger hushållet någon direkt nåbar offentlig IPv4-adress.

Denna skillnad syns i frågor från communityn om Immich bakom CGNAT: användare rapporterar ofta en fungerande lokal installation och stöter på begränsningen först när de lägger till fjärråtkomst. CGNAT är därför ett nåbarhetsvillkor, inte ett villkor för applikationens lagring.

Om Immich även slutar fungera i det lokala nätverket är CGNAT inte den första förklaringen. Felsök lokal DNS, containernätverk, serverns tillgänglighet, lagring eller autentisering innan du bygger om den offentliga åtkomstvägen.

Dubbel NAT och CGNAT skapar olika kontrollgränser

Vid dubbel NAT i hemmet kan en administratör kontrollera båda översättningslagren, till exempel en gateway från internetleverantören och en egen router. En direkt inkommande väg kan ibland byggas genom att vidarebefordra genom båda lagren eller ändra topologin. Den avgörande frågan är om den yttre mappningen ligger under hushållets kontroll.

Tailscales artikel om svår NAT-traversering förklarar varför flera NAT-lager och operatörsbaserade gateways minskar chansen att upprätta direkta peer-to-peer-vägar. Ju striktare mappningarna är, desto större är sannolikheten att ett traverseringssystem behöver använda en reservreläserver.

Märk inte varje WAN-adress som ser privat ut som samma problem utan att kontrollera topologin. IPv6, offentliga alternativ från internetleverantören, bryggläge och olika uppströmsarkitekturer kan ändra vilka vägar som är tillgängliga även när hemrouterns gränssnitt ser likadant ut.

Överlagringsnätverk kan återställa nåbarheten utan portvidarebefordran

Ett privat överlagringsnätverk kan låta både fjärrklienten och hemmaservern initiera utgående anslutningar och sedan försöka skapa en krypterad peer-to-peer-väg. När direkt traversering lyckas kan data flöda utan att Immich-tjänsten exponeras som en vanlig offentlig port på hemroutern.

Den mer detaljerade förklaringen av överlagringsanslutning beskriver NAT-traversering samt en krypterad reservreläfunktion när en direkt väg inte kan skapas. Därför kan ett Immich-hushåll bakom CGNAT ändå få fjärråtkomst, trots att vanlig inkommande IPv4-vidarebefordran inte är tillgänglig.

Nackdelen är beroendet av klienter och identiteter: godkända fjärrenheter måste ha åtkomst till överlagringsnätverket, och vägen kan skilja sig från en offentlig omvänd proxy som används av gäster som endast ansluter via webbläsare. Tillförlitlighet bör därför även omfatta hur familjemedlemmarna faktiskt ansluter, inte bara om administratörens telefon fungerar.

-15% OFF

ZimaBoard 2 - Minihemmserver för din stora idé

Single board computer zimaboard2

Reservreläet bevarar åtkomsten men kan påverka prestandan

En reläad väg kan hålla tjänsten nåbar när strikt NAT eller brandväggsregler förhindrar direkt UDP-anslutning. Det löser det grundläggande åtkomstproblemet, men det extra hoppet kan öka fördröjningen eller minska genomströmningen, vilket spelar roll vid stora fotoöverföringar och fjärrvisning i hög upplösning.

En rapport från 2026 om reläprestanda visar ett fall där en långväga DERP-väg lade till hundratals millisekunder tills en bättre reläarkitektur användes. Se omfattningen som specifik för författarens väg, men behåll den allmänna mekanismen med direkt väg kontra reläad väg.

Detta är gränsen för det förenklade svaret ”Tailscale löser CGNAT”. Tailscale kan återställa anslutningen, men garanterar inte samma prestanda som ett direkt LAN eller en direkt peer-väg. Kontrollera den faktiska vägen innan du tillskriver långsam Immich-prestanda själva applikationen.

Verifiera nåbarhet och väg som separata tester

Testa först Immich lokalt med WAN-anslutningen frånkopplad; tjänsten bör fortfarande kunna användas i hemnätverket. Testa sedan den valda fjärrmetoden från mobilnätet eller ett annat externt nätverk. Kontrollera slutligen om fjärranslutningen är direkt eller reläad och jämför uppladdning, öppning av miniatyrbilder och en känd sökning med resultatet i LAN-nätverket.

ZimaSpaces diskussion om CGNAT och dubbel NAT tillämpar samma nätverksprincip på en annan självhostad tjänst: applikationen kan fortsätta vara tillförlitlig lokalt medan den externa åtkomstvägen behöver en separat utformning.

Acceptera arkitekturen när lokal användning överlever ett internetavbrott, fjärrautentiseringen är avsiktlig och den externa vägen uppfyller hushållets krav på fördröjning och genomströmning. Om åtkomsten endast fungerar via ett oväntat långsamt relä ska du se det som ett problem med vägens kvalitet, inte som ett bevis på att Immich i sig är opålitligt bakom NAT.