Why Does Immich Feel Faster on LAN Than on Remote Connections?
Immich usually feels faster on LAN because local clients traverse a shorter, lower-latency path with fewer gateways and without the home internet connection as a bottleneck.
Remote use can add ISP upload limits, mobile or hotel networks, DNS, TLS termination, a reverse proxy, a VPN or overlay, and sometimes a relay. Those additions do not make every request slow in the same way: thumbnails, metadata queries, original downloads, uploads, and search calls stress different parts of the path, so compare identical actions before concluding that “remote Immich” is one performance mode.
LAN Removes Most WAN Path Variability
On a wired or strong Wi-Fi LAN, client and server are usually separated by only a few local switching or routing hops. Round-trip time is low and the household controls most of the path, so small API calls and many thumbnail requests can complete with little network waiting.
The direct-versus-relayed model in NAT traversal helps explain the contrast. A remote client may reach the same server over a direct WAN tunnel or through a relay, while the LAN client simply takes the local route. The application endpoint can be identical even when transport conditions are not.
A faster LAN does not prove the server is healthy under all workloads. Local low latency can hide inefficient requests or slow storage because network waiting is small. Keep server metrics in the comparison so a remote-path diagnosis does not excuse a backend bottleneck that affects both routes.
Home Upload Becomes Remote Download Capacity
When someone outside the house opens photos from a home server, the server sends data through the household’s internet upload direction. Many residential connections have much less upstream capacity than local Ethernet or Wi-Fi, so remote originals and large previews can become bandwidth-limited even when LAN browsing is instant.
A community thread on family remote access shows why households evaluate more than connectivity: the route must also be simple and dependable for nontechnical users. Performance, authentication, and user experience are all part of the practical remote path.
Bandwidth is not the right explanation when tiny metadata controls, filters, or login operations are slow while large transfers achieve the expected rate. That pattern points more strongly toward latency, request routing, proxy behavior, DNS, or server response time.
Proxies and Tunnels Add Processing and Configuration Boundaries
A remote request may terminate TLS at a proxy, cross another container network, or travel through an encrypted overlay before reaching Immich. Well-configured layers can add little overhead, but each layer introduces another place for buffering, header handling, timeout policy, path selection, or MTU problems to affect particular requests.
A 2026 Immich user report about remote filtering delays eventually identified an endpoint-path configuration issue after relay performance was also considered. The example is valuable because two distinct mechanisms produced similar “remote is slow” symptoms.
Do not swap remote-access technologies based on one page load. First identify whether the failing operation is a transfer, an API request, authentication, or connection establishment. A reverse proxy cannot fix a saturated home uplink, and a faster tunnel cannot fix a slow database query.
Caching Can Make LAN and Remote Tests Unequal
A phone on the LAN may already have thumbnails, session state, DNS answers, or recently accessed assets cached, while the remote test may begin from a colder state. Comparing those two runs can exaggerate the network difference because one client is requesting less data from the server.
ZimaSpace’s explanation of storage latency reinforces the need to control cache and workload state when comparing performance. The same discipline applies to route testing: use the same account, asset set, client, and cache condition where possible.
The LAN-versus-WAN mechanism stops explaining a discrepancy that remains when both tests are forced through the same route or when server-side response time itself grows identically. At that point, inspect the application or host rather than continuing to optimize network topology.
Build a Same-Action Route Comparison
Choose four actions: load the same album, open the same large photo, run the same known search, and upload the same test file. Record client-observed time, server request time where available, round-trip latency, transfer throughput, and whether the remote path is direct, proxied, or relayed.
Compare LAN and remote runs from a known cache state, then change only one route variable at a time. Tailscale’s discussion of direct and relayed connections provides a useful path-classification model. If only large transfers improve, bandwidth is the stronger limit.
Accept the diagnosis when the changed route improves the operation predicted by the mechanism without changing the server workload. Keep the simplest remote design that meets the family’s access and performance targets; extra proxy, tunnel, or relay layers should exist for a clear reachability or security reason.
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.
Does Immich Work Reliably Behind CGNAT or Double NAT?
CGNAT and double NAT do not break local Immich use. They mainly complicate direct inbound remote access and can force alternate or relayed paths.
