Waarom voelt Immich sneller aan via LAN dan via externe verbindingen?

Eva Wong

IceWhale author

Eva Wong is de Technisch Schrijver en en vaste knutselaar bij ZimaSpace. Een levenslange geek met een passie voor homelabs en open-source software, zij is gespecialiseerd in het vertalen van complexe technische concepten naar toegankelijke, praktische handleidingen. Eva gelooft dat zelf-hosting leuk moet zijn, niet intimiderend. Met haar tutorials stelt ze de community in staat om hardware-setup te ontrafelen, van het bouwen van hun eerste NAS tot het beheersen van Docker-containers.

Why Does Immich Feel Faster on LAN Than on Remote Connections?

Immich voelt op een LAN doorgaans sneller aan, omdat lokale clients een korter pad met een lagere latentie en minder gateways volgen, zonder dat de internetverbinding thuis een knelpunt vormt.

Gebruik op afstand kan worden vertraagd door uploadlimieten van de internetprovider, mobiele netwerken of hotelnetwerken, DNS, TLS-beëindiging, een reverse proxy, een VPN of overlay en soms een relay. Die toevoegingen maken niet elk verzoek op dezelfde manier traag: thumbnails, metadataverzoeken, downloads van originelen, uploads en zoekopdrachten belasten verschillende delen van het pad. Vergelijk daarom identieke acties voordat je concludeert dat “Immich op afstand” één prestatiemodus is.

Een LAN verwijdert de meeste variatie in het WAN-pad

Op een bekabeld LAN of een sterk wifi-LAN zijn client en server meestal slechts door enkele lokale switch- of routeringssprongen van elkaar gescheiden. De retourtijd is laag en het huishouden beheert het grootste deel van het pad, waardoor kleine API-aanroepen en veel thumbnailverzoeken met weinig netwerkvertraging kunnen worden afgehandeld.

Het model van directe verbindingen versus relays in NAT-traversal helpt het verschil te verklaren. Een externe client kan dezelfde server bereiken via een directe WAN-tunnel of via een relay, terwijl de LAN-client simpelweg de lokale route gebruikt. Het applicatie-eindpunt kan identiek zijn, ook wanneer de transportomstandigheden verschillen.

Een sneller LAN bewijst niet dat de server onder alle workloads gezond presteert. Een lage lokale latentie kan inefficiënte verzoeken of trage opslag maskeren, omdat de netwerkvertraging klein is. Neem serverstatistieken mee in de vergelijking, zodat een diagnose van het externe pad geen backendknelpunt vergoelijkt dat beide routes beïnvloedt.

De upload van thuis wordt de downloadcapaciteit op afstand

Wanneer iemand buitenshuis foto's van een thuisserver opent, verstuurt de server de gegevens via de uploadrichting van de internetverbinding thuis. Veel residentiële verbindingen hebben aanzienlijk minder upstreamcapaciteit dan lokaal Ethernet of wifi. Daardoor kunnen originelen en grote voorbeelden op afstand door bandbreedte worden beperkt, zelfs wanneer bladeren op het LAN direct verloopt.

Een discussiedraad in de community over toegang op afstand voor gezinnen laat zien waarom huishoudens meer dan alleen connectiviteit beoordelen: de route moet ook eenvoudig en betrouwbaar zijn voor niet-technische gebruikers. Prestaties, authenticatie en gebruikerservaring maken allemaal deel uit van het praktische pad op afstand.

Bandbreedte is niet de juiste verklaring wanneer kleine metadatabewerkingen, filters of aanmeldingen traag zijn terwijl grote overdrachten de verwachte snelheid halen. Dat patroon wijst sterker op latentie, routering van verzoeken, prox gedrag, DNS of de responstijd van de server.

Proxies en tunnels voegen verwerkings- en configuratiegrenzen toe

Een extern verzoek kan TLS bij een proxy beëindigen, een ander containernetwerk doorkruisen of via een versleutelde overlay gaan voordat het Immich bereikt. Goed geconfigureerde lagen voegen mogelijk weinig overhead toe, maar elke laag introduceert een extra plek waar buffering, headerverwerking, timeoutbeleid, padselectie of MTU-problemen specifieke verzoeken kunnen beïnvloeden.

Een gebruikersrapport uit 2026 over vertragingen bij filters op afstand wees uiteindelijk op een configuratieprobleem in het eindpuntpad, nadat ook relayprestaties waren onderzocht. Het voorbeeld is waardevol omdat twee verschillende mechanismen vergelijkbare symptomen van “op afstand is het traag” veroorzaakten.

Wissel niet van technologie voor toegang op afstand op basis van één paginalading. Bepaal eerst of de mislukte bewerking een overdracht, API-aanroep, authenticatie of verbindingsopbouw is. Een reverse proxy kan een verzadigde uplink thuis niet repareren, en een snellere tunnel kan een trage databasequery niet oplossen.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

Door caching kunnen LAN- en externe tests ongelijk zijn

Een telefoon op het LAN heeft mogelijk al thumbnails, sessiestatus, DNS-antwoorden of recent gebruikte assets in de cache, terwijl de externe test met een koudere cache begint. Door die twee runs te vergelijken kan het netwerkverschil groter lijken, omdat de ene client minder gegevens bij de server opvraagt.

De uitleg van ZimaSpace over opslaglatentie benadrukt dat je de cache- en workloadstatus moet beheersen wanneer je prestaties vergelijkt. Diezelfde discipline geldt voor routetests: gebruik waar mogelijk hetzelfde account, dezelfde assets, dezelfde client en dezelfde cacheconditie.

Het LAN-versus-WAN-mechanisme verklaart een verschil niet langer wanneer dat verschil blijft bestaan nadat beide tests via dezelfde route zijn uitgevoerd, of wanneer de responstijd aan de serverzijde zelf in beide gevallen identiek toeneemt. Onderzoek dan de applicatie of host in plaats van de netwerktopologie verder te optimaliseren.

Maak een routevergelijking met dezelfde acties

Kies vier acties: laad hetzelfde album, open dezelfde grote foto, voer dezelfde bekende zoekopdracht uit en upload hetzelfde testbestand. Noteer de door de client waargenomen tijd, de aanvraagtijd op de server waar beschikbaar, de retourlatentie, de overdrachtssnelheid en of het externe pad direct, via een proxy of via een relay loopt.

Vergelijk LAN- en externe runs vanuit een bekende cachestatus en wijzig daarna telkens slechts één routevariabele. De bespreking van Tailscale over directe verbindingen en verbindingen via een relay biedt een nuttig model voor padclassificatie. Als alleen grote overdrachten verbeteren, is bandbreedte waarschijnlijk de sterkere beperking.

Accepteer de diagnose wanneer de gewijzigde route de bewerking verbetert die volgens het mechanisme zou moeten verbeteren, zonder de serverworkload te wijzigen. Houd het eenvoudigste externe ontwerp aan dat voldoet aan de toegangs- en prestatiedoelen van het gezin; extra proxy-, tunnel- of relaylagen horen alleen aanwezig te zijn vanwege een duidelijke reden voor bereikbaarheid of beveiliging.