Does Immich Work Reliably Behind CGNAT or Double NAT?
Yes, Immich can run reliably behind CGNAT or double NAT, because those network layers mainly affect how remote clients reach the server rather than local Immich processing.
The difficulty appears when a family expects unsolicited inbound IPv4 connections to reach a home server that does not control the outer address translation. Double NAT may still be manageable when both routers are under your control; CGNAT usually places the outer translation at the ISP, so a simple port-forward on the home router cannot create the same direct public path.
Local Immich Operation Does Not Depend on Public Reachability
Phones and browsers on the same home network can reach the Immich server through private addressing without any public port mapping. Uploads, browsing, database work, thumbnails, and local machine learning can therefore remain healthy even when the ISP gives the household no directly reachable public IPv4 address.
This distinction appears in community questions about Immich behind CGNAT: users often report a working local deployment and encounter the limitation only when adding remote access. That makes CGNAT a reachability condition, not an application-storage condition.
If Immich also fails on the LAN, CGNAT is not the first explanation. Diagnose local DNS, container networking, server availability, storage, or authentication before redesigning the public path.
Double NAT and CGNAT Create Different Control Boundaries
With double NAT inside a home, an administrator may control both translation layers—for example, an ISP gateway plus a personal router. A direct inbound route can sometimes be constructed by forwarding through both layers or changing the topology. The defining issue is whether the outer mapping is under household control.
Tailscale’s article on hard NAT traversal explains why multiple NAT layers and carrier-grade gateways reduce the chance of establishing direct peer-to-peer paths. The more restrictive the mappings, the more likely a traversal system needs a fallback relay.
Do not label every private-looking WAN address as the same problem without checking the topology. IPv6, ISP-provided public options, bridge mode, and different upstream architectures can change the available paths even when the home router screen looks similar.
Overlay Networks Can Restore Reachability Without Port Forwarding
A private overlay can let both the remote client and home server initiate outbound connections and then attempt to form an encrypted peer-to-peer path. When direct traversal succeeds, the data can flow without exposing the Immich service as a normal public port on the home router.
The deeper explanation of overlay connectivity describes NAT traversal plus encrypted relay fallback when a direct path cannot be formed. This is why an Immich household behind CGNAT can still achieve remote access even though ordinary inbound IPv4 forwarding is unavailable.
The tradeoff is client and identity dependency: authorized remote devices need access to the overlay, and the path may differ from a public reverse proxy used by browser-only guests. Reliability should therefore include how family members actually connect, not only whether one administrator’s phone works.
Relay Fallback Preserves Access but Can Change Performance
A relayed path can keep the service reachable when hard NAT or firewall rules prevent direct UDP connectivity. That solves the binary access problem, but the extra hop can increase latency or reduce throughput, which matters for large photo uploads and high-resolution remote browsing.
A 2026 report on relay performance shows a case where a long-distance DERP route added hundreds of milliseconds until a better relay architecture was used. Treat the magnitude as that author’s path, while keeping the general direct-versus-relayed mechanism.
This is the failure boundary for the simple answer “Tailscale fixes CGNAT.” It can restore connectivity, but it does not guarantee the same performance as a direct LAN or direct peer route. Verify the actual path before attributing slow Immich behavior to the application.
Verify Reachability and Path as Separate Tests
First test local Immich with the WAN disconnected; it should remain usable inside the home network. Then test the chosen remote method from cellular or another external network. Finally, inspect whether the remote connection is direct or relayed and compare upload, thumbnail opening, and a known search against the LAN baseline.
ZimaSpace’s discussion of CGNAT and double NAT applies the same network-layer principle to another self-hosted service: the application can remain locally reliable while the remote entry path needs a separate design.
Accept the architecture when local use survives internet loss, remote authentication is intentional, and the remote route meets the household’s latency and throughput target. If access works only through an unexpectedly slow relay, treat that as a path-quality issue rather than proof that Immich itself is unreliable behind NAT.
Recommended products
Tech & AI HUB
More to Read
Open Models Are Catching Frontier AI—Is 2026 the Year Local AI Becomes Good Enough?
Open models are getting good enough for more local AI workloads, while frontier cloud models remain useful for the hardest reasoning and agent tasks.
NVIDIA PAIR Turns Your Home Network Into a Local AI Cluster—Do You Still Need One Big GPU Server?
NVIDIA PAIR spreads local AI requests across multiple PCs, making compute more elastic while one home server can keep data and state persistent.
Why Does Immich Feel Faster on LAN Than on Remote Connections?
LAN requests usually take a shorter, lower-latency path. Remote access adds WAN capacity limits and may add DNS, TLS, proxy, VPN, or relay hops.
