Host-Networking in Docker - wann es Sinn macht und wann nicht

Host-Networking in Docker - wann es Sinn macht und wann nicht

Mit --network host teilt sich ein Container den Netzwerk-Stack des Hosts direkt — kein Bridge-Netzwerk, keine Port-Übersetzung. Das hat spezifische Anwendungsfälle, aber auch klare Grenzen.

Was Host-Networking bewirkt

Normalerweise bekommt jeder Container eine eigene virtuelle Netzwerkschnittstelle und eine interne IP-Adresse. Ports werden über iptables-Regeln auf den Host-Port gemappt.

Mit --network host entfällt das komplett:

# Mit Bridge (Standard): Port 80 im Container → Port 8080 auf dem Host
docker run -p 8080:80 nginx

# Mit Host-Networking: nginx bindet direkt auf Port 80 des Hosts
docker run --network host nginx

Der Container ist aus Netzwerk-Sicht identisch mit einem Prozess, der direkt auf dem Host läuft. Kein Port-Mapping, kein NAT, keine Übersetzungsschicht.

Anwendungsfälle

Performance-kritische Anwendungen: Die NAT-Schicht von Bridge-Netzwerken hat Overhead. Bei sehr hohem Netzwerkdurchsatz kann Host-Networking 10–20% mehr Throughput liefern.

Monitoring und Netzwerk-Tools: Tools, die alle Netzwerkschnittstellen des Hosts sehen oder auf Raw Sockets zugreifen müssen:

docker run --network host --rm nicolaka/netshoot ss -tlnp

Broadcast und Multicast: Container, die auf Broadcast-Pakete im lokalen Netz angewiesen sind (mDNS, SSDP, bestimmte Embedded-Protokolle), funktionieren mit Bridge-Networking nicht korrekt.

Dienst bindet auf alle Interfaces: Wenn ein Dienst explizit auf 0.0.0.0 binden muss und Port-Mapping das stört.

Einschränkungen und Nachteile

Weniger Isolation: Der Container hat Zugriff auf alle Netzwerkschnittstellen des Hosts. Ein kompromittierter Container kann den gesamten Netzwerk-Stack des Hosts sehen.

Port-Konflikte: Wenn Port 80 bereits auf dem Host belegt ist, schlägt der Container-Start fehl — kein Mapping, das den Konflikt auflösen könnte.

Nur auf Linux: --network host hat auf Docker Desktop für Mac und Windows keine Wirkung. Container laufen dort in einer Linux-VM, der "Host" ist diese VM, nicht das Mac/Windows-System.

# Auf Linux: nginx läuft auf Port 80 des echten Hosts
docker run --network host nginx

# Auf Mac/Windows: läuft auf Port 80 der internen VM — für den Mac nicht direkt erreichbar
docker run --network host nginx  # kein Effekt wie erwartet

Empfehlung

Für den Großteil aller Anwendungsfälle: Custom Bridge Networks oder published Ports. Host-Networking nur dann, wenn eines der spezifischen Use Cases oben zutrifft und man die Sicherheitsabwägung bewusst trifft.

# Standard für die meisten Dienste
docker run -p 127.0.0.1:8080:80 nginx

# Host-Networking nur wenn nötig und bewusst
docker run --network host mein-netzwerk-tool