Warum verliert Home Assistant nach einer Proxy- oder DNS-Änderung Sitzungen?

Der Verlust einer Sitzung nach einer Proxy- oder DNS-Änderung ist in der Regel auf eine Abweichung zwischen dem URL-Ursprung, den der Client verwendet, und der Route zurückzuführen, die Home Assistant jetzt erkennt – nicht auf beschädigte Benutzerkonten.

Ein Browser kann weiterhin Cookies und den Frontend-Status für den alten Hostnamen gespeichert haben, während ein Smartphone die neue Adresse auflöst. Oder der Proxy liefert zwar die Anmeldeseite aus, schlägt aber beim authentifizierten WebSocket fehl. Beginnen Sie mit einem privaten Browserfenster und einem direkten Test im lokalen Netzwerk, notieren Sie für jedes Ergebnis das genaue Schema und den Hostnamen, und löschen Sie nicht alle Sitzungen, bevor die fehlerhafte Ebene identifiziert wurde.

Trennen Sie den Status eines einzelnen Clients von einem gemeinsamen Pfadfehler

Öffnen Sie Home Assistant in einem privaten Fenster über die vorgesehene endgültige URL und vergleichen Sie das Ergebnis mit dem betroffenen Browser und der mobilen App. Notieren Sie, ob die Anmeldung abgeschlossen wird, ob das Dashboard fünf Minuten lang verbunden bleibt und ob ein Neuladen der Seite die Sitzung beibehält. Dieser reversible Vergleich prüft einen veralteten Client-Status, ohne den Server zu verändern.

Ein Proxy kann die Anmeldeseite zurückgeben, während das authentifizierte Frontend später eine fehlende Verbindung meldet. Dieser Verbindungsfehler trotz erfolgreicher Anmeldung zeigt, warum die Darstellung von HTML kein Beweis dafür ist, dass der gesamte Sitzungspfad funktioniert.

Wenn nur der alte Browser fehlschlägt und das private Fenster stabil bleibt, entfernen Sie auf diesem Client die Websitedaten für die alten und neuen Home-Assistant-Ursprünge und melden Sie sich anschließend erneut an. Wenn jeder Client über die Proxy-URL fehlschlägt, der direkte Zugriff im lokalen Netzwerk jedoch funktioniert, behalten Sie den Client-Status bei und untersuchen Sie den Proxy-Pfad.

Überprüfen Sie WebSocket- und Forwarded-Origin-Verarbeitung

Untersuchen Sie während der Anmeldung die Netzwerkansicht des Browsers oder das Proxy-Protokoll und achten Sie auf das WebSocket-Upgrade, den Status, den Zeitpunkt der Trennung, das weitergeleitete Schema, den weitergeleiteten Host und die Client-Adresse. Entscheidend ist der Unterschied zwischen einer geladenen HTTP-Seite und einem dauerhaften authentifizierten Kanal, der erfolgreich aufgerüstet wird und geöffnet bleibt.

Bei der Fehlerbehebung von Home-Assistant-Reverse-Proxys wird WebSocket-Weiterleitung wiederholt als separate Voraussetzung gegenüber gewöhnlichem HTTP-Proxying genannt. Verwenden Sie diesen Mechanismus nur zur Interpretation des Upgrade-Pfads, nicht als Beweis dafür, dass eine einzige Nginx-Konfiguration für jeden Proxy geeignet ist.

Wenn das Upgrade fehlschlägt, korrigieren Sie ausschließlich die Proxy-Route, die Upgrade-Header, das weitergeleitete Schema oder die Grenze des vertrauenswürdigen Proxys, bei der die Protokolle einen Fehler zeigen. Wenn es erfolgreich ist und die Verbindung bestehen bleibt, lassen Sie den Proxy unverändert und untersuchen Sie stattdessen DNS- und Client-Ursprungsdaten.

Vergleichen Sie DNS-Antworten und endgültige URLs

Lösen Sie den Home-Assistant-Hostnamen vom fehlerhaften Client, einem funktionierenden Client und dem Proxy-Host aus auf. Vergleichen Sie IPv4, IPv6, Split-DNS-Antworten, den Zertifikatsnamen, das Weiterleitungsziel und die in der Begleit-App gespeicherte URL. Eine DNS-Änderung ist erst abgeschlossen, wenn Clients denselben vorgesehenen Endpunkt unter demselben kanonischen Hostnamen erreichen.

Der übergeordnete Zusammenhang zwischen Erkennung, Namensauflösung und Routing wird im Erreichbarkeitsmodell von Home Assistant dargestellt. Nutzen Sie es, um eine veraltete DNS-Antwort von einem Fehler auf Sitzungsebene zu unterscheiden.

Wenn Clients unterschiedliche Endpunkte auflösen, warten Sie die dokumentierte TTL ab oder leeren Sie den Resolver-Cache nur auf dem betroffenen Client und dem lokalen Resolver. Erstellen Sie keine konkurrierenden temporären Hostnamen, da jeder zusätzliche Ursprung eine weitere Cookie- und Weiterleitungsgrenze erzeugt.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Testen Sie den ursprünglichen Sitzungspfad erneut und eskalieren Sie gezielt

Melden Sie sich über die endgültige öffentliche oder private URL an, lassen Sie ein aktives Dashboard geöffnet, laden Sie eine verschachtelte Ansicht neu, wechseln Sie einmal das Netzwerk, falls der Fernzugriff Teil des Designs ist, und wiederholen Sie den Test nach einem Neustart eines Clients. Der Test gilt als bestanden, wenn dieselbe kanonische URL, ein stabiler WebSocket und eine erhaltene Sitzung über das ursprüngliche auslösende Ereignis hinweg gewährleistet sind.

Wenn der saubere Client funktioniert, aber ein vorhandener Client weiterhin fehlschlägt, reparieren Sie nur das Profil dieses Clients oder die Verbindung der App. Wenn alle Proxy-Clients mit denselben Hinweisen auf ein Upgrade- oder Weiterleitungsproblem fehlschlagen, machen Sie die letzte Proxy- oder DNS-Änderung rückgängig und sichern Sie die Protokolle, bevor Sie eine weitere Änderung vornehmen.

Eskalieren Sie den Fall mit der genauen URL-Klasse, bei der der Fehler auftritt, den DNS-Antworten, den Proxy-Statuscodes, dem WebSocket-Ergebnis, Zeitstempeln und dem Client-Vergleich. Beenden Sie die Untersuchung, sobald zwei verschiedene Clients ihre Sitzungen über Neuladen und erneute Verbindung hinweg beibehalten; weitere Cookie- oder Proxy-Änderungen erhöhen dann nur das Risiko, ohne diagnostischen Nutzen zu bringen.