Waarom verliest Home Assistant sessies na een wijziging van de proxy of DNS?

Sessieverlies na een proxy- of DNS-wijziging ontstaat meestal door een verschil tussen de URL-origin die de client gebruikt en de route die Home Assistant nu ziet, niet door beschadigde gebruikersaccounts.

Een browser kan nog cookies en frontendstatus voor de oude hostnaam bevatten terwijl een telefoon het nieuwe adres omzet, of de proxy kan de inlogpagina aanbieden maar de geauthenticeerde WebSocket niet correct afhandelen. Begin met één privébrowservenster en één directe LAN-test, noteer voor elk resultaat het exacte schema en de hostnaam en verwijder niet alle sessies voordat de falende laag is vastgesteld.

Scheid clientstatus van een gedeeld padprobleem

Open Home Assistant in een privévenster via de beoogde definitieve URL en vergelijk dit met de getroffen browser en mobiele app. Noteer of het inloggen wordt voltooid, of het dashboard vijf minuten verbonden blijft en of vernieuwen van de pagina de sessie behoudt. Deze omkeerbare vergelijking test verouderde clientstatus zonder de server te wijzigen.

Een proxy kan de inlogpagina retourneren terwijl de geauthenticeerde frontend later meldt dat er geen verbinding kan worden gemaakt. Deze verbindingsfout na geslaagde login laat zien waarom het weergeven van HTML geen bewijs is dat het volledige sessiepad werkt.

Als alleen de oude browser faalt en het privévenster stabiel blijft, verwijder dan op die client de sitegegevens voor de oude en nieuwe Home Assistant-origins en meld je opnieuw aan. Als elke client via de proxy-URL faalt maar directe LAN-toegang werkt, behoud dan de clientstatus en richt je op het proxypad.

Controleer WebSocket- en doorgestuurde-originverwerking

Bekijk tijdens het inloggen het netwerkoverzicht van de browser of het proxylogboek en let op de WebSocket-upgrade, status, timing van de verbreking, het doorgestuurde schema, de doorgestuurde host en het clientadres. Het belangrijke onderscheid is een HTTP-pagina die laadt versus een blijvend geauthenticeerd kanaal dat wordt geüpgraded en open blijft.

Bij het oplossen van problemen met een reverse proxy voor Home Assistant wordt WebSocket-doorsturing herhaaldelijk genoemd als een afzonderlijke vereiste naast gewone HTTP-proxying. Gebruik dit mechanisme alleen om het upgradepad te interpreteren, niet als bewijs dat één Nginx-configuratie voor elke proxy geschikt is.

Als de upgrade mislukt, corrigeer dan alleen de proxyr route, upgradeheaders, het doorgestuurde schema of de grens van de vertrouwde proxy waarvan de logboeken aantonen dat die onjuist is. Als de upgrade slaagt en de verbinding open blijft, laat de proxy dan ongewijzigd en onderzoek in plaats daarvan DNS en de originstatus van de client.

Vergelijk DNS-antwoorden en definitieve URL's

Resolveer de Home Assistant-hostnaam vanaf de falende client, een werkende client en de proxyhost. Vergelijk IPv4, IPv6, split-DNS-antwoorden, de certificaatnaam, de omleidingsbestemming en de URL die in de companion-app is opgeslagen. Een DNS-wijziging is pas voltooid wanneer clients hetzelfde bedoelde eindpunt onder dezelfde canonieke hostnaam bereiken.

De bredere samenhang tussen ontdekking, naamomzetting en routering wordt beschreven in het bereikbaarheidsmodel van Home Assistant. Gebruik dit om een verouderd DNS-antwoord te onderscheiden van een fout op sessieniveau.

Als clients verschillende eindpunten oplossen, wacht dan de gedocumenteerde TTL af of wis de resolvercache alleen op de getroffen client en lokale resolver. Maak geen concurrerende tijdelijke hostnamen aan, omdat elke extra origin een nieuwe cookie- en omleidingsgrens creëert.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Test het oorspronkelijke sessiepad opnieuw en schaal gericht op

Meld je aan via de definitieve openbare of privéadres-URL, houd een live dashboard geopend, laad een geneste weergave opnieuw, wissel één keer van netwerk als externe toegang onderdeel van het ontwerp is en herhaal dit na één herstart van de client. De test is geslaagd als dezelfde canonieke URL, een stabiele WebSocket en een behouden sessie aanwezig zijn na de oorspronkelijke aanleiding.

Als de schone client slaagt maar één bestaande client nog steeds faalt, herstel dan alleen dat clientprofiel of die app-verbinding. Als alle proxyclients falen met dezelfde aanwijzingen voor een upgrade- of omleidingsprobleem, draai dan de laatste proxy- of DNS-wijziging terug en bewaar de logboeken voordat je een andere wijziging probeert.

Schaal het probleem op met de exacte categorie van de falende URL, DNS-antwoorden, proxystatuscodes, het WebSocket-resultaat, tijdstippen en de vergelijking tussen clients. Stop zodra twee verschillende clients hun sessies behouden na vernieuwen en opnieuw verbinden; extra cookie- of proxywijzigingen vergroten dan alleen het risico zonder diagnostische waarde.