Waarom mislukt het inloggen bij Home Assistant na een herstart van de reverse proxy?

Eva Wong

IceWhale author

Eva Wong is de Technisch Schrijver en en vaste knutselaar bij ZimaSpace. Een levenslange geek met een passie voor homelabs en open-source software, zij is gespecialiseerd in het vertalen van complexe technische concepten naar toegankelijke, praktische handleidingen. Eva gelooft dat zelf-hosting leuk moet zijn, niet intimiderend. Met haar tutorials stelt ze de community in staat om hardware-setup te ontrafelen, van het bouwen van hun eerste NAS tot het beheersen van Docker-containers.

Why Does Home Assistant Login Fail After a Reverse Proxy Restart? - Zima Store Online

Als inloggen bij Home Assistant alleen mislukt na een herstart van de reverse proxy, test dan eerst rechtstreeks via het LAN en laat de gebruikersdatabase ongewijzigd totdat het proxypad is geïsoleerd.

Een proxyherstart kan het containeradres, doorgestuurde clientgegevens, de WebSocket-afhandeling, het DNS-doel of de upstream-backend wijzigen zonder dat een Home Assistant-wachtwoord verandert. Daardoor zijn accounts verwijderen en alle sessies resetten geen goede eerste stappen. Vergelijk de directe Home Assistant-URL met de normale proxied hostnaam, bewaar de browser- en proxyfouten en bepaal of de fout optreedt vóór de authenticatie, tijdens het inlogverzoek of wanneer de frontend zijn permanente verbinding opent.

Begin met het scheiden van Home Assistant-authenticatie en het proxypad

Gebruik hetzelfde bekende werkende account via het directe lokale Home Assistant-adres en via de openbare of interne prox-hostnaam. Als rechtstreeks inloggen werkt terwijl het proxypad faalt, zijn het account en de authenticatiestatus van Core waarschijnlijk gezond genoeg om ongemoeid te laten. Als beide paden falen, richt het onderzoek dan weer op Home Assistant, de herstelde status of de inloggegevens zelf.

In een geval met een reverse proxy vertoonde rechtstreeks gedrag verschillen met het Apache-pad totdat WebSocket- en proxydetails waren gecorrigeerd. Zo’n vergelijking tussen rechtstreeks en via de proxy levert meer diagnostische informatie op dan herhaaldelijk wachtwoorden wijzigen.

Noteer de HTTP-status, de omleidingsketen, de fout in de browserconsole, de upstreamreactie van de proxy en het bijbehorende tijdstip in het Home Assistant-logboek voordat je de configuratie wijzigt. Een 400-fout door een niet-vertrouwde proxy, een mislukte WebSocket, een omleiding naar het verkeerde schema en een ongeldig wachtwoord zijn verschillende fouten, ook al toont het scherm dezelfde algemene melding dat er geen verbinding kan worden gemaakt.

De vier oorzaken aan proxyzijde hebben verschillende kenmerken

De meest voorkomende vertakkingen zijn een gewijzigd bronadres van de proxy dat niet langer overeenkomt met de regel voor vertrouwde proxy’s, wijzigingen in doorgestuurde headers of het schema, een defecte afhandeling van de WebSocket-upgrade en routering naar de verkeerde Home Assistant-backend. Door het opnieuw aanmaken van een proxycontainer kan een van deze zaken veranderen terwijl de Home Assistant-instantie zelf stabiel blijft.

Een recente casus voor het oplossen van problemen met een reverse proxy laat zien dat Home Assistant doorgestuurd verkeer afwees totdat de directe proxy in het juiste vertrouwde bereik werd geplaatst. Deze controle van de identiteit van de vertrouwde proxy is veiliger dan het bereik permanent verbreden: controleer welk proxyadres Home Assistant daadwerkelijk bereikt en vertrouw alleen die grens.

Gebruik de onderstaande kenmerken en wijzig steeds slechts één vertakking tegelijk. Laat na het testen geen breed bereik voor vertrouwde proxy’s staan; daarmee verwijder je een belangrijke bescherming tegen vervalste doorgestuurde clientadressen.

Oorzaak 1: De herstart wijzigde het bronadres van de proxy

Kenmerk: verzoeken worden direct afgewezen en Home Assistant-logboeken vermelden een niet-vertrouwde reverse proxy.
Controle: vergelijk het subnet/adres van de proxycontainer met het geconfigureerde vertrouwde bereik.
ALS–DAN: als het herstellen van het juiste beperkte vertrouwde bereik het inloggen oplost, laat het account en de sessiestatus ongewijzigd.

Oorzaak 2: De doorgestuurde host of het schema komt niet langer overeen met de openbare oorsprong

Kenmerk: omleidingen springen tussen HTTP/HTTPS of alternatieve hostnamen, of cookies lijken gekoppeld aan een onverwachte oorsprong.
Controle: vergelijk Host en het doorgestuurde schema vóór en na de herstart.
ALS–DAN: als het corrigeren van deze waarden de omleidings-/inloglus oplost, lag de fout bij de toegangsidentiteit en niet bij de Home Assistant-gebruikers.

Oorzaak 3: De inlogpagina wordt geladen, maar de WebSocket-upgrade mislukt

Kenmerk: de statische gebruikersinterface wordt geladen, waarna de frontend de verbinding verbreekt of de initialisatie niet kan voltooien.
Controle: inspecteer het WebSocket-verzoek in de browser en de upgradeheaders van de proxy.
ALS–DAN: als rechtstreekse toegang de WebSocket open houdt terwijl toegang via de hostnaam dat niet doet, blijf dan in de proxylayer zoeken.

Oorzaak 4: De proxy verwijst naar een andere of nieuwe backend

Kenmerk: de server lijkt nieuw geconfigureerd, bekende gebruikers zijn verdwenen of de serverspecifieke status verschilt via de proxy.
Controle: vergelijk het upstreamadres, de identiteit van de instantie en het configuratiepad.
ALS–DAN: als de proxy de verkeerde container of herstelde instantie bereikt, corrigeer dan eerst de routering voordat je authenticatiegegevens aanpast.

Gebruik WebSocket-gedrag om een frontendfout niet ten onrechte als inlogfout aan te merken

De frontend van Home Assistant is na de eerste HTTP-uitwisseling afhankelijk van een permanente WebSocket-verbinding. Een proxy kan de inlogpagina daarom succesvol aanbieden, maar kort daarna falen wanneer de verbinding wordt geüpgraded of open blijft. Gebruikers beschrijven die volgorde vaak als een inlogfout omdat deze direct na het invoeren van de inloggegevens optreedt.

Een reverse-proxyopstelling van Home Assistant op Synology bereikte het inlogpad, maar bleef falen totdat de afhandeling van de WebSocket-upgrade was gecorrigeerd. Controle van het gedrag van proxied WebSocket-upgrades voorkomt onnodig werk aan het resetten van gebruikers wanneer het HTTP-inlogpad al goed functioneert.

Als de socket faalt, controleer dan de upgradeafhandeling van HTTP/1.1, time-outs, TLS-beëindiging, hostnaam en eventuele CDN- of authenticatiemiddleware vóór de proxy. Houd de wijzigingen beperkt. Voeg geen ongerelateerde headers toe die je uit een andere proxystack hebt gekopieerd, tenzij het mislukte verzoek aantoont waarom ze nodig zijn.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

Valideer de oplossing via twee proxyherstarts en een schone client

Log na de gerichte oplossing in en uit via de normale hostnaam, open een dashboard lang genoeg om te bevestigen dat de WebSocket stabiel blijft en herhaal dit vanuit een privébrowservenster of met een tweede client. Start de proxy daarna tweemaal opnieuw en herstart de proxyhost als het containeradres of netwerk daarvan deel uitmaakt van de vermoedelijke oorzaak.

De vergelijking van ZimaSpace tussen lokale en externe Home Assistant-paden past hetzelfde isolatieprincipe toe: behoud het gezonde lokale applicatiepad terwijl je de extra DNS-, TLS-, proxy- en routeringslagen test die op afstand worden gebruikt.

De test is geslaagd wanneer rechtstreeks en via de proxy inloggen naar dezelfde Home Assistant-instantie leidt, het verwachte beperkte proxyadres wordt vertrouwd, omleidingen het bedoelde schema en de bedoelde host behouden, de WebSocket tijdens normaal gebruik actief blijft en een proxyherstart het resultaat niet verandert. Onderzoek Home Assistant-authenticatie pas verder wanneer hetzelfde bekende werkende account ook via het directe pad faalt.