Dlaczego logowanie do Home Assistant kończy się niepowodzeniem po ponownym uruchomieniu odwrotnego serwera proxy?

Eva Wong

IceWhale author

Eva Wong jest Technicznym pisarzem i stałym majsterkowiczem w ZimaSpace. Całe życie geek z pasją do homelabów i oprogramowania open-source, specjalizuje się w tłumaczeniu skomplikowanych koncepcji technicznych na przystępne, praktyczne przewodniki. Eva wierzy, że samodzielne hostowanie powinno być zabawą, a nie czymś onieśmielającym. Poprzez swoje samouczki umożliwia społeczności rozwiewanie tajemnic konfiguracji sprzętu, od budowy pierwszego NAS po opanowanie kontenerów Docker.

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

Jeśli logowanie do Home Assistant nie działa dopiero po restarcie odwrotnego serwera proxy, najpierw przetestuj bezpośrednie logowanie przez sieć LAN i nie zmieniaj bazy użytkowników, dopóki nie odizolujesz ścieżki proxy.

Restart proxy może zmienić adres kontenera, przekazywane informacje o kliencie, obsługę WebSocketów, docelowy rekord DNS lub backend nadrzędny, nie zmieniając żadnego hasła Home Assistant. Dlatego usuwanie kont i masowe resetowanie sesji to złe pierwsze kroki. Porównaj bezpośredni adres URL Home Assistant ze zwykłą nazwą hosta obsługiwaną przez proxy, zapisz błędy przeglądarki i proxy oraz ustal, czy problem występuje przed uwierzytelnieniem, podczas żądania logowania czy w momencie otwierania przez frontend stałego połączenia.

Najpierw oddziel uwierzytelnianie Home Assistant od ścieżki proxy

Użyj tego samego sprawdzonego konta, logując się zarówno przez bezpośredni lokalny adres Home Assistant, jak i przez publiczną lub wewnętrzną nazwę hosta proxy. Jeśli bezpośrednie logowanie działa, a ścieżka proxy nie, konto i stan uwierzytelniania Core są prawdopodobnie wystarczająco sprawne, aby pozostawić je bez zmian. Jeśli obie ścieżki zawodzą, przenieś dochodzenie z powrotem do Home Assistant, przywróconego stanu lub samych danych logowania.

W jednym przypadku dotyczącym logowania przez odwrotny serwer proxy bezpośrednie działanie różniło się od ścieżki Apache do czasu poprawienia obsługi WebSocketów i szczegółów proxy. Tego rodzaju porównanie dostępu bezpośredniego i przez proxy dostarcza więcej informacji diagnostycznych niż wielokrotna zmiana haseł.

Przed zmianą konfiguracji zapisz kod HTTP, łańcuch przekierowań, błąd w konsoli przeglądarki, odpowiedź backendu proxy oraz odpowiadający jej znacznik czasu w logach Home Assistant. Kod 400 od niezaufanego proxy, nieudane połączenie WebSocket, przekierowanie do niewłaściwego schematu i nieprawidłowe hasło to różne awarie, nawet jeśli ekran wyświetla ten sam ogólny komunikat o braku możliwości połączenia.

Cztery przyczyny po stronie proxy mają różne oznaki

Najczęstsze przyczyny to zmieniony adres źródłowy proxy, który nie pasuje już do reguły zaufanego proxy, zmienione przekazywane nagłówki lub schemat, uszkodzona obsługa ulepszenia WebSocket oraz kierowanie do niewłaściwego backendu Home Assistant. Ponowne utworzenie kontenera proxy może zmienić jeden z tych elementów, podczas gdy sama instancja Home Assistant pozostaje stabilna.

Niedawny przypadek diagnostyki odwrotnego proxy pokazuje, że Home Assistant odrzucał przekazywany ruch do czasu umieszczenia bezpośredniego proxy we właściwym zaufanym zakresie. Taka weryfikacja tożsamości zaufanego proxy jest bezpieczniejsza niż trwałe rozszerzanie zakresu: sprawdź, jaki adres proxy rzeczywiście dociera do Home Assistant, i ufaj tylko tej granicy.

Skorzystaj z poniższych oznak i zmieniaj jedną gałąź naraz. Po zakończeniu testów nie pozostawiaj szerokiego zakresu zaufanego proxy; usuwa on ważną ochronę przed fałszowaniem przekazywanych adresów klientów.

Przyczyna 1: Restart zmienił adres źródłowy proxy

Oznaka: żądania są natychmiast odrzucane, a logi Home Assistant wskazują niezaufany odwrotny serwer proxy.
Sprawdź: porównaj podsieć lub adres kontenera proxy ze skonfigurowanym zaufanym zakresem.
JEŚLI–TO: jeśli przywrócenie właściwego, wąskiego zaufanego zakresu naprawi logowanie, pozostaw konto i stan sesji bez zmian.

Przyczyna 2: Przekazywany host lub schemat nie pasuje już do publicznego źródła

Oznaka: przekierowania przełączają się między HTTP i HTTPS albo alternatywnymi nazwami hostów, lub pliki cookie wydają się przypisane do nieoczekiwanego źródła.
Sprawdź: porównaj nagłówek Host i przekazywany schemat przed restartem i po nim.
JEŚLI–TO: jeśli poprawienie tych wartości naprawi cykl przekierowania i logowania, przyczyną była tożsamość ruchu przychodzącego, a nie użytkownicy Home Assistant.

Przyczyna 3: Strona logowania się ładuje, ale ulepszenie WebSocket kończy się niepowodzeniem

Oznaka: statyczny interfejs się ładuje, po czym frontend rozłącza się lub nie może zakończyć inicjalizacji.
Sprawdź: przeanalizuj żądanie WebSocket w przeglądarce oraz nagłówki ulepszenia w proxy.
JEŚLI–TO: jeśli dostęp bezpośredni utrzymuje otwarte połączenie WebSocket, a dostęp przez nazwę hosta nie, pozostań w warstwie proxy.

Przyczyna 4: Proxy wskazuje inny lub świeżo utworzony backend

Oznaka: serwer wygląda na nowo skonfigurowany, znani użytkownicy znikają lub stan właściwy dla serwera różni się w zależności od dostępu przez proxy.
Sprawdź: porównaj adres backendu, tożsamość instancji i ścieżkę konfiguracji.
JEŚLI–TO: jeśli proxy dociera do niewłaściwego kontenera lub przywróconej instancji, najpierw napraw routing, a dopiero potem zmieniaj dane uwierzytelniania.

Wykorzystaj działanie WebSocketów, aby nie mylić awarii frontendu z awarią logowania

Frontend Home Assistant korzysta ze stałego połączenia WebSocket po początkowej wymianie HTTP. Proxy może więc poprawnie wyświetlić stronę logowania, a kilka chwil później zawieść podczas ulepszania połączenia lub utrzymywania go otwartego. Użytkownicy często opisują tę sekwencję jako błąd logowania, ponieważ występuje ona natychmiast po przesłaniu danych uwierzytelniających.

W konfiguracji Home Assistant z odwrotnym proxy na serwerze Synology ścieżka logowania była osiągalna, ale nadal kończyła się niepowodzeniem, dopóki nie poprawiono obsługi ulepszenia WebSocket. Sprawdzenie działania ulepszenia WebSocket przez proxy zapobiega niepotrzebnemu resetowaniu użytkowników, gdy ścieżka logowania HTTP działa już prawidłowo.

Jeśli połączenie gniazdowe nie działa, sprawdź obsługę ulepszenia HTTP/1.1, limity czasu, terminowanie TLS, nazwę hosta oraz wszelkie oprogramowanie CDN lub pośredniczące uwierzytelnianie znajdujące się przed proxy. Ogranicz zakres zmian. Nie dodawaj niezwiązanych nagłówków skopiowanych z innego stosu proxy, chyba że nieudane żądanie wykaże, dlaczego są potrzebne.

-15% OFF

ZimaBoard 2 – Mini serwer domowy dla Twojego wielkiego pomysłu

Single board computer zimaboard2

Zweryfikuj poprawkę po dwóch restartach proxy i na czystym kliencie

Po zastosowaniu właściwej poprawki zaloguj się i wyloguj przez zwykłą nazwę hosta, otwórz pulpit na wystarczająco długo, aby potwierdzić stabilność WebSocketu, a następnie powtórz test w prywatnym oknie przeglądarki lub na drugim kliencie. Potem dwukrotnie zrestartuj proxy i uruchom ponownie hosta proxy, jeśli adres kontenera lub sieć są częścią podejrzanej przyczyny.

Porównanie lokalnych i zdalnych ścieżek Home Assistant przygotowane przez ZimaSpace opiera się na tej samej zasadzie izolacji: zachowaj zdrową lokalną ścieżkę aplikacji podczas testowania dodatkowych warstw DNS, TLS, proxy i routingu używanych zdalnie.

Test uznaj za zakończony pomyślnie, gdy logowanie bezpośrednie i przez proxy prowadzi do tej samej instancji Home Assistant, oczekiwany wąski adres proxy jest zaufany, przekierowania zachowują zamierzony schemat i host, WebSocket pozostaje stabilny podczas normalnego użycia, a restart proxy nie zmienia wyniku. Przejdź do diagnostyki uwierzytelniania Home Assistant dopiero wtedy, gdy to samo sprawdzone konto nie działa również przez ścieżkę bezpośrednią.