Bör Home Assistant använda värdnätverk eller ett bryggat nätverk?
Home Assistant bör använda värdnätverk när LAN-upptäckt är ett absolut krav; bryggnätverk är bättre när explicita portar och isolering är viktigare.
Inget av lägena är universellt snabbare eller säkrare. Valet avgör vilket nätverksnamnområde Home Assistant ser, hur multicast- och broadcastupptäckt når det, vilka portar du publicerar och hur andra containrar ansluter. Utgå från de integrationer som måste fungera efter omstart och testa sedan upptäckt, direktstyrning, MQTT- eller radiogateways samt fjärråtkomst via valt läge innan du betraktar konfigurationen som stabil.
Kontrollera först om Home Assistant måste ta emot LAN-upptäcktstrafik
Många Home Assistant-integrationer kan använda en känd IP-adress eller en brokeranslutning, men andra är beroende av mDNS, SSDP, UPnP eller broadcastupptäckt. Dessa protokoll är den främsta anledningen till att värdnätverk är vanligt för Container-installationer: Home Assistant deltar direkt i värdens LAN-namnområde i stället för att kräva vidarebefordran av multicast över en Docker-brygga.
En guide om Docker-nätverk förklarar att värdnätverk tar bort brygggränsen, vilket gör broadcastbaserade tjänster enklare men också tar bort Dockers portpublicering och separeringen av nätverksnamnområden. För de flesta Home Assistant-installationer är denna avvägning viktigare än den råa genomströmningen.
Lista de integrationer som faktiskt behöver upptäckt. Om alla kritiska enheter använder explicita adresser, MQTT, Zigbee via en mappad koordinator eller en annan väldefinierad slutpunkt kan bryggläge fungera smidigt. Om flera integrationer är beroende av lokal upptäckt och du inte vill underhålla multicastreläer är värdläge vanligtvis det enklare driftvalet.
Värdnätverk är rätt när enkel upptäckt väger tyngre än isolering av namnområden
I värdläge binder Home Assistant direkt till värdens nätverksstack. Det finns inget lager för Docker-portmappning, och containern ser värdens gränssnitt på ett sätt som vanligtvis passar bättre för lokal upptäckt. Nackdelen är svagare nätverksisolering och att portkonflikter måste hanteras på värdnivå.
En genomgång av en Home Assistant-design med Docker kommer fram till samma villkorade slutsats: värdläge förenklar mDNS- och UPnP-upptäckt, medan bryggläge gör nätverksgränser och publicerade portar tydligare.
Välj värdläge när upptäcktsproblem återkommer och servern är en betrodd hemmaserver med ett kontrollerat antal tjänster. Använd inte värdläge enbart för att dölja ett okänt anslutningsproblem. Om en enhet fortfarande inte fungerar med värdnätverk kan orsaken vara VLAN-regler, Wi-Fi-klientisolering, lokal DNS, enhetsbehörigheter eller ett problem på integrationsnivå snarare än Dockers brygga.
Bryggnätverk är rätt när integrationerna har explicit åtkomlighet
Bryggläge ger containern en privat Docker-adress och låter dig publicera endast de Home Assistant-portar som ska vara åtkomliga. Andra containrar kan kommunicera via namngivna Docker-nätverk, medan LAN-enheter når den publicerade värdporten. Detta ger en tydligare gräns när upptäckt inte är nödvändig eller när du medvetet proxar multicasttrafik.
Home Assistant-användare som jämför brygg- och macvlan-konfigurationer rapporterar att vanlig brygga kan komplicera mDNS, medan alternativa nätverksdesigner återställer direkt synlighet på LAN. Den användbara lärdomen från upptäcktsbeteendet i bryggnätverk är att testa det protokoll du behöver, i stället för att anta att publicerade TCP-portar även vidarebefordrar multicastupptäckt.
Välj bryggläge när de nödvändiga enheterna kan nås via explicit IP-adress, värdnamn, broker eller en mappad hårdvarusökväg och du vill ha tydligare gränser mellan tjänster. Om en integration endast misslyckas för att den inte kan upptäcka en LAN-enhet bör du först försöka konfigurera slutpunkten explicit. Byt till värdläge eller ett mer avancerat nätverk först när integrationen faktiskt kräver detta upptäcktsbeteende.
Validera valet med samma integrationsmatris efter omstart
Skapa ett test med fem rader: åtkomst till den lokala instrumentpanelen, en mDNS- eller SSDP-enhet, en integration med explicit IP-adress, en broker- eller radiogateway samt den vanliga sökvägen via omvänd proxy eller VPN. Testa efter att containern har återskapats och efter omstart av värden, inte bara direkt efter att du ändrat Compose, eftersom cachad upptäckt kan dölja ett nätverksläge som senare kommer att misslyckas.
ZimaSpaces felsökning av åtkomst till Docker-subnät visar samma gräns: att en applikation är tillgänglig och att containernätverket är åtkomligt är två olika kontroller, även när båda finns på samma fysiska server.
Behåll värdläge när det konsekvent bevarar den upptäckt som krävs och du accepterar det gemensamma namnområdet. Behåll bryggläge när alla nödvändiga integrationer fortsätter att vara åtkomliga och den explicita gränsen minskar oklarheter i driften. Om inget av lägena fungerar bör du sluta växla mellan dem och i stället granska VLAN-routing, multicastvidarebefordran, brandväggsregler eller själva integrationens transport; nätverksläget är bara ett lager i sökvä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.
