Dlaczego Home Assistant traci sesje po zmianie serwera proxy lub DNS?

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 Lose Sessions After a Proxy or DNS Change? - Zima Store Online

Utrata sesji po zmianie serwera proxy lub DNS zwykle wynika z niezgodności między źródłem adresu URL używanym przez klienta a trasą, którą widzi teraz Home Assistant, a nie z uszkodzonych kont użytkowników.

Przeglądarka może nadal przechowywać pliki cookie i stan interfejsu dla starej nazwy hosta, podczas gdy telefon rozpoznaje nowy adres, albo proxy może wyświetlać stronę logowania, ale nie obsługiwać uwierzytelnionego WebSocketu. Zacznij od jednego prywatnego okna przeglądarki i jednego testu bezpośrednio w sieci LAN, zapisz dokładny schemat i nazwę hosta dla każdego wyniku oraz nie usuwaj wszystkich sesji, dopóki nie ustalisz, która warstwa zawodzi.

Oddziel stan jednego klienta od awarii wspólnej ścieżki

Otwórz Home Assistant w prywatnym oknie, używając docelowego końcowego adresu URL, a następnie porównaj wynik z używaną przeglądarką i aplikacją mobilną. Zapisz, czy logowanie się kończy, czy pulpit pozostaje połączony przez pięć minut oraz czy odświeżenie strony zachowuje sesję. To odwracalne porównanie pozwala sprawdzić nieaktualny stan klienta bez zmieniania serwera.

Proxy może zwrócić stronę logowania, podczas gdy uwierzytelniony interfejs później zgłosi brak możliwości połączenia. Ta awaria połączenia mimo pomyślnego logowania pokazuje, dlaczego samo wyświetlenie HTML nie dowodzi, że cała ścieżka sesji działa.

Jeśli zawodzi tylko stara przeglądarka, a prywatne okno pozostaje stabilne, usuń dane witryny dla starych i nowych źródeł Home Assistant na tym kliencie, a następnie zaloguj się ponownie. Jeśli każdy klient zawodzi pod adresem proxy, ale bezpośredni dostęp przez LAN działa, zachowaj stan klientów i przejdź do analizy ścieżki proxy.

Sprawdź obsługę WebSocketu i nagłówków forwarded-origin

Podczas logowania sprawdź widok sieci w przeglądarce lub dziennik proxy i obserwuj uaktualnienie połączenia WebSocket, jego status, moment rozłączenia, przekazany schemat, przekazaną nazwę hosta oraz adres klienta. Istotne jest rozróżnienie między stroną HTTP, która się ładuje, a trwałym uwierzytelnionym kanałem, który przechodzi uaktualnienie i pozostaje otwarty.

Wskazówki dotyczące rozwiązywania problemów z odwrotnym proxy Home Assistant wielokrotnie wskazują przekazywanie WebSocketu jako osobny wymóg względem zwykłego proxy HTTP. Użyj tego mechanizmu wyłącznie do interpretacji ścieżki uaktualnienia, a nie jako dowodu, że jedna konfiguracja Nginx pasuje do każdego proxy.

Jeśli uaktualnienie się nie powiedzie, popraw tylko trasę proxy, nagłówki uaktualnienia, przekazany schemat lub granicę zaufanego proxy, które dzienniki wskazują jako nieprawidłowe. Jeśli zakończy się powodzeniem i połączenie pozostanie aktywne, nie zmieniaj proxy i zbadaj raczej DNS oraz stan źródła adresu URL klienta.

Porównaj odpowiedzi DNS i końcowe adresy URL

Rozwiąż nazwę hosta Home Assistant z poziomu zawodnego klienta, działającego klienta oraz hosta proxy. Porównaj adresy IPv4 i IPv6, odpowiedzi split-DNS, nazwę w certyfikacie, miejsce przekierowania oraz adres URL zapisany w aplikacji towarzyszącej. Zmiana DNS jest zakończona dopiero wtedy, gdy klienci docierają do zamierzonego punktu końcowego pod tą samą kanoniczną nazwą hosta.

Szerszą zależność między wykrywaniem, rozpoznawaniem nazw i routingiem opisuje model dostępności Home Assistant. Wykorzystaj go, aby oddzielić nieaktualną odpowiedź DNS od awarii na poziomie sesji.

Jeśli klienci rozpoznają różne punkty końcowe, poczekaj na udokumentowany TTL lub wyczyść pamięć podręczną resolvera tylko na zawodnym kliencie i lokalnym resolverze. Nie twórz konkurencyjnych tymczasowych nazw hostów, ponieważ każdy dodatkowy origin tworzy kolejną granicę plików cookie i przekierowań.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

Powtórz pierwotną ścieżkę sesji i eskaluj problem w wąskim zakresie

Zaloguj się za pomocą końcowego publicznego lub prywatnego adresu URL, pozostaw otwarty aktywny pulpit, odśwież zagnieżdżony widok, raz przełącz sieć, jeśli dostęp zdalny jest częścią konfiguracji, a następnie powtórz test po ponownym uruchomieniu jednego klienta. Test można uznać za pomyślny, gdy używany jest ten sam kanoniczny adres URL, WebSocket działa stabilnie, a sesja zostaje zachowana po pierwotnym zdarzeniu wywołującym problem.

Jeśli czysty klient działa, ale jeden z istniejących nadal zawodzi, napraw tylko profil tego klienta lub połączenie aplikacji. Jeśli wszystkie klienty proxy zawodzą, dostarczając takie same dowody dotyczące uaktualnienia lub przekierowania, wycofaj ostatnią zmianę proxy lub DNS i zachowaj dzienniki przed wprowadzeniem kolejnej zmiany.

Zgłaszając problem, podaj dokładną klasę zawodnego adresu URL, odpowiedzi DNS, kody statusu proxy, wynik połączenia WebSocket, znaczniki czasu oraz porównanie klientów. Zakończ diagnostykę, gdy dwa różne klienty zachowują sesje po odświeżeniu i ponownym połączeniu; dalsze zmiany plików cookie lub proxy zwiększają wtedy ryzyko, nie dostarczając wartości diagnostycznej.