Docker-Netzwerke verstehen: bridge, internes DNS & das proxy-Netz

networks: [proxy] – dieser Halbsatz taucht in fast jedem App-Rezept der Serverküche auf, meist unkommentiert. Höchste Zeit, ihn einmal zentral zu erklären. Danach verstehst du, wie Container sich finden, warum manche kein Internet brauchen und wie Traefik überhaupt an sie herankommt.

Was bauen wir?

Kein neuer Dienst, sondern das Netzwerk-Modell hinter jedem Docker-Stack. Am Ende weißt du, warum du eigene Netzwerke anlegen solltest statt das Standard-bridge, wie Container sich per Name statt IP erreichen (das interne DNS), was ein internal-Netz ohne Internetzugang bringt und warum das gemeinsame proxy-Netz der Trick ist, mit dem Traefik jede App erreicht. Alle Ausgaben stammen von einem echten Debian 13-Server mit Docker 29.

Voraussetzungen

• Ein Server mit installiertem Docker und Grundwissen zu Docker Compose
• Root- oder docker-Gruppen-Zugang (siehe Benutzer & Rechte)
• Kein zusätzliches Paket – alles bringt Docker mit

Schritt für Schritt

Schritt 1: Was schon da ist

Nach der Installation bringt Docker drei Netzwerke mit:

docker network ls

NETWORK ID     NAME      DRIVER    SCOPE
9d087537e327   bridge    bridge    local
b622109fef73   host      host      local
e12e562ad7f6   none      null      local

• bridge – das Standard-Netz. Container ohne explizite Netzangabe landen hier. Es funktioniert, hat aber einen entscheidenden Haken (Schritt 3).
• host – der Container teilt sich den Netzwerk-Stack des Hosts direkt (kein Isolations-Layer, keine Port-Zuordnung). Nur für Sonderfälle.
• none – gar kein Netzwerk. Für Container, die bewusst offline sein sollen.

Für eigene Stacks nutzt du keines davon direkt, sondern legst eigene Netzwerke an. Warum, zeigt Schritt 3.

Schritt 2: Ein eigenes Netzwerk anlegen

docker network create demo-net

Docker erstellt ein bridge-Netz und vergibt automatisch ein Subnetz:

docker network inspect demo-net --format 'name={{.Name}} driver={{.Driver}} subnet={{range .IPAM.Config}}{{.Subnet}}{{end}}'

name=demo-net driver=bridge subnet=172.20.0.0/16

Jeder Container in diesem Netz bekommt eine IP aus 172.20.0.0/16. Aber mit IPs willst du gar nicht arbeiten – sie ändern sich bei jedem Neustart. Der eigentliche Gewinn ist etwas anderes.

Schritt 3: Das interne DNS – Container per Name finden

Starte zwei Container in demo-net: einen Webserver und einen Client.

docker run -d --name web --network demo-net nginx:1.29-alpine
docker run -d --name client --network demo-net alpine:3.20 sleep 600

Jetzt der entscheidende Test – der Client erreicht den Webserver über seinen Namen:

docker exec client ping -c 2 web

PING web (172.20.0.2): 56 data bytes
64 bytes from 172.20.0.2: seq=0 ttl=64 time=0.171 ms
64 bytes from 172.20.0.2: seq=1 ttl=64 time=0.095 ms

Docker löst den Containernamen web automatisch auf die richtige IP auf. Das gilt auch für HTTP:

docker exec client wget -qO- http://web/

<title>Welcome to nginx!</title>

Genau deshalb steht in Compose-Dateien DB_HOST=db statt einer IP: db ist der Servicename, und Docker macht daraus die richtige Adresse. Der Vergleich mit dem Standard-bridge zeigt, warum du es meidest – dort gibt es keine Namensauflösung:

docker run -d --name legacy1 nginx:1.29-alpine
docker run --rm alpine:3.20 ping -c 1 legacy1

ping: bad address 'legacy1'

Schritt 4: Segmentieren – Datenbank ohne Internet

Nicht jeder Container braucht jeden anderen zu sehen. Eine Datenbank soll nur von ihrer App erreichbar sein und braucht selbst kein Internet. Dafür gibt es internal-Netze:

docker network create --internal demo-intern

internal: true kappt die Route nach draußen. Der Beweis:

docker run --rm --network demo-intern alpine:3.20 \
  sh -c "wget -qT4 -O- http://example.com >/dev/null 2>&1 && echo REACHED || echo BLOCKED"

BLOCKED

Das ist ein starkes Sicherheitsmuster: Selbst wenn ein Angreifer die Datenbank kompromittiert, kann sie keine Verbindung nach außen aufbauen (kein Nachladen von Schadcode, kein Datenabfluss). Ein typischer Stack nutzt deshalb zwei Netze: ein internal-Netz zwischen App und Datenbank, und das öffentliche proxy-Netz nur zwischen App und Traefik.

Schritt 5: Das proxy-Netz – wie Traefik jede App erreicht

Jetzt der meistkopierte Halbsatz des Katalogs. Traefik läuft in einem eigenen Container und muss mit jeder App reden, um deren Anfragen weiterzuleiten. Container reden aber nur miteinander, wenn sie im selben Netz sind. Die Lösung: ein gemeinsames, dauerhaftes Netz namens proxy.

docker network inspect proxy --format 'name={{.Name}} driver={{.Driver}} subnet={{range .IPAM.Config}}{{.Subnet}}{{end}} internal={{.Internal}}'

name=proxy driver=bridge subnet=172.19.0.0/16 internal=false

Traefik hängt dauerhaft in diesem Netz. Jede neue App tritt ihm bei – in Compose so:

services:
  meineapp:
    image: beispiel/app:1.0
    networks:
      - proxy        # damit Traefik die App erreicht
      - intern       # private Verbindung zur Datenbank
    labels:
      - "traefik.enable=true"
      # ... die Router-/Service-Labels

networks:
  proxy:
    external: true   # von Traefik angelegt, NICHT neu erstellen
  intern:
    internal: true

Zwei Dinge sind hier zentral: external: true sagt Docker „dieses Netz existiert schon, häng dich nur an“ – legst du es versehentlich neu an, landet die App in einem anderen proxy-Netz als Traefik und ist über die Domain nicht erreichbar (der Klassiker aus dem 502-Troubleshooting). Und über das zweite Netz intern erreicht die App ihre Datenbank, ohne dass diese je im öffentlichen Netz hängt.

Schritt 6: Ports veröffentlichen – nur wo nötig

In allen bisherigen Schritten reden Container untereinander, ohne einen einzigen Port zu veröffentlichen. Ein Port muss nur dann nach außen, wenn der Host oder das Internet direkt zugreifen soll:

docker run -d --name pub -p 8099:80 nginx:1.29-alpine
curl -s -o /dev/null -w "%{http_code}\n" http://127.0.0.1:8099/

200

-p 8099:80 bindet Host-Port 8099 auf Container-Port 80. In Compose ist das ports: ["8099:80"]. Der wichtige Unterschied zu expose: expose macht einen Port nur für andere Container sichtbar (netzintern), ports öffnet ihn zum Host.

Wenn es nicht funktioniert

Wartung & Backups

• Netzwerke brauchen kein Backup – sie werden aus der Compose-Datei jederzeit neu erzeugt. Wichtig ist also, dass deine compose.yaml und die networks:-Deklarationen im Backup liegen, nicht der Netz-Zustand selbst.
• Verwaiste Netze aufräumen. Nach vielen Tests sammeln sich ungenutzte Netze an. docker network ls zeigt sie, docker network prune entfernt alle ohne angehängte Container. Das dauerhafte proxy-Netz bleibt dabei erhalten, solange Traefik läuft.
• Das proxy-Netz ist Infrastruktur. Behandle es wie Traefik selbst: einmal anlegen, dann in Ruhe lassen. Es aus Versehen zu löschen (network prune bei gestopptem Traefik) zwingt dich, alle Apps neu zu verbinden. Mehr zum sauberen Aufräumen steht in Docker-Stack aktuell halten.