Varför känns Immich snabbare på LAN än via fjärranslutningar?

Immich känns vanligtvis snabbare på LAN eftersom lokala klienter färdas över en kortare väg med lägre latens, färre gateways och utan att internetanslutningen hemma blir en flaskhals.

Fjärranvändning kan lägga till begränsningar i internetleverantörens uppladdningshastighet, mobil- eller hotellnätverk, DNS, TLS-terminering, en reverse proxy, ett VPN eller ett overlay-nätverk och ibland en reläserver. Dessa tillägg gör inte alla förfrågningar långsamma på samma sätt: miniatyrbilder, metadataförfrågningar, nedladdningar av original, uppladdningar och sökförfrågningar belastar olika delar av vägen. Jämför därför identiska åtgärder innan du drar slutsatsen att ”fjärranvändning av Immich” är ett enda prestandaläge.

LAN tar bort det mesta av variationen i WAN-vägen

På ett trådbundet LAN eller ett starkt Wi-Fi-LAN skiljs klienten och servern vanligtvis åt av bara några få lokala växlings- eller routningshopp. Rundturen har låg latens och hushållet kontrollerar större delen av vägen, så små API-anrop och många miniatyrbildsförfrågningar kan slutföras med kort väntetid på nätverket.

Modellen med direktanslutning kontra relä i NAT-traversering hjälper till att förklara skillnaden. En fjärrklient kan nå samma server via en direkt WAN-tunnel eller genom en reläserver, medan LAN-klienten helt enkelt använder den lokala vägen. Programmets slutpunkt kan vara identisk även när transportförhållandena inte är det.

Ett snabbare LAN bevisar inte att servern fungerar bra under alla arbetsbelastningar. Låg lokal latens kan dölja ineffektiva förfrågningar eller långsam lagring eftersom väntetiden på nätverket är liten. Ta med servermätvärden i jämförelsen så att en diagnos av fjärrvägen inte ursäktar en flaskhals i backend som påverkar båda vägarna.

Hemmets uppladdning blir kapacitet för fjärrnedladdning

När någon utanför hemmet öppnar foton från en hemserver skickar servern data via hushållets uppladdningsriktning mot internet. Många privata internetanslutningar har betydligt mindre uppströmskapacitet än lokalt Ethernet eller Wi-Fi, så fjärråtkomst till original och stora förhandsvisningar kan bli bandbreddsbegränsad även när bläddring på LAN sker omedelbart.

En diskussion i communityt om fjärråtkomst för familjer visar varför hushåll utvärderar mer än bara anslutningen: vägen måste också vara enkel och pålitlig för icke-tekniska användare. Prestanda, autentisering och användarupplevelse är alla en del av den praktiska fjärrvägen.

Bandbredd är inte rätt förklaring när små metadatakontroller, filter eller inloggningsåtgärder är långsamma medan stora överföringar når den förväntade hastigheten. Det mönstret pekar snarare mot latens, routning av förfrågningar, proxybeteende, DNS eller svarstid från servern.

Proxies och tunnlar lägger till bearbetnings- och konfigurationsgränser

En fjärrförfrågan kan avsluta TLS vid en proxy, passera genom ett annat containernätverk eller färdas genom ett krypterat overlay-nätverk innan den når Immich. Välkonfigurerade lager kan ge liten extra belastning, men varje lager introducerar ytterligare en plats där buffring, headerhantering, timeoutpolicy, vägval eller MTU-problem kan påverka vissa förfrågningar.

En användarrapport från 2026 om fördröjningar vid fjärrfiltrering identifierade till slut ett konfigurationsproblem i slutpunktens väg, efter att även reläprestanda hade övervägts. Exemplet är värdefullt eftersom två olika mekanismer gav liknande symtom av typen ”fjärråtkomst är långsam”.

Byt inte teknik för fjärråtkomst baserat på en enda sidinläsning. Identifiera först om den felande åtgärden är en överföring, en API-förfrågan, autentisering eller anslutningsetablering. En reverse proxy kan inte åtgärda en överbelastad upplänk hemma, och en snabbare tunnel kan inte åtgärda en långsam databasfråga.

Featured

ZimaCube 2 personlig molnhem NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Cachelagring kan göra LAN- och fjärrtester ojämförbara

En telefon på LAN kan redan ha miniatyrbilder, sessionstillstånd, DNS-svar eller nyligen använda resurser i cachen, medan fjärrtestet kan börja från ett kallare tillstånd. Att jämföra dessa två körningar kan överdriva nätverksskillnaden eftersom den ena klienten begär mindre data från servern.

ZimaSpaces förklaring av lagringslatens understryker behovet av att kontrollera cache- och arbetsbelastningstillstånd när prestanda jämförs. Samma noggrannhet gäller vid testning av vägar: använd samma konto, samma uppsättning resurser, samma klient och samma cacheförhållanden när det är möjligt.

LAN kontra WAN slutar förklara en avvikelse som kvarstår när båda testerna tvingas genom samma väg eller när svarstiden på serversidan ökar på samma sätt. Inspektera då applikationen eller värdsystemet i stället för att fortsätta optimera nätverkstopologin.

Skapa en jämförelse av samma åtgärd över olika vägar

Välj fyra åtgärder: läs in samma album, öppna samma stora foto, kör samma kända sökning och ladda upp samma testfil. Registrera tiden som klienten observerar, serverns förfrågningstid där den är tillgänglig, rundturslatens, överföringshastighet och om fjärrvägen är direkt, proxad eller reläad.

Jämför LAN- och fjärrkörningar från ett känt cachetillstånd och ändra sedan endast en variabel i vägen åt gången. Tailscales diskussion om direkta och reläade anslutningar ger en användbar modell för klassificering av vägar. Om endast stora överföringar förbättras är bandbredd den starkare begränsningen.

Godta diagnosen när den ändrade vägen förbättrar den åtgärd som mekanismen förutsäger, utan att serverns arbetsbelastning ändras. Behåll den enklaste fjärrdesignen som uppfyller familjens mål för åtkomst och prestanda; extra proxy-, tunnel- eller relälager bör finnas av ett tydligt skäl som rör åtkomst eller säkerhet.