Varför förlorar Home Assistant sessioner efter en proxy- eller DNS-ändring?
Sessionsförlust efter en proxy- eller DNS-ändring beror vanligtvis på en avvikelse mellan den URL-ursprungspunkt som klienten använder och den rutt som Home Assistant nu ser, inte på skadade användarkonton.
En webbläsare kan fortfarande ha cookies och frontendtillstånd för det gamla värdnamnet, medan en telefon slår upp den nya adressen, eller så kan proxyn visa inloggningssidan men misslyckas med den autentiserade WebSocket-anslutningen. Börja med ett privat webbläsarfönster och ett direkt test via det lokala nätverket, dokumentera exakt schema och värdnamn för varje resultat och undvik att ta bort alla sessioner tills det felande lagret har identifierats.
Skilj klienttillstånd från ett gemensamt sökvägsfel
Öppna Home Assistant i ett privat fönster med den avsedda slutliga URL:en och jämför sedan med den berörda webbläsaren och mobilappen. Dokumentera om inloggningen slutförs, om instrumentpanelen förblir ansluten i fem minuter och om en siduppdatering bevarar sessionen. Denna reversibla jämförelse testar gammalt klienttillstånd utan att ändra servern.
En proxy kan returnera inloggningssidan medan den autentiserade frontenddelen senare rapporterar att den inte kan ansluta. Detta anslutningsfel efter lyckad inloggning visar varför återgivning av HTML inte är ett bevis på att hela sessionsvägen fungerar.
Om bara den gamla webbläsaren misslyckas och det privata fönstret förblir stabilt, tar du bort webbplatsdata för de gamla och nya Home Assistant-ursprungen på den klienten och loggar sedan in igen. Om alla klienter misslyckas med proxy-URL:en men direkt åtkomst via det lokala nätverket fungerar, bevarar du klienttillståndet och går vidare till proxysökvägen.
Verifiera WebSocket- och vidarebefordrad ursprungshantering
Granska webbläsarens nätverksvy eller proxyloggen under inloggningen och observera WebSocket-uppgraderingen, statusen, frånkopplingens tidpunkt, vidarebefordrat schema, vidarebefordrat värdnamn och klientadress. Den viktiga skillnaden är en HTTP-sida som laddas jämfört med en beständig autentiserad kanal som uppgraderas och förblir öppen.
Felsökning av omvänd proxy för Home Assistant identifierar upprepade gånger vidarebefordran av WebSocket som ett separat krav från vanlig HTTP-proxying. Använd den mekanismen endast för att tolka uppgraderingsvägen, inte som bevis på att en Nginx-konfiguration passar alla proxyer.
Om uppgraderingen misslyckas korrigerar du endast proxyrutten, uppgraderingsrubrikerna, det vidarebefordrade schemat eller gränsen för betrodd proxy som loggarna visar är felaktig. Om den lyckas och förblir ansluten lämnar du proxyn oförändrad och undersöker i stället DNS- och klientens ursprungstillstånd.
Jämför DNS-svar och slutliga URL:er
Slå upp Home Assistant-värdnamnet från den felande klienten, en fungerande klient och proxyvärden. Jämför IPv4, IPv6, svar från delad DNS, certifikatnamn, omdirigeringsmål och URL:en som lagras i den medföljande appen. En DNS-ändring är slutförd först när klienterna når den avsedda slutpunkten under samma kanoniska värdnamn.
Det bredare sambandet mellan identifiering, namnupplösning och routning beskrivs i modellen för Home Assistants nåbarhet. Använd den för att skilja ett gammalt DNS-svar från ett fel på sessionslagret.
Om klienterna slår upp olika slutpunkter väntar du på den dokumenterade TTL-tiden eller rensar resolvercachen endast på den berörda klienten och den lokala resolvern. Skapa inte konkurrerande tillfälliga värdnamn, eftersom varje ytterligare ursprung skapar ännu en cookie- och omdirigeringsgräns.
Testa den ursprungliga sessionsvägen igen och eskalera avgränsat
Logga in via den slutliga publika eller privata URL:en, håll en aktiv instrumentpanel öppen, ladda om en kapslad vy, byt nätverk en gång om fjärråtkomst ingår i lösningen och upprepa sedan efter en omstart av en klient. Ett godkänt test kräver samma kanoniska URL, en stabil WebSocket-anslutning och en bevarad session genom den ursprungliga utlösande händelsen.
Om den rena klienten fungerar men en befintlig klient fortfarande misslyckas, reparerar du endast den klientens profil eller appanslutning. Om alla proxyklienter misslyckas med samma belägg för uppgraderings- eller omdirigeringsproblem återställer du den senaste proxy- eller DNS-ändringen och sparar loggarna innan du provar en annan ändring.
Eskalera med den exakta klassen för den felande URL:en, DNS-svaren, proxyns statuskoder, WebSocket-resultatet, tidsstämplarna och klientjämförelsen. Avsluta när två olika klienter behåller sessionerna efter uppdatering och återanslutning; ytterligare cookie- eller proxyändringar ökar då risken utan att ge något diagnostiskt värde.
Rekommenderade produkter
Support och tips
Mer att läsa
Så optimerar du Immich-databasanslutningar för samtidiga containrar
Höj inte max_connections först. Mät Immich-sessionerna, summera alla containers behov, behåll utrymme för administratörsåtkomst och justera bara den flaskhals som har bevisats.
Så förhindrar du duplicerade jobb eller importer i Immich
Separera upprepade jobb från duplicerade resurser. Använd en enda kanonisk inläsningsväg, kontrollera omförsök och sökvägsändringar och testa sedan återinmatning på en liten grupp.
Så reparerar du Immich när dess databasvolym blir full
Ta aldrig bort PostgreSQL-WAL för att frigöra utrymme. Stoppa skrivningar till Immich, bevara databastillståndet, lägg till säker lagringskapacitet, återställ PostgreSQL och förhindra sedan att...
