Immich si apre localmente ma non funziona da remoto dopo una modifica al router
Se Immich continua ad aprirsi sulla rete Wi‑Fi domestica dopo una modifica al router, ma non funziona tramite dati mobili, probabilmente il server è sano e il livello cambiato è il percorso remoto che lo circonda.
Un router sostitutivo o ripristinato può cambiare l’indirizzo LAN del server, cancellare le regole di port forwarding, ottenere un IP pubblico diverso, modificare il comportamento DNS o collocare la connessione dietro una modalità NAT differente. Inizia con un vero test da una rete esterna e procedi dal server verso l’esterno. Modifica un solo livello alla volta: aprire porte aggiuntive prima di sapere quale passaggio ha fallito può aumentare l’esposizione senza ripristinare l’accesso.
Dimostra che il problema riguarda solo l’accesso remoto
Per prima cosa, testa Immich da un dispositivo sulla stessa LAN usando l’attuale indirizzo locale del server. Poi disattiva il Wi‑Fi sul telefono e ripeti il test remoto tramite rete cellulare. Se anche l’accesso locale non funziona, smetti di considerarlo un problema del perimetro del router e ripara prima il server o la rete locale.
Se l’accesso locale funziona ma quello remoto no, annota il nome host remoto esatto, il protocollo e l’errore visualizzato. Un timeout indica qualcosa di diverso da un avviso relativo al certificato o da una pagina di errore del proxy. Annota anche se utilizzi il port forwarding diretto, un reverse proxy, una VPN mesh o un tunnel, perché la sostituzione del router influisce in modo diverso su ciascuno di questi modelli.
Non usare la stessa rete Wi‑Fi domestica come unico test remoto. Alcuni router gestiscono le richieste interne verso il nome host pubblico tramite hairpin NAT, mentre altri no; di conseguenza, un test dalla LAN può produrre un falso fallimento o un falso successo. Al termine di questa fase devi avere un sintomo chiaro: Immich funziona localmente, mentre un determinato percorso esterno non funziona.
Controlla che il router invii ancora il traffico alla stessa destinazione LAN
Un router nuovo assegna spesso all’host Immich un indirizzo privato diverso. Confronta l’attuale indirizzo LAN del server con la destinazione memorizzata in qualsiasi regola di port forwarding, upstream del reverse proxy, oggetto firewall o prenotazione DHCP. Se la regola punta ancora al vecchio indirizzo, correggi questa mappatura prima di intervenire su Immich.
Ricrea solo la regola in ingresso effettivamente necessaria per il modello di accesso scelto. Verifica insieme porta esterna, destinazione interna, porta interna e protocollo. Se utilizzi un reverse proxy, normalmente il router inoltra il traffico al proxy anziché direttamente a Immich; inoltrarlo a entrambi può creare un secondo percorso pubblico non necessario.
Dopo aver corretto la destinazione, ripeti il test tramite rete cellulare e controlla se il proxy o i log del server rilevano la richiesta. Se i log rimangono completamente vuoti, il traffico si interrompe ancora prima di raggiungere l’applicazione. Se la richiesta ora raggiunge il proxy o l’host ma restituisce un errore dell’applicazione, probabilmente il perimetro del router è stato sistemato e la sezione successiva dovrebbe concentrarsi sull’indirizzamento pubblico o sulla risoluzione dei nomi.
Confronta l’IP pubblico, il record DNS e la modalità NAT
La sostituzione del router può coincidere con l’assegnazione di un nuovo lease WAN. Risolvi il nome host utilizzato per Immich e confronta il risultato con l’IP pubblico attualmente assegnato alla connessione domestica. Se differiscono, il nome indirizza i client al vecchio endpoint anche se tutti i servizi locali funzionano correttamente.
Il DNS dinamico mantiene un nome host allineato a un indirizzo pubblico variabile. Se il nome host continua a risolversi nel vecchio indirizzo WAN, i client esterni continueranno a raggiungere la destinazione errata finché il record e le relative cache non si aggiorneranno. Controlla come il DNS dinamico segue gli IP variabili, correggi l’aggiornamento o il record, quindi ripeti il test da un resolver esterno e tramite rete cellulare.
Se l’indirizzo WAN del router non corrisponde all’indirizzo pubblico visibile da Internet, la nuova connessione potrebbe trovarsi dietro un NAT di livello operatore o un altro livello NAT upstream. Con il NAT tra i peer e Internet pubblico, modificare il port forwarding del router domestico potrebbe non rendere mai raggiungibile il servizio. In questo caso, utilizza un indirizzo pubblico, un percorso VPN/overlay o un altro metodo di accesso che non dipenda dall’inoltro in ingresso non richiesto.
Verifica lo stato del reverse proxy, di TLS e del firewall dopo la modifica di rete
Se il traffico esterno raggiunge l’host ma Immich continua a non aprirsi, controlla i livelli di identità che il router non gestisce. Verifica che il reverse proxy punti ancora all’indirizzo e alla porta attuali di Immich, che il nome host corrisponda alla regola del proxy e che il firewall del server consenta il percorso previsto dalla nuova subnet LAN.
Un dominio che raggiunge il sito proxy sbagliato, entra in un ciclo di reindirizzamenti o mostra un errore relativo al nome del certificato non presenta più un semplice problema di port forwarding. Mantieni separati il percorso IP funzionante e quello basato sul nome host che non funziona mentre controlli DNS, SNI, routing Host e qualsiasi URL pubblico configurato. Non rigenerare i certificati alla cieca quando il nome host continua a risolversi nell’indirizzo pubblico errato.
Per un albero decisionale più ampio, separa la raggiungibilità locale dai problemi del percorso pubblico prima di ripetere le correzioni lato server. Una volta dimostrato che Immich funziona localmente, una modifica al router restringe l’indagine allo stato di indirizzamento, NAT, DNS, firewall, proxy e TLS.
Ripeti il test dall’esterno e scegli il percorso di accesso sicuro più semplice
Una volta corretta una causa, ripeti il test originale tramite rete cellulare usando lo stesso nome host e lo stesso client. Poi riavvia una volta il router e una volta l’host Immich. La correzione è duratura solo se il server mantiene la destinazione LAN prevista, il DNS continua a risolversi correttamente e l’accesso remoto torna a funzionare senza interventi manuali.
Se fai affidamento sull’esposizione diretta in ingresso, verifica che sia pubblico solo il percorso HTTPS previsto e rimuovi le vecchie regole temporanee. Per l’accesso riservato alla famiglia, una VPN mesh o un tunnel autenticato può ridurre la dipendenza dal port forwarding e dagli indirizzi pubblici variabili, soprattutto quando il nuovo router o il percorso dell’ISP sono difficili da controllare.
Smetti di apportare modifiche alla rete quando le richieste raggiungono regolarmente il proxy o l’endpoint Immich corretto e il client originale torna a funzionare. Se l’accesso locale continua a funzionare ma nessun pacchetto esterno raggiunge il router nonostante un percorso pubblico/DNS corretto, contatta l’ISP o cambia modello di accesso: è un problema al confine della rete, non un motivo per ricostruire Immich.
Prodotti consigliati
Supporto e consigli
Altro da leggere
Come ottimizzare le connessioni al database di Immich per container simultanei
Non aumentare prima max_connections. Misura le sessioni di Immich, somma la richiesta totale di ogni container, mantieni un margine per l'amministratore e ottimizza solo...
Come impedire la duplicazione di processi o importazioni in Immich
Separa i processi ripetuti dalle risorse duplicate. Utilizza un unico percorso di acquisizione canonico, controlla i nuovi tentativi e le modifiche ai percorsi, quindi...
Come riparare Immich dopo che il volume del database si è riempito
Non eliminare mai il WAL di PostgreSQL per liberare spazio. Interrompi le scritture di Immich, preserva lo stato del database, aggiungi capacità in modo...
