Varför misslyckas inloggningen till Home Assistant efter en omstart av reverse proxy-servern?
Om inloggningen till Home Assistant endast misslyckas efter en omstart av reverse proxyn, testa direkt inloggning via LAN först och låt användardatabasen vara oförändrad tills proxyvägen har isolerats.
En omstart av proxyn kan ändra dess containeradress, vidarebefordrad klientinformation, WebSocket-hantering, DNS-mål eller uppströmsbackend utan att ändra något Home Assistant-lösenord. Därför är det dåliga första åtgärder att ta bort konton och återställa alla sessioner. Jämför den direkta Home Assistant-URL:en med det vanliga proxade värdnamnet, spara webbläsarens och proxyns felmeddelanden och fastställ om felet uppstår före autentiseringen, under inloggningsbegäran eller när frontendgränssnittet öppnar sin beständiga anslutning.
Börja med att skilja Home Assistant-autentisering från proxyvägen
Använd samma fungerande konto via den direkta lokala Home Assistant-adressen och via det offentliga eller interna proxyvärdnamnet. Om direkt inloggning fungerar medan proxyvägen misslyckas är kontot och Cores autentiseringstillstånd sannolikt tillräckligt friska för att lämnas orörda. Om båda vägarna misslyckas bör du återgå till att undersöka Home Assistant, det återställda tillståndet eller själva inloggningsuppgifterna.
I ett fall med reverse-proxyinloggning skilde sig det direkta beteendet från Apache-vägen tills WebSocket- och proxydetaljerna korrigerades. En sådan jämförelse mellan direkt åtkomst och proxyåtkomst ger bättre diagnostik än att upprepade gånger ändra lösenord.
Anteckna HTTP-status, omdirigeringskedja, webbläsarens konsolfel, proxyns svar från uppströmsservern och motsvarande tidsstämpel i Home Assistant-loggen innan du ändrar konfigurationen. Ett 400-fel från en opålitlig proxy, en misslyckad WebSocket, en omdirigering till fel schema och ett ogiltigt lösenord är olika fel, även om skärmen visar samma generiska meddelande om att anslutningen inte kan upprättas.
De fyra proxyrelaterade orsakerna lämnar olika spår
De vanligaste orsakerna är att proxyns ändrade källadress inte längre matchar regeln för betrodda proxyservrar, förändrade vidarebefordrade headers eller schema, bruten hantering av WebSocket-uppgradering samt dirigering till fel Home Assistant-backend. Återskapandet av en proxycontainer kan ändra något av detta medan själva Home Assistant-instansen förblir stabil.
Ett nyligt felsökningsfall med reverse proxy visar att Home Assistant avvisade vidarebefordrad trafik tills den omedelbara proxyn placerades i rätt betrott intervall. Denna kontroll av proxyidentiteten är säkrare än att permanent bredda intervallet: kontrollera vilken proxyadress som faktiskt når Home Assistant och lita endast på den gränsen.
Använd spåren nedan och ändra en gren i taget. Låt inte ett brett intervall för betrodda proxyservrar ligga kvar efter testningen; det tar bort ett viktigt skydd mot förfalskade vidarebefordrade klientadresser.
Orsak 1: Omstarten ändrade proxyns källadress
- Tecken: begäranden avvisas omedelbart och Home Assistant-loggarna identifierar en opålitlig reverse proxy.
- Kontroll: jämför proxycontainerns subnät eller adress med det konfigurerade betrodda intervallet.
- OM–SÅ: om återställning av rätt snäva betrodda intervall löser inloggningen, låt konto- och sessionstillståndet vara oförändrat.
Orsak 2: Den vidarebefordrade värden eller schemat matchar inte längre det offentliga ursprunget
- Tecken: omdirigeringar växlar mellan HTTP/HTTPS eller alternativa värdnamn, eller så verkar cookies vara kopplade till ett oväntat ursprung.
- Kontroll: jämför Host och det vidarebefordrade schemat före och efter omstarten.
- OM–SÅ: om korrigering av dessa värden löser omdirigerings- och inloggningsloopen var felet ingressidentitet, inte Home Assistant-användare.
Orsak 3: Inloggningssidan läses in men WebSocket-uppgraderingen misslyckas
- Tecken: det statiska gränssnittet läses in, men frontend kopplas sedan från eller kan inte slutföra initieringen.
- Kontroll: granska webbläsarens WebSocket-begäran och proxyns uppgraderingsheaders.
- OM–SÅ: om direkt åtkomst håller WebSocket-anslutningen öppen medan värdnamnet inte gör det, fortsätt felsöka i proxylagret.
Orsak 4: Proxyn pekar på en annan eller ny backend
- Tecken: servern verkar nykonfigurerad, kända användare saknas eller serverspecifikt tillstånd skiljer sig via proxyn.
- Kontroll: jämför uppströmsadress, instansidentitet och konfigurationssökväg.
- OM–SÅ: om proxyn når fel container eller återställd instans, korrigera routningen innan du rör autentiseringsdata.
Använd WebSocket-beteendet för att undvika att kalla ett frontendfel för ett inloggningsfel
Home Assistants frontend är beroende av en beständig WebSocket-anslutning efter den första HTTP-kommunikationen. En proxy kan därför visa inloggningssidan korrekt men misslyckas ögonblick senare när anslutningen uppgraderas eller hålls öppen. Användare beskriver ofta denna sekvens som ett inloggningsfel eftersom den inträffar direkt efter att inloggningsuppgifterna har skickats.
En reverse-proxykonfiguration för Home Assistant på Synology nådde inloggningsvägen men misslyckades ändå tills hanteringen av WebSocket-uppgraderingen korrigerades. Genom att kontrollera proxad WebSocket-uppgradering undviker du att slösa tid på att återställa användare när HTTP-inloggningsvägen redan fungerar.
Om socketanslutningen misslyckas ska du validera hantering av HTTP/1.1-uppgradering, tidsgränser, TLS-terminering, värdnamn samt eventuell CDN- eller autentiseringsmellanvara framför proxyn. Håll ändringsmängden liten. Lägg inte till orelaterade headers som kopierats från en annan proxystack om inte den misslyckade begäran visar varför de behövs.
Validera korrigeringen genom två proxyomstarter och en ren klient
Efter den matchande korrigeringen loggar du in och ut via det vanliga värdnamnet, öppnar en instrumentpanel tillräckligt länge för att bekräfta att WebSocket-anslutningen förblir stabil och upprepar sedan testet i ett privat webbläsarfönster eller från en andra klient. Starta därefter om proxyn två gånger och starta om proxyns värd om dess containeradress eller nätverk ingår bland de misstänkta orsakerna.
ZimaSpaces jämförelse av lokala och fjärranslutna Home Assistant-vägar tillämpar samma isoleringsprincip: bevara den fungerande lokala applikationsvägen medan du testar de extra DNS-, TLS-, proxy- och routinglager som används på distans.
Testet är godkänt när både direkt och proxad inloggning når samma Home Assistant-instans, den förväntade snäva proxyadressen är betrodd, omdirigeringar bevarar avsett schema och värdnamn, WebSocket-anslutningen överlever normal användning och en proxyomstart inte förändrar resultatet. Eskalera till felsökning av Home Assistant-autentiseringen först när samma fungerande konto även misslyckas via den direkta vägen.
Rekommenderade produkter
Support och tips
Mer att läsa
Så optimerar du Home Assistant-databasanslutningar för samtidiga containrar
Finjustera en extern Recorder-databas utifrån uppmätta aktiva anslutningar och svarstider, inte genom att höja det maximala antalet anslutningar eller kopiera en annan värds anslutningspool.
Så förhindrar du duplicerade jobb eller importer i Home Assistant
Använd spårningsdata och unika åtgärdsnycklar för att göra automatiseringar och importer säkra att försöka igen utan att skapa dubbla åtgärder eller poster.
Så reparerar du Home Assistant efter att databasvolymen blivit full
Återställ efter en full Recorder-volym utan att först radera bevismaterial, minska sedan tillväxten och bevisa att historik och automatiseringar överlever en omstart.
