Docker-Netzwerkmodi erklärt: bridge/host/none/container – Performance-Vergleich und Szenario-Auswahl

Im Terminal blinkt die grüne Meldung „Container started“, der Service läuft – und trotzdem timeout bei curl. docker logs dreimal durchgeblättert, keine Fehler. Port-Mapping mit -p 8080:80 ist konfiguriert, Routing stimmt, Firewall aus. Wo liegt das Problem?

Später stellte sich heraus: Der Netzwerkmodus war falsch gewählt. Ich dachte, docker run -p reicht – und wusste nicht, dass Docker vier Netzwerkmodi hat: bridge, host, none und container.

Wenn Ihnen das bekannt vorkommt – Container läuft, aber nicht erreichbar – oder Sie bei der Docker-Netzwerkkonfiguration unsicher sind: Dieser Artikel erklärt die vier Modi in klarer Sprache – Unterschiede, Funktionsweise und Einsatzszenarien. Keine komplexe Linux-Netzwerk-Namespace-Theorie, nur das, was Sie in der Praxis wirklich brauchen.

Zuerst das Fundament: die docker0-Bridge

Was ist docker0? Das „Gateway“ Ihrer Container

Nach der Docker-Installation erscheint automatisch eine virtuelle Netzwerkkarte namens docker0. Stellen Sie sich das als Gateway vor – alle Container müssen über sie ins Netzwerk.

Probieren Sie im Terminal:

ip addr show docker0

Die Ausgabe sieht etwa so aus:

docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0

Sehen Sie 172.17.0.1? Das ist die IP-Adresse von docker0. Docker vergibt jedem neuen Container eine IP aus dem Bereich 172.17.0.0/16 – zum Beispiel 172.17.0.2, 172.17.0.3.

Die Docker-Netzwerkliste:

docker network ls

NETWORK ID     NAME      DRIVER    SCOPE
7f8a2b3c9d4e   bridge    bridge    local

Das Standard-bridge-Netzwerk nutzt im Hintergrund die docker0-Bridge.

veth pair: Das „Walkie-Talkie“ der Container-Vernetzung

docker0 allein reicht nicht. Container sitzen in ihrem eigenen „Raum“ (Netzwerk-Namespace) – wie kommunizieren sie mit docker0?

Die Antwort: veth pair. Wie ein Walkie-Talkie-Paar: Eine Seite im Container heißt eth0, die andere auf dem Host vethXXX (z. B. veth9a7b4c).

Starten Sie einen Test-Container:

docker run -d --name test-nginx nginx

Auf dem Host die Netzwerkkarten prüfen:

ip addr | grep veth

Es erscheint ein neues veth-Gerät. Im Container:

docker exec test-nginx ip addr

Dort gibt es eth0 mit der IP 172.17.0.2. Dieses eth0 und das vethXXX auf dem Host bilden ein Paar – Pakete gehen von eth0 über vethXXX zur docker0-Bridge, dann über NAT und die Host-Netzwerkkarte (z. B. eth0 oder ens33) ins Internet.

Die gesamte Kette:

Container (172.17.0.2)
  ↓ eth0
  ↓ (veth pair)
  ↓ vethXXX
  ↓
docker0-Bridge (172.17.0.1)
  ↓ NAT-Weiterleitung
  ↓
Host-Netzwerkkarte (z. B. 192.168.1.100)
  ↓
Internet

Klingt kompliziert, läuft aber sehr schnell. Ein Ping auf die Container-IP zeigt Latenzen im Sub-Millisekunden-Bereich.

Ehrlich gesagt war mir veth pair anfangs auch unverständlich. Später wurde klar: Es ist ein virtuelles Kabel – ein Ende im Container, eines an docker0. Mehr nicht.

Bridge-Modus – Docker-Standard

Warum ist bridge der Standard?

Ohne Angabe eines Netzwerkmodus wählt Docker automatisch bridge. Der Grund: ein guter Kompromiss aus Isolation und Benutzerfreundlichkeit.

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

Preise ansehen →Anzeige

Im bridge-Modus hat jeder Container eine eigene IP, Port-Konflikte entfallen, und mit -p lassen sich Dienste einfach auf dem Host exponieren. Für die meisten Szenarien reicht das.

Beispiel – zwei Nginx-Container:

docker run -d -p 8080:80 --name web1 nginx
docker run -d -p 8081:80 --name web2 nginx

Beide lauschen intern auf Port 80, kollidieren aber nicht. Der Host erreicht sie über 8080 und 8081 – Docker macht NAT-Port-Weiterleitung.

Mit docker inspect web1 die Netzwerkkonfiguration ansehen:

"Networks": {
    "bridge": {
        "IPAddress": "172.17.0.2",
        "Gateway": "172.17.0.1"
    }
}

Der Container erhält die private IP 172.17.0.2, Gateway ist docker0 mit 172.17.0.1.

Standard-bridge vs. benutzerdefiniertes bridge: ein wichtiger Unterschied

Hier lauert eine Falle. Im Standard-bridge-Netzwerk (docker0) kommunizieren Container nur per IP – keine Namensauflösung.

Test:

docker run -d --name db mysql
docker run -it --name app alpine ping db

Schlägt fehl. Sie müssen ping 172.17.0.2 mit expliziter IP nutzen.

Mit benutzerdefiniertem bridge-Netzwerk:

docker network create mynet
docker run -d --name db --network mynet mysql
docker run -it --name app --network mynet alpine ping db

Jetzt funktioniert es. Benutzerdefinierte bridge-Netzwerke haben eingebautes DNS – Containernamen funktionieren wie Hostnamen.

Deshalb empfiehlt sich in Produktion ein benutzerdefiniertes Netzwerk statt docker0 – Service Discovery wird deutlich einfacher, ohne fest codierte IPs.

Das Geheimnis hinter -p: NAT-Weiterleitung

Mit -p 8080:80 fügt Docker eine NAT-Regel in iptables ein:

iptables -t nat -L -n | grep 8080

Ausgabe etwa:

DNAT  tcp  --  0.0.0.0/0  0.0.0.0/0  tcp dpt:8080 to:172.17.0.2:80

Bedeutung: Alles, was an Port 8080 des Hosts geht, wird an 172.17.0.2:80 des Containers weitergeleitet.

So erreicht ein externer Zugriff auf http://Host-IP:8080 den Dienst im Container – Docker übernimmt die Adressumsetzung.

Einsatzszenarien für bridge

bridge eignet sich für:

• Microservices: Mehrere Container, Isolation und gegenseitige Kommunikation (benutzerdefiniertes bridge-Netzwerk)
• Entwicklungsumgebung: Schnell Services starten und testen – Standard-bridge reicht
• Web-Apps mit Port-Mapping: Blog, API-Services usw.

Performance: bridge hat NAT- und veth-Overhead, aber für die meisten Anwendungen vernachlässigbar. Echte Engpässe sind selten – machen Sie sich nicht unnötig Sorgen.

Host-Modus – Performance zuerst

Was ist der Host-Modus? Direkt auf dem Host-Netzwerk

Am einfachsten: Der Container verzichtet auf ein eigenes Netzwerk und nutzt den Netzwerk-Stack des Hosts.

docker run -d --net=host --name web nginx

Keine eigene Container-IP, kein eth0 – die Netzwerkkonfiguration ist identisch mit ip addr auf dem Host.

Entscheidend: Kein -p nötig. Lauscht der Dienst im Container auf Port 80, reicht Host-IP:80 von außen.

Wo liegt der Performance-Vorteil?

Host-Modus umgeht docker0, veth pair und NAT. Pakete gehen direkt über die Host-Netzwerkkarte – fast wie ein nativer Prozess.

In Benchmarks ist host unter hoher Last etwa 5–10 % schneller als bridge. Für latenzkritische Anwendungen (Hochfrequenzhandel, Echtzeit-Spielserver) kann das relevant sein.

Ein Praxisbeispiel: Nginx als Reverse Proxy mit Zehntausenden Requests pro Sekunde. Nach Umstellung auf host sank die P99-Latenz von 12 ms auf 9 ms – nur 3 ms, aber für dieses Projekt war das viel wert.

Fallstricke und Kosten des Host-Modus

Mehr Performance, aber auch mehr Risiken:

Fallstrick 1: Port-Konflikte

Mehrere Container auf demselben Port schlagen fehl:

docker run -d --net=host nginx  # lauscht auf 80
docker run -d --net=host nginx  # erneut 80 – Fehler: Address already in use

Wie zwei native Nginx-Instanzen auf dem Host. Mehrere Instanzen? Port im Container ändern oder host-Modus vermeiden.

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

Jetzt starten →Anzeige

Fallstrick 2: Dienst muss auf 0.0.0.0 lauschen

Lauscht der Dienst nur auf 127.0.0.1, ist er von außen nicht erreichbar. Es muss 0.0.0.0 sein.

Beispiel: Node.js mit app.listen(3000, 'localhost') im host-Modus – extern kein Zugriff. Erst app.listen(3000, '0.0.0.0') löste das Problem.

Fallstrick 3: Keine Netzwerk-Isolation

Der Container erreicht alle Netzwerkressourcen des Hosts – erhöhtes Sicherheitsrisiko. Bei untrusted Code ist host-Modus riskant.

Wann Host-Modus nutzen?

Ehrlich: Nur bei echtem Performance-Engpass. Für die meisten Anwendungen ist der bridge-Overhead irrelevant.

Host-Modus passt zu:

• Monitoring: Prometheus, Grafana, ELK – direkter Zugriff auf Host-Ressourcen
• High-Performance-Proxies: Nginx, HAProxy mit minimaler Latenz
• Datenbanken: MySQL, Redis – performance-sensitiv (Sicherheit beachten)

Bei einigen Tausend Requests pro Sekunde lohnt sich host selten – bridge reicht.

None- und Container-Modus – Spezialfälle

None-Modus: Vollständig isolierte Sandbox

Wörtlich: Der Container hat kein Netzwerk.

docker run -it --net=none alpine sh

Im Container zeigt ip addr nur loopback (lo) – kein Internet, kein Zugriff von anderen Containern.

Wann None-Modus?

In der Praxis fast nie genutzt. Sehr enge Anwendungsfälle:

• Sicherheitstests: Untrusted Code ohne Netzwerk-Zugang
• Offline-Datenverarbeitung: Nur lokale Berechnung, kein Netzwerk
• Manuelle Netzwerkkonfiguration: Selten – z. B. mit pipework veth manuell einrichten

Ohne Security-Forschung oder spezielle Anforderungen brauchen Sie none selten.

Container-Modus: Gemeinsames Netzwerk

Ein Container nutzt den Netzwerk-Namespace eines anderen:

# Ersten Container starten
docker run -d --name web nginx

# Zweiten Container teilt das Netzwerk von web
docker run -it --net=container:web alpine sh

Beide teilen IP, Ports und Netzwerkkonfiguration. Im zweiten Container erreicht localhost:80 den Nginx.

Typische Anwendung: Kubernetes Pods

Kubernetes-Pods nutzen container-Modus. Mehrere Container in einem Pod teilen das Netzwerk eines „pause“-Containers.

Beispiel: App-Container und Log-Sidecar kommunizieren über localhost, ohne externe Ports.

Bei reinem Docker (ohne Kubernetes) ist container-Modus seltener – bridge mit benutzerdefiniertem Netzwerk ist flexibler.

Einordnung beider Modi

none und container sind eher Low-Level-Fähigkeiten als Alltagslösungen. Flexibilität für Spezialfälle – in 80 % der Fälle brauchen Sie sie nicht.

Merken Sie sich:

• None-Modus: Vollständige Netzwerk-Isolation (selten)
• Container-Modus: Häufig in Kubernetes, selten bei standalone Docker

Praxis-Entscheidung: Den richtigen Netzwerkmodus wählen

Entscheidungsfluss

Welcher Modus für Ihr Projekt?

Netzwerk-Isolation erforderlich?
│
├─ Nein → Performance-Engpass?
│         │
│         ├─ Ja → Host-Modus (Sicherheitsrisiken beachten)
│         └─ Nein → Bridge-Modus (sicherer)
│
└─ Ja → Kommunikation per Containernamen nötig?
        │
        ├─ Ja → Benutzerdefiniertes Bridge-Netzwerk
        └─ Nein → Standard-Bridge-Netzwerk

Spezialfälle:

• Kein Netzwerk nötig → None-Modus
• Container in Kubernetes-Pods → Container-Modus

Szenario-Übersicht

Drei häufige Missverständnisse

Missverständnis 1: „Host ist immer am besten“

Falsch. Host opfert Isolation und Flexibilität – der Gewinn ist oft vernachlässigbar.

Manche betreiben alles im host-Modus – Port-Konflikte und Sicherheitsprobleme häufen sich. Performance steigt etwas, Wartungsaufwand verzehnfacht sich.

Fakt: Für 80 % der Anwendungen reicht bridge. Lassen Sie sich nicht von „bessere Performance“ blenden.

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

15 % Rabatt sichern →Anzeige

Missverständnis 2: „Standard-bridge reicht überall“

In Produktion nicht empfohlen. Keine Namensauflösung – Services kommunizieren per fest codierter IP oder Umgebungsvariablen. Fragil.

Benutzerdefiniertes Netzwerk ist schnell eingerichtet:

docker network create mynet
docker-compose.yml: network angeben

Fakt: Zwei Minuten Konfiguration sparen Stunden Debugging.

Missverständnis 3: „Netzwerkprobleme = falscher Modus“

Nicht immer. Oft sind Firewall, iptables oder DNS schuld.

Systematisches Vorgehen:

1. Im Container Gateway (docker0-IP) pingen
2. Externe Host-IP pingen
3. iptables auf DROP-Regeln prüfen
4. Docker-Daemon-Konfiguration prüfen (/etc/docker/daemon.json)

Fakt: Der Modus ist nur der erste Schritt – Netzwerk-Troubleshooting braucht Systematik.

Fortgeschrittene Tipps

Tipp 1: Container in mehreren Netzwerken

Manchmal braucht ein Container zwei Netzwerke (Frontend und Backend):

docker network create frontend
docker network create backend

docker run -d --name web --network frontend nginx
docker network connect backend web

web ist jetzt in frontend und backend.

Tipp 2: Feste IP-Vergabe

Bei benutzerdefiniertem Netzwerk Subnetz und Gateway festlegen:

docker network create \
  --driver bridge \
  --subnet 192.168.10.0/24 \
  --gateway 192.168.10.1 \
  mynet

docker run -d --network mynet --ip 192.168.10.100 nginx

Nützlich bei Firewall-Whitelists mit festen IPs.

Tipp 3: Tools für Netzwerk-Troubleshooting

# Netzwerk-Tools installieren
docker exec -it <container> apk add curl netcat-openbsd

# Konnektivität testen
docker exec <container> nc -zv <host> <port>

# Routing-Tabelle
docker exec <container> ip route

# Paket-Analyse (Host-Rechte erforderlich)
docker exec <container> tcpdump -i eth0

Fazit

Kurz die vier Netzwerkmodi:

• Bridge-Modus: Standard, für die meisten Szenarien – in Produktion benutzerdefiniertes bridge-Netzwerk
• Host-Modus: Performance zuerst, Isolation eingeschränkt – nur bei echtem Engpass
• None-Modus: Kein Netzwerk, selten genutzt
• Container-Modus: Geteiltes Netzwerk, vor allem in Kubernetes

Merken Sie sich: Es gibt keinen besten Modus – nur den passenden.

Wenn Sie Docker gerade kennenlernen, starten Sie mit Standard-bridge. Bei Problemen anpassen: Service Discovery schwierig → benutzerdefiniertes bridge; Performance knapp → host. Nicht von Anfang an den „optimalen“ Modus suchen.

Probieren Sie es aus: Benutzerdefiniertes Netzwerk anlegen, mehrere Container starten, testen ob sie sich per Namen erreichen. Einmal selbst durchspielen hilft mehr als zehn Artikel.

Wenn Sie in Projekten auf Docker-Netzwerkprobleme stoßen, teilen Sie gern Ihre Erfahrungen. Das Thema ist tief – mit diesen Grundlagen lösen Sie aber 80 % der Fälle selbst.