network_mode: host in Docker Compose erklärt

Sie packen Home Assistant oder Pi-hole in eine docker-compose.yml, fahren den Stack hoch, und die Geräte-Erkennung funktioniert einfach nicht. Keine neuen Geräte, keine automatisch erkannten Integrationen, nichts. Der Container läuft einwandfrei — docker compose ps zeigt ihn als gesund an — er sieht nur den Rest Ihres LANs nicht. Der Fix, der in Forenbeiträgen immer wieder auftaucht, ist network_mode: host, und das klingt erstmal so, als würde es genau die Isolation zerstören, die Sie von Docker eigentlich wollten.

Warum das Standard-Bridge-Netzwerk Discovery blockiert

Compose setzt standardmäßig jeden Dienst auf ein Bridge-Netzwerk und versteckt ihn per NAT hinter der IP des Hosts — jeder Container bekommt seine eigene private Adresse, und Compose mappt nur die Ports, die Sie explizit deklarieren. Das ist normale, bewusste Isolation, und für die meisten Dienste völlig ausreichend.

Problematisch wird es bei allem, was auf Multicast angewiesen ist, um andere Geräte zu finden — mDNS/Zeroconf (die Namensauflösung und Auto-Discovery für .local-Hostnamen) und SSDP/UPnP (genutzt von DLNA-Medienservern, manchen Smart-Home-Geräten und Chromecast-ähnlichem Discovery) senden beide auf einer Multicast-Adresse, die eine NAT-Grenze in der Regel nicht überquert — anders als gewöhnlicher Unicast-Verkehr. Der Container kann weiterhin problemlos ausgehende Verbindungen aufbauen; er sieht nur nie den Multicast-Verkehr in Ihrem echten LAN — und wird selbst auch nicht gesehen.

Was network_mode: host tatsächlich tut

Laut Dockers eigener Dokumentation zum Host-Network-Driver ist bei einem Container mit dem host-Treiber "der Netzwerk-Stack dieses Containers nicht vom Docker-Host isoliert — der Container teilt sich den Netzwerk-Namespace des Hosts, und der Container bekommt keine eigene IP-Adresse zugewiesen." Es gibt keine Bridge, kein NAT, keine eigene Container-IP: Der Prozess im Container bindet sich direkt an das echte Netzwerk-Interface des Hosts, exakt so, als liefe er außerhalb von Docker.

Genau diese eine Änderung ist auch der Grund, warum Multicast-basiertes Discovery wieder funktioniert — der Container ist jetzt tatsächlich im Netzwerksegment Ihres LANs präsent, statt hinter einer übersetzten Adresse zu sitzen.

Dieselbe Docker-Dokumentation ist auch konkret dazu, wo dieser Treiber läuft: Unterstützt werden "Docker Engine unter Linux" und seit "Docker Desktop Version 4.34" auch Docker Desktop — allerdings erst, nachdem Sie es manuell aktivieren (Settings → Resources → Network → "Enable host networking"), und nur für Linux-Container; Windows-Container sind komplett ausgeschlossen. Es funktioniert außerdem nicht zusammen mit Docker Desktops Enhanced-Container-Isolation-Funktion, da die Isolation eines Containers vom Host und die Übergabe des eigenen Host-Netzwerks direkt gegensätzliche Ziele sind.

Bridge vs. Host vs. Macvlan: Die Entscheidung

macvlan bietet den Discovery-Vorteil von host, hält den Traffic des Containers aber auf einer eigenen Adresse statt auf der des Hosts — braucht dafür aber ein Netzwerk-Interface, das der Host in einen promiscuous-nahen Modus versetzen kann, und kann meist ohne zusätzliche Konfiguration nicht mit dem Host selbst sprechen — mehr Aufwand, als die meisten Homelab-Stacks brauchen. Für den häufigen Fall — ein oder zwei Dienste, die LAN-Discovery brauchen, auf Hardware, die Sie vollständig kontrollieren — ist host die einfachere Wahl.

Wann sich Host-Networking lohnt

Mein eigenes Homelab betreibt Home Assistant und Pi-hole per Compose auf einer Proxmox-VM. Der Geräte-Erkennungs-Flow von Home Assistant (neue Zigbee-/Zeroconf-Geräte, die automatisch auftauchen) hat auf dem Standard-Bridge-Netzwerk nie etwas gefunden — erst das Umstellen dieses einen Dienstes auf network_mode: host hat die automatische Erkennung überhaupt zum Laufen gebracht. Pi-hole hat einen zweiten, davon unabhängigen Grund: Auf Bridge-Networking zeigt das Query-Log von Pi-hole für jeden Client dieselbe NAT'ete Container-IP statt der echten LAN-Adresse jedes Geräts — das untergräbt den ganzen Sinn von Logging pro Client. Host-Networking behebt beides — Pi-hole sieht echte Client-IPs, und sein eigener DNS-Dienst ist direkt unter der IP des Hosts erreichbar, ohne Umweg über Port-Mapping.

Wann Sie bei Bridge bleiben sollten

Der Großteil eines typischen Compose-Stacks hat überhaupt keine Discovery-Abhängigkeit — ein Reverse-Proxy, eine Datenbank, eine Backend-API, eine statische Website. Keiner davon braucht Multicast, keiner profitiert von Host-Networking, und alle sind auf der Standard-Bridge mit expliziten ports:-Mappings sicherer und portabler, wie in unserem Docker-Compose-Networking-Guide beschrieben. Isolation ist dort keine Einschränkung, die Sie umgehen — sie ist das Feature, das seinen Job macht.

Einrichtung

services:
  homeassistant:
    image: ghcr.io/home-assistant/home-assistant:stable
    network_mode: host
    volumes:
      - ./homeassistant-config:/config
    restart: unless-stopped

Kein ports:-Block, und keiner wird gebraucht — die Dienste des Containers binden sich direkt an die echten Interfaces des Hosts. Laut der Docker-Compose-Spezifikation sind network_mode: host und ports: ausdrücklich inkompatibel: "Port mapping must not be used with network_mode: host. Doing so causes a runtime error, because network_mode: host already exposes container ports directly to the host network." Lassen Sie nach der Umstellung eines Dienstes auf Host-Modus einen alten ports:-Block stehen, verweigert Compose den Start — stillschweigend ignorieren tut es ihn nicht.

FAQ

Fazit

network_mode: host tauscht Dockers Netzwerk-Isolation gegen direkten Zugriff auf das echte Netzwerk-Interface des Hosts ein — der Fix für Multicast-abhängiges Discovery (mDNS/Zeroconf, SSDP/UPnP), das das Standard-Bridge-Netzwerk nicht weiterleiten kann, und für Dienste wie Pi-hole, die echte Client-IPs statt einer NAT'eten Container-Adresse sehen müssen. Greifen Sie dazu bei der Handvoll Dienste, die es konkret brauchen — Home Assistant, Pi-hole, DLNA-ähnliche Medienserver — und lassen Sie alles andere, also den Großteil eines typischen Stacks, auf der Standard-Bridge, wie in unserem Docker-Compose-Networking-Guide beschrieben. Wenn Sie den Rest des Stacks drumherum noch aufbauen, deckt unser Docker-Compose-Self-Hosting-Guide die Grundlagen ab, die dieser Artikel voraussetzt, und unser Guide zur Heimnetzwerk-Sicherheit die breiteren Trade-offs, Dienste direkt im LAN zu exponieren.