Warum schlägt die Anmeldung bei Home Assistant nach einem Neustart des Reverse-Proxys fehl?

Wenn die Anmeldung bei Home Assistant nur nach einem Neustart des Reverse-Proxys fehlschlägt, testen Sie zuerst die direkte Anmeldung über das LAN und lassen Sie die Benutzerdatenbank unverändert, bis der Proxy-Pfad isoliert wurde.

Ein Proxy-Neustart kann seine Containeradresse, weitergeleitete Clientinformationen, die WebSocket-Verarbeitung, das DNS-Ziel oder das Upstream-Backend ändern, ohne ein Home-Assistant-Passwort zu verändern. Daher sind das Löschen von Konten und pauschale Sitzungszurücksetzungen keine guten ersten Maßnahmen. Vergleichen Sie die direkte Home-Assistant-URL mit dem normalen Proxy-Hostnamen, speichern Sie die Browser- und Proxyfehler und ermitteln Sie, ob der Fehler vor der Authentifizierung, während der Anmeldeanforderung oder beim Öffnen der dauerhaften Verbindung durch das Frontend auftritt.

Trennen Sie zunächst die Home-Assistant-Authentifizierung vom Proxy-Pfad

Verwenden Sie dasselbe bekannte funktionierende Konto über die direkte lokale Home-Assistant-Adresse und über den öffentlichen oder internen Proxy-Hostnamen. Wenn die direkte Anmeldung funktioniert, während der Proxy-Pfad fehlschlägt, sind das Konto und der Authentifizierungsstatus von Core wahrscheinlich intakt genug, um sie unverändert zu lassen. Wenn beide Pfade fehlschlagen, richten Sie die Untersuchung wieder auf Home Assistant, den wiederhergestellten Zustand oder die Zugangsdaten.

In einem Fall zur Anmeldung über einen Reverse-Proxy wich das direkte Verhalten vom Apache-Pfad ab, bis WebSocket- und Proxydetails korrigiert wurden. Ein solcher Vergleich zwischen direktem Zugriff und Proxyzugriff ist diagnostisch hilfreicher als das wiederholte Ändern von Passwörtern.

Erfassen Sie HTTP-Status, Weiterleitungskette, Browserkonsolenfehler, Upstream-Antwort des Proxys und den entsprechenden Zeitstempel im Home-Assistant-Log, bevor Sie die Konfiguration ändern. Ein 400-Fehler durch einen nicht vertrauenswürdigen Proxy, ein fehlgeschlagenes WebSocket, eine Weiterleitung auf das falsche Schema und ein ungültiges Passwort sind unterschiedliche Fehler, auch wenn auf dem Bildschirm dieselbe allgemeine Verbindungsfehlermeldung erscheint.

Die vier Ursachen auf Proxy-Seite hinterlassen unterschiedliche Spuren

Die häufigsten Ursachen sind eine geänderte Proxy-Quelladresse, die nicht mehr zur Trusted-Proxy-Regel passt, Änderungen an weitergeleiteten Headern oder am Schema, eine fehlerhafte Behandlung des WebSocket-Upgrades sowie eine Weiterleitung an das falsche Home-Assistant-Backend. Die Neuerstellung eines Proxy-Containers kann eine dieser Bedingungen ändern, während die Home-Assistant-Instanz selbst stabil bleibt.

Ein aktueller Fall zur Fehlerbehebung bei einem Reverse-Proxy zeigt, dass Home Assistant weitergeleiteten Datenverkehr ablehnte, bis der unmittelbare Proxy in den korrekten vertrauenswürdigen Bereich aufgenommen wurde. Diese Prüfung der Identität des vertrauenswürdigen Proxys ist sicherer, als den Bereich dauerhaft zu erweitern: Überprüfen Sie, welche Proxyadresse Home Assistant tatsächlich erreicht, und vertrauen Sie nur dieser Grenze.

Verwenden Sie die folgenden Merkmale und ändern Sie jeweils nur einen Bereich. Lassen Sie nach dem Test keinen breiten Trusted-Proxy-Bereich bestehen; dadurch wird ein wichtiger Schutz gegen gefälschte weitergeleitete Clientadressen entfernt.

Ursache 1: Der Neustart hat die Proxy-Quelladresse geändert

• Merkmal: Anforderungen werden sofort abgelehnt, und die Home-Assistant-Logs nennen einen nicht vertrauenswürdigen Reverse-Proxy.
• Prüfung: Vergleichen Sie Subnetz und Adresse des Proxy-Containers mit dem konfigurierten vertrauenswürdigen Bereich.
• WENN–DANN: Wenn die Wiederherstellung des korrekten, eng gefassten vertrauenswürdigen Bereichs die Anmeldung behebt, lassen Sie Konto- und Sitzungsstatus unverändert.

Ursache 2: Der weitergeleitete Host oder das Schema stimmt nicht mehr mit dem öffentlichen Ursprung überein

• Merkmal: Weiterleitungen wechseln zwischen HTTP/HTTPS oder alternativen Hostnamen, oder Cookies scheinen an einen unerwarteten Ursprung gebunden zu sein.
• Prüfung: Vergleichen Sie Host und weitergeleitetes Schema vor und nach dem Neustart.
• WENN–DANN: Wenn die Korrektur dieser Werte den Weiterleitungs-/Anmeldezyklus behebt, lag der Fehler an der Identität des Eingangs und nicht an den Home-Assistant-Benutzern.

Ursache 3: Die Anmeldeseite wird geladen, aber das WebSocket-Upgrade schlägt fehl

• Merkmal: Die statische Benutzeroberfläche wird geladen, danach trennt das Frontend die Verbindung oder kann die Initialisierung nicht abschließen.
• Prüfung: Untersuchen Sie die WebSocket-Anforderung im Browser und die Upgrade-Header des Proxys.
• WENN–DANN: Wenn der direkte Zugriff das WebSocket offen hält, der Zugriff über den Hostnamen jedoch nicht, bleiben Sie auf der Proxy-Ebene.

Ursache 4: Der Proxy verweist auf ein anderes oder neu erstelltes Backend

• Merkmal: Der Server wirkt neu konfiguriert, bekannte Benutzer fehlen oder der serverspezifische Zustand unterscheidet sich beim Zugriff über den Proxy.
• Prüfung: Vergleichen Sie Upstream-Adresse, Identität der Instanz und Konfigurationspfad.
• WENN–DANN: Wenn der Proxy den falschen Container oder die falsche wiederhergestellte Instanz erreicht, korrigieren Sie die Weiterleitung, bevor Sie Authentifizierungsdaten ändern.

Nutzen Sie das WebSocket-Verhalten, um einen Frontend-Fehler nicht fälschlich als Anmeldefehler einzustufen

Das Frontend von Home Assistant ist nach dem ersten HTTP-Austausch auf eine dauerhafte WebSocket-Verbindung angewiesen. Ein Proxy kann die Anmeldeseite daher erfolgreich ausliefern, aber kurz darauf beim Upgrade der Verbindung oder beim Offenhalten der Verbindung scheitern. Benutzer beschreiben diese Abfolge oft als Anmeldefehler, weil sie unmittelbar nach der Übermittlung der Zugangsdaten auftritt.

Bei einer Home-Assistant-Reverse-Proxy-Konfiguration auf Synology wurde der Anmeldepfad erreicht, schlug jedoch weiterhin fehl, bis die Behandlung des WebSocket-Upgrades korrigiert wurde. Die Prüfung des WebSocket-Upgrade-Verhaltens über den Proxy verhindert unnötige Zurücksetzungen von Benutzern, wenn der HTTP-Anmeldepfad bereits ordnungsgemäß funktioniert.

Wenn der Socket fehlschlägt, überprüfen Sie die Upgrade-Verarbeitung mit HTTP/1.1, Zeitüberschreitungen, TLS-Terminierung, Hostnamen sowie CDN- oder Authentifizierungs-Middleware vor dem Proxy. Halten Sie die Änderungen eng begrenzt. Fügen Sie keine unverbundenen Header aus einem anderen Proxy-Stack hinzu, sofern die fehlgeschlagene Anforderung nicht zeigt, warum sie erforderlich sind.

-15% OFF

ZimaBoard 2 – Mini-Heimserver für Ihre große Idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Validieren Sie die Fehlerbehebung durch zwei Proxy-Neustarts und einen sauberen Client

Melden Sie sich nach der passenden Fehlerbehebung über den normalen Hostnamen an und wieder ab, öffnen Sie ein Dashboard lange genug, um die Stabilität des WebSockets zu bestätigen, und wiederholen Sie den Test in einem privaten Browserfenster oder mit einem zweiten Client. Starten Sie den Proxy anschließend zweimal neu und booten Sie den Proxy-Host neu, wenn dessen Containeradresse oder Netzwerk als vermutete Ursache infrage kommt.

Der Vergleich von LAN- und Remote-Pfaden von Home Assistant durch ZimaSpace folgt demselben Isolationsprinzip: Bewahren Sie den funktionierenden lokalen Anwendungspfad, während Sie die zusätzlichen DNS-, TLS-, Proxy- und Routing-Ebenen testen, die remote verwendet werden.

Der Test ist bestanden, wenn die direkte Anmeldung und die Anmeldung über den Proxy dieselbe Home-Assistant-Instanz erreichen, die erwartete eng gefasste Proxyadresse vertrauenswürdig ist, Weiterleitungen das vorgesehene Schema und den vorgesehenen Host beibehalten, das WebSocket während der normalen Nutzung bestehen bleibt und ein Proxy-Neustart das Ergebnis nicht verändert. Untersuchen Sie die Home-Assistant-Authentifizierung erst dann weiter, wenn dasselbe bekannte funktionierende Konto auch über den direkten Pfad fehlschlägt.