Perché Home Assistant perde le sessioni dopo una modifica al proxy o al DNS?
La perdita della sessione dopo una modifica al proxy o al DNS di solito deriva da una discrepanza tra l’origine dell’URL utilizzata dal client e il percorso che Home Assistant ora rileva, non da account utente danneggiati.
Un browser potrebbe conservare ancora cookie e stato dell’interfaccia per il vecchio hostname, mentre un telefono risolve il nuovo indirizzo; in alternativa, il proxy potrebbe mostrare la pagina di accesso ma non riuscire a gestire il WebSocket autenticato. Inizia con una finestra di navigazione privata e un test diretto sulla LAN, annota lo schema e l’hostname esatti per ogni risultato ed evita di eliminare tutte le sessioni finché non avrai identificato il livello che causa il problema.
Separa lo stato di un singolo client da un problema del percorso condiviso
Apri Home Assistant in una finestra privata usando l’URL finale previsto, quindi confrontalo con il browser interessato e con l’app mobile. Annota se l’accesso viene completato, se il pannello rimane connesso per cinque minuti e se un aggiornamento della pagina mantiene la sessione. Questo confronto reversibile verifica la presenza di uno stato obsoleto del client senza modificare il server.
Un proxy può restituire la pagina di accesso mentre l’interfaccia autenticata segnala successivamente l’impossibilità di connettersi. Questo fallimento della connessione dopo un accesso riuscito dimostra perché il rendering dell’HTML non prova che l’intero percorso della sessione funzioni.
Se solo il vecchio browser presenta problemi e la finestra privata rimane stabile, rimuovi i dati del sito relativi alle origini vecchia e nuova di Home Assistant su quel client, quindi accedi di nuovo. Se ogni client presenta problemi sull’URL del proxy ma l’accesso diretto alla LAN funziona, conserva lo stato dei client e passa all’analisi del percorso del proxy.
Verifica la gestione di WebSocket e dell’origine inoltrata
Durante l’accesso, esamina la vista di rete del browser o il log del proxy e osserva l’aggiornamento a WebSocket, lo stato, il momento della disconnessione, lo schema inoltrato, l’host inoltrato e l’indirizzo del client. La distinzione utile è tra una pagina HTTP che viene caricata e un canale autenticato persistente che esegue l’upgrade e rimane aperto.
La risoluzione dei problemi dei proxy inversi di Home Assistant identifica ripetutamente l’inoltro WebSocket come un requisito distinto dal normale proxy HTTP. Usa questo meccanismo solo per interpretare il percorso di upgrade, non come prova che una configurazione Nginx sia adatta a ogni proxy.
Se l’upgrade non riesce, correggi solo il percorso del proxy, le intestazioni di upgrade, lo schema inoltrato o il confine del proxy attendibile che i log indicano come errato. Se riesce e la connessione rimane stabile, lascia invariato il proxy e analizza invece il DNS e lo stato dell’origine del client.
Confronta le risposte DNS e gli URL finali
Risolvi l’hostname di Home Assistant dal client che presenta problemi, da un client funzionante e dall’host del proxy. Confronta IPv4, IPv6, le risposte DNS suddivise, il nome nel certificato, la destinazione del reindirizzamento e l’URL memorizzato nell’app companion. Una modifica DNS è completa solo quando i client raggiungono l’endpoint previsto usando lo stesso hostname canonico.
La relazione più ampia tra rilevamento, risoluzione dei nomi e routing è descritta nel modello di raggiungibilità di Home Assistant. Usalo per distinguere una risposta DNS obsoleta da un problema a livello di sessione.
Se i client risolvono endpoint diversi, attendi il TTL documentato oppure svuota la cache del resolver solo sul client interessato e sul resolver locale. Non creare hostname temporanei in concorrenza, perché ogni origine aggiuntiva crea un altro confine per cookie e reindirizzamenti.
Ripeti il test del percorso della sessione originale e procedi per gradi
Accedi tramite l’URL finale pubblico o privato, mantieni aperto un pannello attivo, ricarica una vista annidata, cambia rete una volta se l’accesso remoto fa parte della configurazione e ripeti il test dopo il riavvio di un client. Il test ha esito positivo se l’URL canonico rimane lo stesso, il WebSocket è stabile e la sessione viene mantenuta dopo l’evento che ha originato il problema.
Se il client pulito funziona ma un client esistente continua a non funzionare, intervieni solo sul profilo di quel client o sulla connessione dell’app. Se tutti i client del proxy presentano la stessa evidenza relativa all’upgrade o al reindirizzamento, annulla l’ultima modifica al proxy o al DNS e conserva i log prima di tentare un’altra modifica.
Quando chiedi assistenza, fornisci la classe esatta dell’URL che non funziona, le risposte DNS, i codici di stato del proxy, il risultato del WebSocket, gli orari e il confronto tra i client. Interrompi la diagnosi quando due client diversi mantengono le sessioni dopo un aggiornamento e una riconnessione: ulteriori modifiche a cookie o proxy aggiungerebbero rischio senza fornire valore diagnostico.
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...
