Immich Networking: How Discovery, DNS, and Routing Produce Reachability
Immich reachability results from an ordered chain: endpoint selection, DNS resolution, packet routing, proxy or NAT forwarding, and application response.
A phone can reach Immich by local IP while the same hostname fails on Wi-Fi, or work remotely while taking a longer path at home. These outcomes are produced by different name and route decisions, not by one universal โnetwork is upโ state.
Reachability Starts With the Endpoint a Client Chooses
A client cannot route to โImmichโ as an abstract service; it uses a scheme, hostname or address, port, and sometimes a path. Native applications, browsers, bookmarks, and shared links may store different endpoints. Their reachability can diverge before any packet reaches the server.
A community thread about exposing Immich locally and remotely describes difficulty when a router cannot provide split-horizon behavior and the client lacks automatic local endpoint switching. The case shows that endpoint selection and local DNS capability jointly shape which path a home client attempts.
Write the exact URL used by each client and note whether it was typed, discovered from a link, or saved earlier. Compare scheme, host, port, and path. Do not collapse a working local IP and a failing public hostname into one result; they are different destination contracts.
DNS Selects an Address, Not a Working Service
DNS converts the selected hostname into an address. Public and local resolvers may intentionally return different answers, while stale caches may preserve an old router or server address. A correct answer only identifies a destination; it does not prove the port, proxy, certificate, or application is available there.
A Caddy community case describes Immich working by local IP while a DuckDNS-based local path fails and raises hairpin NAT questions. The details are environment-specific, but they demonstrate that name resolution and router return paths can differ even on the same home network.
Query the hostname from the affected phone or browser network, then compare it with the expected local or public address. Repeat on mobile data. If answers differ intentionally, document split DNS. If they differ unexpectedly, correct the authoritative record or cache before changing Immich containers.
Routing, NAT, and Proxies Complete the Delivery Chain
After DNS, the client needs a route. Remote traffic may cross an ISP, router, port forward, tunnel, or reverse proxy; local traffic may go directly or loop through the public edge. Each layer must deliver the correct port and preserve the request context expected by the application.
The ZimaSpace Immich data-path article separates client, network, application, database, and media dependencies. That layered model prevents a common mistake: restarting Immich when the application already answers locally and the first broken dependency is outside the container.
Follow the path in order: address, route, listening port, proxy target, TLS name, and application response. A successful ping is not sufficient because the web or API port may still be blocked. Likewise, a proxy landing page is not proof that requests reach the Immich service.
Use a Layered Reachability Trace
Create two columns for home Wi-Fi and mobile data. In each, record selected URL, DNS answer, route or gateway, TCP connection, TLS result, HTTP status, and one authenticated Immich API response. Use the same account and asset so identity or permissions do not change the network comparison.
A home-server Immich guide shows DNS routing as a prerequisite before certificate and application access steps. Its sequence supports the diagnostic rule: later layers cannot compensate for an incorrect name-to-address mapping, while correct DNS alone cannot validate forwarding or application health.
Stop at the first layer whose observed value differs from the expected path. Correct only that layer and repeat both columns, because a remote fix can break local hairpin behavior. Reachability is accepted when both intended paths complete the same application request, not merely when a hostname resolves.
Recommended products
Tech & AI HUB
More to Read
Why Does Immich Reprocess Existing Data After an Upgrade?
Immich may reprocess assets when an upgrade invalidates earlier derivatives, metadata, models, or job state; repeated endless work is a separate fault.
What Dependencies Most Often Set the Real Immich Performance Ceiling?
Immich is capped by the slowest dependency on each measured path, so upload, search, browsing, and playback can have different ceilings.
Immich for Families: How Identity and Permissions Shape the Experience
Immich family use depends on separate identities, asset ownership, intentional sharing, limited administration, and tested revocation.
