Perché Immich sembra più veloce sulla LAN rispetto alle connessioni remote?
Immich di solito sembra più veloce sulla LAN perché i client locali percorrono un percorso più breve e con una latenza inferiore, con meno gateway e senza che la connessione Internet domestica rappresenti un collo di bottiglia.
L’uso da remoto può aggiungere limiti alla velocità di upload dell’ISP, reti mobili o alberghiere, DNS, terminazione TLS, un proxy inverso, una VPN o una rete overlay e, talvolta, un relay. Questi elementi non rendono lenta ogni richiesta allo stesso modo: miniature, query dei metadati, download degli originali, upload e chiamate di ricerca sollecitano parti diverse del percorso, quindi confronta azioni identiche prima di concludere che “Immich da remoto” sia un’unica modalità di prestazioni.
La LAN elimina gran parte della variabilità del percorso WAN
Su una LAN cablata o con un segnale Wi-Fi forte, client e server sono generalmente separati solo da pochi hop locali di switching o routing. Il tempo di andata e ritorno è basso e la famiglia controlla gran parte del percorso, quindi le piccole chiamate API e molte richieste di miniature possono essere completate con un’attesa di rete minima.
Il modello diretto rispetto a quello con relay descritto nella tecnica NAT traversal aiuta a spiegare la differenza. Un client remoto può raggiungere lo stesso server tramite un tunnel WAN diretto o attraverso un relay, mentre il client sulla LAN segue semplicemente il percorso locale. L’endpoint dell’applicazione può essere identico anche quando le condizioni di trasporto non lo sono.
Una LAN più veloce non dimostra che il server sia efficiente con ogni carico di lavoro. La bassa latenza locale può nascondere richieste inefficienti o uno storage lento, perché l’attesa di rete è ridotta. Mantieni le metriche del server nel confronto, così una diagnosi del percorso remoto non finisce per giustificare un collo di bottiglia del backend che interessa entrambi i percorsi.
L’upload domestico diventa la capacità di download da remoto
Quando qualcuno fuori casa apre foto archiviate su un server domestico, il server invia i dati tramite la direzione di upload della connessione Internet della famiglia. Molte connessioni residenziali hanno una capacità upstream molto inferiore rispetto alla rete Ethernet o Wi-Fi locale, quindi gli originali e le anteprime di grandi dimensioni possono essere limitati dalla larghezza di banda anche quando la navigazione sulla LAN è istantanea.
Una discussione della community sull’accesso remoto per la famiglia mostra perché le famiglie valutano più della semplice connettività: il percorso deve anche essere semplice e affidabile per gli utenti non tecnici. Prestazioni, autenticazione ed esperienza utente fanno tutte parte del percorso remoto pratico.
La larghezza di banda non è la spiegazione corretta quando piccoli controlli dei metadati, filtri o operazioni di accesso sono lenti mentre i trasferimenti di grandi dimensioni raggiungono la velocità prevista. Questo schema indica più probabilmente latenza, routing delle richieste, comportamento del proxy, DNS o tempo di risposta del server.
I proxy e i tunnel aggiungono confini di elaborazione e configurazione
Una richiesta remota può terminare il TLS su un proxy, attraversare un’altra rete di container o passare attraverso una rete overlay cifrata prima di raggiungere Immich. I livelli configurati correttamente possono aggiungere un overhead minimo, ma ogni livello introduce un ulteriore punto in cui buffering, gestione degli header, criteri di timeout, selezione del percorso o problemi di MTU possono influire su richieste specifiche.
Una segnalazione del 2026 di un utente di Immich sui ritardi dei filtri da remoto ha infine individuato un problema di configurazione del percorso dell’endpoint, dopo aver preso in considerazione anche le prestazioni del relay. L’esempio è utile perché due meccanismi distinti producevano sintomi simili, ovvero “da remoto è lento”.
Non cambiare tecnologia di accesso remoto basandoti sul caricamento di una sola pagina. Innanzitutto, identifica se l’operazione problematica è un trasferimento, una richiesta API, l’autenticazione o la creazione della connessione. Un proxy inverso non può risolvere un uplink domestico saturo e un tunnel più veloce non può risolvere una query lenta al database.
La memorizzazione nella cache può rendere impari i test tra LAN e remoto
Un telefono sulla LAN potrebbe avere già in cache miniature, stato della sessione, risposte DNS o risorse consultate di recente, mentre il test remoto potrebbe iniziare da uno stato più freddo. Confrontare queste due esecuzioni può amplificare la differenza di rete, perché un client sta richiedendo meno dati al server.
La spiegazione di ZimaSpace sulla latenza dello storage ribadisce la necessità di mantenere sotto controllo lo stato della cache e del carico di lavoro quando si confrontano le prestazioni. La stessa disciplina vale per i test dei percorsi: usa, per quanto possibile, lo stesso account, lo stesso insieme di risorse, lo stesso client e la stessa condizione della cache.
Il meccanismo LAN rispetto a WAN smette di spiegare una discrepanza che persiste quando entrambi i test vengono fatti passare attraverso lo stesso percorso o quando cresce allo stesso modo il tempo di risposta lato server. A quel punto, analizza l’applicazione o l’host invece di continuare a ottimizzare la topologia di rete.
Costruisci un confronto dei percorsi basato sulle stesse azioni
Scegli quattro azioni: caricare lo stesso album, aprire la stessa foto di grandi dimensioni, eseguire la stessa ricerca nota e caricare lo stesso file di test. Registra il tempo osservato dal client, il tempo della richiesta sul server quando disponibile, la latenza di andata e ritorno, il throughput del trasferimento e se il percorso remoto è diretto, gestito da proxy o instradato tramite relay.
Confronta le esecuzioni sulla LAN e da remoto partendo da uno stato della cache noto, quindi modifica una sola variabile del percorso alla volta. La discussione di Tailscale sulle connessioni dirette e con relay offre un modello utile per classificare i percorsi. Se migliorano solo i trasferimenti di grandi dimensioni, la larghezza di banda è il limite più probabile.
Considera confermata la diagnosi quando il percorso modificato migliora l’operazione prevista dal meccanismo senza cambiare il carico di lavoro del server. Mantieni il design remoto più semplice che soddisfi gli obiettivi di accesso e prestazioni della famiglia; livelli aggiuntivi di proxy, tunnel o relay dovrebbero esistere per una chiara ragione di raggiungibilità o sicurezza.
Prodotti consigliati
Hub Tecnologico e AI
Altro da leggere
I modelli open stanno raggiungendo l’IA all’avanguardia: il 2026 sarà l’anno in cui l’IA locale diventerà abbastanza valida?
I modelli open stanno diventando abbastanza validi per un numero crescente di carichi di lavoro di IA locali, mentre i modelli cloud di frontiera...
NVIDIA PAIR trasforma la tua rete domestica in un cluster AI locale: ti serve ancora un unico grande server con GPU?
NVIDIA PAIR distribuisce le richieste di IA locale su più PC, rendendo la potenza di calcolo più elastica, mentre un server domestico può mantenere...
Immich funziona in modo affidabile dietro CGNAT o doppio NAT?
CGNAT e doppio NAT non compromettono l’uso locale di Immich. Complicano soprattutto l’accesso remoto diretto in ingresso e possono imporre percorsi alternativi o inoltrati.
