Docker-Netzwerkmodi in der Praxis: Entscheidungsleitfaden für bridge, host und overlay

Aus einem echten Ausfall

Um zwei Uhr nachts lief die API in Produktion plötzlich in Timeouts.

Der Container lief (docker ps: running), die Firewall war offen, Port-Mapping saß, Logs waren sauber. Nach einer halben Stunde Fehlersuche: falscher Docker-Netzwerkmodus – Standard-bridge, aber die App musste hostübergreifend eine Datenbank auf einem anderen Knoten erreichen. Bridge kommuniziert nur auf einem Host.

Viele kennen bridge, host und overlay – aber nicht, wann welcher Modus passt. Den Fehler habe ich am Anfang selbst gemacht.

Nach diesem Artikel haben Sie Entscheidungsfluss und Performance-Tabelle für alle drei Modi. Bei Netzwerkproblemen zuerst fragen: ein Host oder mehrere? – dann sparen Sie sich unnötigen Aufwand.

Bridge: Standardwahl für Einzelhost

Bridge ist der Docker-Standard.

Ohne --network landet jeder docker run hier. Docker legt auf dem Host die virtuelle Bridge docker0 an; Container bekommen eigene IPs (oft 172.17.x.x) und hängen per veth pair daran.

Kurz: Container wie kleine VMs mit privater IP; nach außen meist per NAT (Port-Mapping).

Einsatzszenarien

Mehrere Container auf einem Host: Bridge zuerst.

Dev, Test und viele Produktionsfälle ohne Host-übergreifende Kommunikation – einfach, sicher, wenig Konfiguration.

Konfigurationsbeispiel

Standard ist Bridge – nichts extra setzen:

# Standard bridge, automatische IP, -p für Port-Mapping
docker run -d -p 8080:80 nginx

Nachteil der Standard-Bridge: Container sprechen nur per IP, nicht per Name. Zwei Container verbinden? IP per docker inspect – nach Neustart kann sie wechseln.

# Zwei Container starten
docker run -d --name web nginx
docker run -d --name db redis

# IP von web
docker inspect web | grep IPAddress
# Ausgabe: 172.17.0.2

# Von db aus ping auf IP (nicht auf Namen)
docker exec db ping 172.17.0.2

Empfehlung: benutzerdefiniertes Bridge-Netzwerk

# Eigenes Netzwerk
docker network create --subnet=192.168.100.0/24 my-net

# Container im Netz
docker run -d --network my-net --name web nginx
docker run -d --network my-net --name db redis

# web kann db per Namen erreichen (DNS)
docker exec web ping db

Containername funktioniert wie Hostname – ohne manuelles DNS.

Vultr - Hochleistungs-NVMe-Cloud-Server mit 32 Standorten weltweit, Docker per Klick

Preise ansehen →Anzeige

Host: beste Performance, schwächste Isolation

Im Host-Modus nutzt der Container den Netzwerkstack des Hosts.

Keine eigene IP, kein NAT, kein veth – die Schnittstellen im Container sind die des Hosts. Performance nahe nativ.

Der Preis: kaum Netzwerk-Isolation.

Einsatzszenarien

Latenz- oder Durchsatzkritisch: Gameserver, WebSocket/Streaming, HFT – jede Mikrosekunde zählt.

Auch fürs Debugging: tcpdump im Container sieht Host-Traffic direkt.

Konfigurationsbeispiel

Ohne -p:

# Host-Modus, nginx lauscht auf Host-Port 80
docker run -d --network host nginx

Aufruf von http://<host>:80 trifft nginx im Container.

Risiken

Portkonflikte: Läuft auf dem Host schon ein Dienst auf Port 80, scheitert ein zweiter Host-Container auf 80:

docker: Error response from daemon: driver failed programming external connectivity on endpoint xxx: Bind for 0.0.0.0:80 failed: port is already allocated.

Prüfen:

netstat -tuln | grep :80
# oder
ss -tuln | grep :80
lsof -i :80

Konflikt beenden oder im Container den Listen-Port der App ändern (Host erlaubt kein -p).

Sicherheit: Der Container sieht alle Host-Schnittstellen (LAN, WAN, VPN). Bei Kompromittierung voller Netzwerkzugriff auf dem Host – in Produktion nur mit Härtung.

Host ist selten nötig; bei echten Performance-Engpässen eine Option – wenn Sie die Isolation akzeptieren.

Overlay: hostübergreifend richtig

Bridge: ein Host. Host: schnell, aber nicht hostübergreifend. Mehrere Server? → Overlay.

Overlay nutzt VXLAN: Container auf verschiedenen Hosts wirken wie ein gemeinsames LAN.

Prinzip

VXLAN kapselt Container-Traffic, tunnel über den physischen Pfad, entkapselt am Zielhost. VTEP (VXLAN Tunnel Endpoint) übernimmt das; in Swarm verwaltet Docker das.

Analogie: Paket in großen Karton, Logistik zwischen Städten, Auspacken beim Empfänger – VXLAN ist der Karton, VTEP packt aus/ein.

Voraussetzung: Swarm oder externer KV-Store (Consul, etcd). Einzelner Docker-Knoten reicht nicht – Koordination von IPs, VTEP und Routing.

Einsatzszenarien

In Docker Swarm ist Overlay der übliche Weg für hostübergreifende Dienste (Web auf Knoten A, DB auf B) – Kommunikation per Containername.

In Kubernetes ähnliche Idee über CNI – anders konfiguriert, aber das Overlay-Konzept hilft beim Verständnis.

Railway - Moderne Deployment-Plattform, ohne DevOps-Aufwand, in Minuten live

Jetzt starten →Anzeige

Konfiguration (Ablauf)

# 1. Swarm auf erstem Host
docker swarm init --advertise-addr 192.168.1.10
# Join-Befehl mit Token ausgeben

# 2. Weitere Hosts
docker swarm join --token SWMTKN-xxx 192.168.1.10:2377

# 3. Overlay-Netzwerk
docker network create --driver overlay --subnet=10.0.1.0/24 my-overlay

# 4. Container auf verschiedenen Knoten, gleiches Overlay
docker run -d --network my-overlay --name web nginx   # Knoten A
docker run -d --network my-overlay --name db redis    # Knoten B

# 5. Test – web ping db, hostübergreifend
docker exec web ping db

Häufiger Fehler: Overlay ohne docker swarm init → „This node is not a swarm manager“.

--subnet=10.0.1.0/24 (/24, 256 IPs) vermeidet Kollisionen; große Cluster ggf. /16 – IP-Planung vorher.

Performance: Zahlen

Vergleich aus Lasttests (72 Stunden, Produktionsbericht):

Erkenntnisse

Host vs. Bridge: 128 μs → 32 μs (ca. 14 % schneller), Durchsatz Host nahe nativ, Bridge ~80 %. Bei tausenden Requests pro Sekunde spürbar.

Bridge / NAT: CPU von ~0,9 auf ~1,8 Kerne – NAT pro externem Request.

Overlay / VXLAN: höhere Latenz und CPU – für Verteilung, nicht für maximalen Einzelhost-Durchsatz.

Praxis

HFT: 32 μs vs. 128 μs kann den Unterschied machen. Normale Web-Apps: RTT in Millisekunden – Mikrosekunden oft irrelevant.

Performancekritisch → Host. Sicherheit → Bridge. Hostübergreifend → Overlay mit Overhead.

Selbst messen

Latenz/Durchsatz: ping, iperf3

docker exec container-a ping container-b
docker exec container-a iperf3 -c container-b

CPU: docker stats --no-stream

Traffic: tcpdump (Host-Modus auf eth0; Bridge auf docker0)

Vor Go-Live Lasttest mit Ihrem gewählten Modus.

Entscheidungsfluss

Drei Schritte

1. Hostübergreifende Kommunikation nötig?

Web auf A, DB auf B → ja.

• Ja → Schritt 2
• Nein → Schritt 3

2. Swarm im Einsatz?

Hostübergreifend: Swarm + Overlay oder Host + manuelles Routing (aufwendig).

• Ja → Overlay (Swarm verwaltet)
• Nein → Macvlan oder Host + Routing (Spezialfälle)

3. Performance sehr kritisch?

Alibaba Cloud - Top-Wahl für Entwickler, exklusiv 15 % Rabatt auf Lighthouse-Server

15 % Rabatt sichern →Anzeige

HFT, Echtzeit, Gaming?

• Ja → Host (Sicherheit prüfen)
• Nein → Bridge (sicherer Default)

Szenario-Tabelle

Tipp

Nicht sofort „optimalen“ Modus suchen – Bridge reicht meist. Anpassen bei:

• Service Discovery mühsam → custom Bridge
• Performance-Engpass → Host + Sicherheit
• Mehrere Hosts → Overlay

Früh Host ohne Grund führt oft zu Portkonflikten und Lücken – Bridge deckt ~90 % ab.

Best Practices in Produktion

Bridge: custom + DNS

Standard-Bridge: nur IP. In Produktion:

docker network create --subnet=192.168.100.0/24 --name my-app-net
docker run -d --network my-app-net --name web-server nginx
docker run -d --network my-app-net --name redis-cache redis
docker exec web-server ping redis-cache

Subnetz bewusst wählen (z. B. 192.168.100.0/24), nicht blind 172.17.x.x – Kollision mit Firmen-LAN vermeiden.

Host: härten

docker run -d --network host --cap-drop NET_RAW nginx

Traffic überwachen (Prometheus/Grafana o. ä.) – ungewöhnliche Outbound-Verbindungen alarmieren.

Host in Produktion selten – nur bei nachgewiesenem Engpass.

Overlay: Subnetz und Stabilität

docker network create --driver overlay --subnet=10.0.1.0/24 my-overlay

CPU wegen VXLAN beobachten; Swarm-Interconnect stabil und niedrige Latenz (idealerweise internes Netz).

Kurzfassung

1. Einzelhost → Bridge
Sicher, einfach. Service Discovery? Custom Bridge mit Namen.

2. Performance → Host
Beste Latenz, schwächste Isolation – Härtung nicht vergessen.

3. Hostübergreifend → Overlay
Mit Swarm; komplexer, aber nötig für verteilte Container.

Nächste Netzwerkfrage: ein Host oder mehrere?
Nicht mit Overlay auf einem Host starten – von Bridge aus nachjustieren.

Grundlagen zu bridge/host/none/container: Serie Teil 11 „Docker-Netzwerkmodi im Detail“ – dann passt dieser Artikel als Nächstes.

Referenzen

"Docker-Netzwerktreiber (bridge, host, overlay, macvlan …) – Konfiguration und Szenarien in der offiziellen Doku."

"Overlay mit VXLAN, Swarm oder KV-Store – Schritt-für-Schritt für hostübergreifende Container."

"Swarm-Netzwerke: Overlay anlegen, Service-Netzwerk, Best Practices hostübergreifend."

"72-Stunden-Lasttest: Latenz, Durchsatz und Paketverlust für Host, Bridge und Overlay."

"Docker Network Tests under Host/Bridge Mode – Latenzmethoden und Vergleichsdaten."