L’accesso a Immich non riesce dopo il riavvio del proxy inverso
Se l’accesso a Immich non riesce solo dopo il riavvio del reverse proxy, verifica innanzitutto se il percorso attraverso il proxy si è interrotto mentre l’applicazione Immich e l’account continuano a funzionare direttamente.
Un riavvio può portare alla luce indirizzi upstream obsoleti, l’assenza di appartenenza a una rete condivisa, modifiche agli header, problemi nella gestione dei cookie oppure un processo proxy riavviato prima che le sue dipendenze fossero nuovamente raggiungibili. Prova lo stesso account tramite l’endpoint Immich locale e tramite il normale hostname pubblico, quindi segui il primo livello in cui i due percorsi divergono.
Usa l’accesso diretto per distinguere il problema di autenticazione da quello del proxy
Prova un account noto sul server Immich tramite un percorso locale affidabile che aggiri il reverse proxy. Se l’accesso diretto riesce mentre l’hostname pubblico resta in caricamento, reindirizza o restituisce un errore upstream, il record dell’utente e il percorso di autenticazione principale sono probabilmente integri. Concentra l’indagine su proxy, TLS, routing e stato del browser.
Un caso della community in cui l’accesso diretto funzionava mentre quello tramite proxy non riusciva illustra questo metodo di isolamento. Il report è specifico per una determinata versione, quindi usalo per giustificare il confronto tra i percorsi, non per presumere la stessa causa principale.
Se sia l’accesso diretto sia quello tramite proxy non riescono, smetti di modificare le impostazioni del proxy. Controlla invece lo stato del servizio Immich, la connettività al database, lo stato dell’account e i log del server. Il riavvio del proxy avvenuto vicino al momento del problema potrebbe essere una coincidenza; il test di bypass impedisce di trasformare quella coincidenza temporale in una diagnosi non dimostrata.
Verifica che il proxy possa raggiungere l’upstream Immich corrente
Dopo il riavvio del proxy, verifica che possa risolvere e raggiungere l’upstream Immich dal proprio namespace di rete. In Docker, un upstream basato sul nome del servizio all’interno di una rete definita dall’utente e condivisa è generalmente più stabile di un IP del container copiato manualmente, che cambia quando il container viene ricreato.
Una discussione su un’interruzione del reverse proxy relativa alla connettività tra proxy e Immich mostra perché sia necessario controllare la raggiungibilità dell’upstream e il supporto WebSocket del proxy prima di recuperare l’account. Considera la configurazione esatta come un’indicazione circoscritta, non come un modello valido per ogni proxy.
Riavvia il proxy da solo due volte e verifica se l’upstream viene risolto ogni volta nello stesso servizio. Il test è superato quando la connessione riesce immediatamente senza modificare gli indirizzi. Se la risoluzione dei nomi, l’appartenenza alla rete o la porta di destinazione cambiano dopo la ricreazione, correggi la definizione della rete in Compose invece di riavviare ripetutamente l’intero stack.
Controlla gli header inoltrati, il TLS e la gestione dei cookie
L’accesso può non riuscire anche quando il proxy restituisce la pagina di Immich, perché l’autenticazione dipende dall’intero percorso HTTP. Confronta la configurazione del proxy prima e dopo il riavvio, inclusi l’inoltro dell’host e dello schema, la terminazione HTTPS, i reindirizzamenti, eventuali riscritture dei cookie e l’eventuale presenza di un secondo proxy o tunnel che modifica anch’esso la risposta.
Una discussione della community di Immich documenta un caso di accesso con cookie duplicati in cui la gestione dei cookie da parte del proxy causava un caricamento infinito durante l’accesso. Si tratta di un caso circoscritto, ma ricorda l’importanza di controllare la risposta e i cookie nel browser invece di presumere che credenziali valide garantiscano una sessione tramite proxy correttamente avviata.
Non eliminare tutti gli account e non reimpostare il database solo perché una sessione del browser sembra bloccata. Dopo aver registrato i cookie e la risposta originali, usa una finestra privata o un secondo browser. Se un client pulito funziona, cancella solo i dati del sito interessato e correggi la regola del proxy che ha creato il cookie o il reindirizzamento errato.
Leggi i log di accesso e di errore del proxy all’ora esatta della richiesta fallita
Riproduci un tentativo di accesso e annota l’ora esatta, l’hostname pubblico, il client e lo stato restituito. Poi controlla i log di accesso e di errore del proxy relativi a quella richiesta. Distingui una richiesta che non ha mai raggiunto il proxy, un errore 4xx o 5xx generato dal proxy, un errore di connessione all’upstream e una richiesta arrivata a Immich che ha ricevuto una risposta dall’applicazione.
Il metodo di troubleshooting dei log NGINX mostra come lo stato, gli errori upstream, i tempi delle richieste e il logging mirato forniscano indicazioni molto più affidabili del semplice aggiornamento ripetuto della pagina di accesso. Applica lo stesso principio a Caddy, Traefik o a un altro proxy.
Se il log del proxy mostra una risposta upstream riuscita mentre il browser non completa l’accesso, controlla reindirizzamenti, cookie, TLS e stato del client. Se il proxy non riesce a connettersi all’upstream, correggi il routing o la disponibilità del servizio. Se è Immich stesso a restituire l’errore, segui il log del server corrispondente invece di considerare il proxy la causa.
Verifica che la correzione resista al riavvio che ha originariamente causato il problema
Dopo aver corretto la causa confermata, ripeti esattamente l’evento scatenante: riavvia solo il reverse proxy, attendi il superamento del controllo di integrità ed esegui l’accesso tramite l’hostname pubblico. Poi apri una risorsa esistente, carica un file di piccole dimensioni e mantieni attiva la sessione abbastanza a lungo da verificare il normale traffico API.
La guida di ZimaSpace sui percorsi di accesso remoto controllati fornisce il contesto più ampio: il proxy è solo uno dei livelli dell’accesso remoto, quindi DNS, TLS, autenticazione e upstream privato devono rimanere configurati intenzionalmente e monitorabili.
Considera il test superato solo quando l’accesso resiste a due riavvii del proxy e la stessa configurazione si avvia correttamente dopo un riavvio completo dello stack. Ripristina le modifiche recenti al proxy se una nuova regola per gli header o i cookie ha creato il problema. In caso di escalation, includi il diff della configurazione del proxy, lo stato della richiesta, l’errore upstream, l’ora del log del server e il risultato del test diretto rispetto a quello tramite proxy.
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...
