Kan Home Assistant fungera bakom en reverse proxy på en undersökväg?

Eva Wong

IceWhale author

Eva Wong är Teknisk skribent och den boende fixaren på ZimaSpace. En livslång nörd med en passion för hemma-labb och öppen källkod, hon specialiserar sig på att översätta komplexa tekniska koncept till tillgängliga, praktiska guider. Eva tror att självhosting ska vara roligt, inte skrämmande. Genom sina handledningar ger hon gemenskapen verktyg att avmystifiera hårdvaruinstallationer, från att bygga sin första NAS till att bemästra Docker-containrar.

Can Home Assistant Work Behind a Reverse Proxy on a Subpath? - Zima Store Online

Home Assistant kan köras bakom en omvänd proxy, men att tillförlitligt tillhandahålla tjänsten från en omskriven undersökväg är i allmänhet inte en stödd driftsgräns.

En sida på example.com/homeassistant kan returnera HTML medan efterföljande förfrågningar fortfarande riktas mot rotbaserade resurser, autentiseringsvägar, WebSockets eller integrationsåteranrop. Testa mer än den första skärmen: använd en ny webbläsare, logga in, öppna en instrumentpanel i realtid, ladda om en kapslad väg och slutför ett återanrop. Om något lager tappar prefixet bör du flytta Home Assistant till ett eget värdnamn i stället för att lägga till fler omskrivningar.

Skilj stöd för omvänd proxy från stöd för undersökvägar

En omvänd proxy kan avsluta TLS och vidarebefordra en förfrågan till Home Assistant från värdnamnets rot. En undersökväg innebär ett annat krav: varje genererad URL, resurs, API-anrop, WebSocket, omdirigering och återanrop måste konsekvent bevara ett prefix som applikationen förstår. Att det fungerar på proxynivå innebär inte att applikationskontraktet är uppfyllt.

Tester i Home Assistant-communityn leder till en tydlig slutsats: applikationen stöder inte driftsättning under ett URL-prefix. Det fastställda svaret om att lägga Home Assistant i en undersökväg rekommenderar ett underdomännamn oavsett val av proxy.

GODKÄNT för stöd för omvänd proxy innebär att Home Assistant fungerar vid roten av ett dedikerat värdnamn med korrekt vidarebefordran. UNDERKÄNT för den föreslagna undersökvägen innebär att en eller flera applikationsvägar tappar prefixet. Blanda inte ihop dessa slutsatser och hävda att omvända proxyservrar i sig är inkompatibla.

Använd frontendresurser som det första testet med låg risk

Öppna den föreslagna undersökvägen i en privat webbläsarprofil och granska nätverksförfrågningarna innan du ändrar Home Assistant. Om grunddokumentet läses in men JavaScript, ikoner, manifest eller översättningar begär sökvägar från värdnamnets rot, har topologin redan misslyckats med sitt första reversibla test.

Ett dokumenterat försök med sökvägsomskrivning returnerade huvudsidan medan frontendresurser begärde snedstrecksbaserade URL:er utan Home Assistant-prefixet. Det misslyckandet med rotbaserade resurser är en mismatch mellan applikationens sökvägar, inte en saknad fil på proxyn.

GODKÄNT innebär att varje frontendresurs returneras korrekt under den avsedda vägen. UNDERKÄNT innebär att 404-svar eller förfrågningar till rotvägar förekommer. Avsluta där och testa ett dedikerat värdnamn; ersättning i svarstext är skört eftersom framtida frontendbyggen kan introducera nya sökvägar som omskrivningen inte täcker.

Testa WebSockets, autentisering och kapslade vägar

Ett statiskt skal för en instrumentpanel är inte en fullständig session. Logga in från en ren profil, övervaka entitetsuppdateringar i flera minuter, uppdatera en kapslad URL för instrumentpanelen, logga ut och logga sedan in igen. Kontrollera därefter om HTTP-uppgraderingar, token, omdirigeringar och omladdningar av vägar behåller samma offentliga ursprung och sökväg.

Home Assistant är starkt beroende av WebSockets för kommunikation i frontend i realtid, så en proxy måste bevara uppgraderingssökvägen och rubrikerna. En användares redogörelse för hantering av WebSockets via omvänd proxy visar varför det inte räcker att bara läsa in HTML som kompatibilitetstest.

GODKÄNT innebär att autentisering, realtidsuppdateringar, navigering och direkta omladdningar fungerar utan fel i sökvägsöversättningen. Även ett UNDERKÄNT resultat som är begränsat till sockets eller omdirigeringar innebär att undersökvägsdesignen ska avvisas. Att åtgärda ett proxydirektiv bevisar inte att återanrop och framtida vägar kommer att förstå prefixet.

Featured

ZimaCube 2 personlig molnhem NAS

ZimaCube2

Välj ett dedikerat värdnamn som stabil gräns

Publicera Home Assistant vid roten av ett dedikerat värdnamn, till exempel ha.example.com, och dirigera sedan värdnamnet genom den omvända proxyn till den interna tjänsten. Detta bevarar ett offentligt ursprung utan att kräva att applikationen förstår ett sökvägsprefix. Ett privat VPN eller en tunnel kan ge samma rena rotgräns utan offentlig exponering.

När en befintlig fjärrsökväg slutar fungera efter nätverksändringar bör du verifiera DNS, offentlig adress, NAT, tunnel och proxyrouting separat. ZimaSpaces diagnostik för fjärråtkomst efter en routerändring tillhandahåller den angränsande kontrollen av sökvägen.

Alternativet är godkänt när en ren webbläsare kan läsa in resurser, upprätta en WebSocket, autentisera, uppdatera kapslade vägar och nå Home Assistant efter en omstart av proxyn. Behåll den gamla vägen endast så länge som krävs för att kunna återställa DNS- eller proxyändringar; kör inte två tvetydiga offentliga URL:er på obestämd tid.

Avsluta när hela sessionen överlever en omstart

Starta om proxyn och Home Assistant en gång och upprepa sedan hela testet från det lokala nätverket och det avsedda fjärrnätverket. Bekräfta certifikatnamnet, den vidarebefordrade klientadressen, gränsen för betrodd proxy, inloggning, realtidsstatus, utloggning och ett integrationsåteranrop. Detta är den ursprungliga arbetsbelastningen, inte ett förenklat test av en statisk sida.

Förklara endast rotvärdnamnsdesignen som godkänd om den klarar varje steg. En undersökväg som fungerar endast efter anpassad omskrivning av svar förblir en driftmässig skuld utan stöd, eftersom en uppdatering kan ändra beteendet för resurser eller återanrop. Dokumentera det fungerande värdnamnet, uppströmsadressen och återställningskonfigurationen.

Eskalera när rotvärdnamnsdesignen fortfarande misslyckas, eftersom den återstående orsaken sannolikt är proxytillit, WebSocket-vidarebefordran, DNS, certifikat eller routing snarare än stöd för basvägar. Exponera inte Home Assistant direkt på en oskyddad port enbart för att bevara den önskade URL-strukturen.