Se l’accesso a Home Assistant non riesce solo dopo il riavvio di un reverse proxy, prova prima l’accesso diretto dalla LAN e lascia invariato il database degli utenti finché non avrai isolato il percorso del proxy.
Un riavvio del proxy può modificare l’indirizzo del container, le informazioni inoltrate sul client, la gestione dei WebSocket, la destinazione DNS o il backend upstream senza modificare alcuna password di Home Assistant. Per questo, eliminare account e reimpostare tutte le sessioni non sono buone prime mosse. Confronta l’URL diretto di Home Assistant con il normale hostname usato dal proxy, salva gli errori del browser e del proxy e stabilisci se il problema si verifica prima dell’autenticazione, durante la richiesta di accesso o quando il frontend apre la connessione persistente.
Inizia separando l’autenticazione di Home Assistant dal percorso del proxy
Usa lo stesso account sicuramente funzionante tramite l’indirizzo locale diretto di Home Assistant e tramite l’hostname pubblico o interno del proxy. Se l’accesso diretto funziona mentre il percorso del proxy non funziona, è probabile che l’account e lo stato di autenticazione di Core siano sufficientemente integri da poter essere lasciati invariati. Se entrambi i percorsi non funzionano, sposta l’indagine su Home Assistant, sullo stato ripristinato o sulle credenziali.
In un caso di accesso tramite reverse proxy, il comportamento diretto differiva da quello attraverso Apache finché i dettagli di WebSocket e proxy non sono stati corretti. Questo tipo di confronto diretto-versus-proxy è più diagnostico del cambiare ripetutamente le password.
Prima di modificare la configurazione, annota il codice di stato HTTP, la catena di reindirizzamenti, l’errore nella console del browser, la risposta upstream del proxy e l’orario corrispondente nei log di Home Assistant. Un errore 400 dovuto a un proxy non attendibile, un WebSocket non riuscito, un reindirizzamento allo schema errato e una password non valida sono problemi diversi, anche se la schermata mostra la stessa generica impossibilità di connessione.
Le quattro cause lato proxy lasciano tracce diverse
I casi più comuni sono un indirizzo sorgente del proxy cambiato che non corrisponde più alla regola per i proxy attendibili, variazioni nelle intestazioni inoltrate o nello schema, una gestione interrotta dell’upgrade WebSocket e l’instradamento verso un backend Home Assistant errato. La ricreazione di un container proxy può modificare uno di questi elementi mentre l’istanza di Home Assistant rimane stabile.
Un recente caso di risoluzione dei problemi di un reverse proxy mostra Home Assistant che rifiutava il traffico inoltrato finché il proxy immediato non è stato inserito nell’intervallo attendibile corretto. Questo controllo dell’identità del proxy attendibile è più sicuro che ampliare permanentemente l’intervallo: verifica quale indirizzo del proxy raggiunge effettivamente Home Assistant e considera attendibile solo quel confine.
Usa le tracce riportate di seguito e modifica un solo ramo alla volta. Dopo il test, non lasciare attivo un intervallo ampio di proxy attendibili: eliminerebbe un’importante protezione contro gli indirizzi client inoltrati contraffatti.
Causa 1: il riavvio ha modificato l’indirizzo sorgente del proxy
- Traccia: le richieste vengono rifiutate immediatamente e i log di Home Assistant identificano un reverse proxy non attendibile.
- Controllo: confronta la subnet o l’indirizzo del container proxy con l’intervallo attendibile configurato.
- SE–ALLORA: se il ripristino dell’intervallo attendibile corretto e ristretto risolve l’accesso, lascia invariati l’account e lo stato delle sessioni.
Causa 2: l’host o lo schema inoltrato non corrisponde più all’origine pubblica
- Traccia: i reindirizzamenti passano da HTTP a HTTPS o da un hostname alternativo all’altro, oppure i cookie risultano associati a un’origine imprevista.
- Controllo: confronta l’host e lo schema inoltrato prima e dopo il riavvio.
- SE–ALLORA: se la correzione di questi valori risolve il ciclo di reindirizzamento/accesso, il problema riguardava l’identità in ingresso e non gli utenti di Home Assistant.
Causa 3: la pagina di accesso viene caricata, ma l’upgrade WebSocket non riesce
- Traccia: l’interfaccia statica viene caricata, poi il frontend si disconnette o non riesce a completare l’inizializzazione.
- Controllo: esamina la richiesta WebSocket nel browser e le intestazioni di upgrade del proxy.
- SE–ALLORA: se l’accesso diretto mantiene aperto il WebSocket mentre l’hostname non ci riesce, continua a lavorare sul livello del proxy.
Causa 4: il proxy punta a un backend diverso o nuovo
- Traccia: il server sembra appena configurato, gli utenti conosciuti scompaiono oppure lo stato specifico del server differisce quando si accede tramite il proxy.
- Controllo: confronta l’indirizzo upstream, l’identità dell’istanza e il percorso di configurazione.
- SE–ALLORA: se il proxy raggiunge il container o l’istanza ripristinata errata, correggi l’instradamento prima di intervenire sui dati di autenticazione.
Usa il comportamento del WebSocket per evitare di scambiare un problema del frontend per un problema di accesso
Il frontend di Home Assistant dipende da una connessione WebSocket persistente dopo lo scambio HTTP iniziale. Un proxy può quindi fornire correttamente la pagina di accesso, ma fallire pochi istanti dopo, quando la connessione viene aggiornata o deve rimanere aperta. Gli utenti spesso descrivono questa sequenza come un problema di accesso perché si verifica subito dopo l’invio delle credenziali.
Una configurazione di reverse proxy di Home Assistant su Synology raggiungeva il percorso di accesso, ma continuava a non funzionare finché la gestione dell’upgrade WebSocket non è stata corretta. Controllare il comportamento dell’upgrade WebSocket tramite proxy evita di perdere tempo reimpostando gli utenti quando il percorso di accesso HTTP è già funzionante.
Se il socket non funziona, verifica la gestione dell’upgrade HTTP/1.1, i timeout, la terminazione TLS, l’hostname e qualsiasi middleware CDN o di autenticazione posto davanti al proxy. Mantieni ristretto l’insieme delle modifiche. Non aggiungere intestazioni non correlate copiate da un altro stack proxy, a meno che la richiesta non riuscita dimostri perché siano necessarie.
Convalida la correzione attraverso due riavvii del proxy e un client pulito
Dopo aver applicato la correzione appropriata, accedi e disconnettiti tramite l’hostname normale, apri una dashboard abbastanza a lungo da confermare che il WebSocket rimanga stabile e ripeti il test da una finestra di navigazione privata o da un secondo client. Poi riavvia due volte il proxy e riavvia l’host del proxy se l’indirizzo del container o la rete rientrano tra le cause sospette.
Il confronto di ZimaSpace tra i percorsi LAN e remoti di Home Assistant applica lo stesso principio di isolamento: preserva il percorso locale funzionante dell’applicazione mentre testi i livelli aggiuntivi di DNS, TLS, proxy e routing usati da remoto.
Il test è superato quando l’accesso diretto e quello tramite proxy raggiungono la stessa istanza di Home Assistant, l’indirizzo ristretto previsto del proxy è considerato attendibile, i reindirizzamenti mantengono lo schema e l’host desiderati, il WebSocket rimane attivo durante l’uso normale e un riavvio del proxy non modifica il risultato. Passa all’indagine sull’autenticazione di Home Assistant solo quando lo stesso account sicuramente funzionante non riesce ad accedere neppure tramite il percorso diretto.
Supporto e consigli
Altro da leggere

Come ottimizzare le connessioni al database di Home Assistant per container simultanei
Ottimizza un database Recorder esterno in base alle connessioni attive e alla latenza misurate, senza aumentare il numero massimo di connessioni né copiare il...

Come evitare duplicati di processi o importazioni in Home Assistant
Usa tracce e chiavi operative univoche per rendere sicuri i nuovi tentativi di automazioni e importazioni, evitando di generare azioni o record duplicati.

Come riparare Home Assistant dopo che il volume del database si è riempito
Recupera da un volume Recorder completamente pieno senza eliminare prima le prove, poi riduci la crescita e dimostra che la cronologia e le automazioni...

