Werkt Immich betrouwbaar achter CGNAT of dubbele NAT?

Ja, Immich kan betrouwbaar achter CGNAT of dubbele NAT draaien, omdat deze netwerklagen vooral bepalen hoe externe clients de server bereiken en niet hoe Immich lokaal werkt.

De moeilijkheid ontstaat wanneer een gezin verwacht dat ongevraagde inkomende IPv4-verbindingen een thuisserver bereiken die geen controle heeft over de buitenste adresvertaling. Dubbele NAT is mogelijk nog beheersbaar wanneer je beide routers beheert; bij CGNAT vindt de buitenste vertaling meestal plaats bij de internetprovider, waardoor een eenvoudige poortdoorschakeling op de thuisrouter niet dezelfde directe openbare route kan creëren.

Lokale werking van Immich is niet afhankelijk van openbare bereikbaarheid

Telefoons en browsers op hetzelfde thuisnetwerk kunnen de Immich-server via private adressering bereiken zonder openbare poortdoorschakeling. Uploads, bladeren, databasewerk, miniaturen en lokaal machine learning kunnen daardoor goed blijven werken, zelfs wanneer de internetprovider het huishouden geen rechtstreeks bereikbaar openbaar IPv4-adres geeft.

Dit onderscheid komt naar voren in vragen uit de community over Immich achter CGNAT: gebruikers melden vaak een werkende lokale installatie en lopen pas tegen de beperking aan wanneer ze externe toegang toevoegen. CGNAT is daarmee een bereikbaarheidskwestie, geen probleem met de applicatieopslag.

Als Immich ook op het LAN niet werkt, is CGNAT niet de eerste verklaring. Controleer lokale DNS, containernetwerken, de beschikbaarheid van de server, opslag en authenticatie voordat je de openbare route opnieuw ontwerpt.

Dubbele NAT en CGNAT creëren verschillende beheergrenzen

Bij dubbele NAT binnen een woning kan een beheerder beide vertalingslagen beheren, bijvoorbeeld een gateway van de internetprovider plus een eigen router. Soms kan een directe inkomende route worden aangelegd door beide lagen door te sturen of de netwerktopologie te wijzigen. De bepalende vraag is of de buitenste mapping onder controle van het huishouden staat.

Het artikel van Tailscale over moeilijke NAT-traversal legt uit waarom meerdere NAT-lagen en gateways van carrier-grade-kwaliteit de kans op directe peer-to-peerverbindingen verkleinen. Hoe beperkter de mappings zijn, hoe waarschijnlijker het is dat een traversalsysteem een relais als fallback nodig heeft.

Label niet elk WAN-adres dat er privé uitziet als hetzelfde probleem zonder de topologie te controleren. IPv6, openbare opties van de internetprovider, bridge-modus en verschillende upstreamarchitecturen kunnen de beschikbare routes veranderen, zelfs wanneer het scherm van de thuisrouter er hetzelfde uitziet.

Overlaynetwerken kunnen bereikbaarheid herstellen zonder poortdoorschakeling

Een private overlay kan zowel de externe client als de thuisserver uitgaande verbindingen laten starten en vervolgens proberen een versleutelde peer-to-peerroute op te zetten. Wanneer directe traversal slaagt, kan het verkeer lopen zonder de Immich-service als normale openbare poort op de thuisrouter bloot te stellen.

De uitgebreidere uitleg van overlayconnectiviteit beschrijft NAT-traversal plus een versleutelde fallback via een relais wanneer geen directe route kan worden gevormd. Daarom kan een huishouden met Immich achter CGNAT toch externe toegang krijgen, ook al is gewone inkomende IPv4-doorschakeling niet beschikbaar.

De afweging zit in de afhankelijkheid van clients en identiteiten: geautoriseerde externe apparaten moeten toegang hebben tot de overlay, en de route kan verschillen van een openbare reverse proxy die door gasten in alleen een browser wordt gebruikt. Betrouwbaarheid moet daarom ook omvatten hoe gezinsleden daadwerkelijk verbinding maken, niet alleen of de telefoon van één beheerder werkt.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Een relaisfallback behoudt de toegang, maar kan de prestaties veranderen

Een route via een relais kan de service bereikbaar houden wanneer strikte NAT of firewallregels directe UDP-connectiviteit verhinderen. Daarmee wordt het binaire toegangsprobleem opgelost, maar de extra tussenstap kan de latentie verhogen of de doorvoer verlagen. Dat is relevant voor grote fotouploads en op afstand bekijken in hoge resolutie.

Een rapport uit 2026 over relayprestaties beschrijft een geval waarin een DERP-route over lange afstand honderden milliseconden toevoegde totdat een betere relaisarchitectuur werd gebruikt. Beschouw de omvang als kenmerkend voor de route van die auteur, maar houd vast aan het algemene mechanisme van directe versus gerelayeerde verbindingen.

Dit is de grens van het eenvoudige antwoord “Tailscale lost CGNAT op”. Het kan de verbinding herstellen, maar garandeert niet dezelfde prestaties als een directe LAN- of peerroute. Controleer de werkelijke route voordat je traag Immich-gedrag aan de applicatie toeschrijft.

Controleer bereikbaarheid en route als afzonderlijke tests

Test Immich eerst lokaal terwijl de WAN-verbinding is uitgeschakeld; binnen het thuisnetwerk moet het bruikbaar blijven. Test daarna de gekozen externe methode via mobiel internet of een ander extern netwerk. Controleer ten slotte of de externe verbinding direct of via een relais verloopt en vergelijk uploads, het openen van miniaturen en een bekende zoekopdracht met de LAN-baseline.

De bespreking van CGNAT en dubbele NAT door ZimaSpace past hetzelfde principe op netwerkniveau toe op een andere zelfgehoste service: de applicatie kan lokaal betrouwbaar blijven terwijl voor de externe toegangsroute een apart ontwerp nodig is.

Accepteer de architectuur wanneer lokaal gebruik doorgaat na internetuitval, externe authenticatie bewust is ingericht en de externe route voldoet aan de gewenste latentie en doorvoer voor het huishouden. Als toegang alleen via een onverwacht traag relais werkt, beschouw dat dan als een probleem met de routekwaliteit en niet als bewijs dat Immich zelf onbetrouwbaar is achter NAT.