Docker-Reverse-Proxy: nginx-proxy vs. Traefik

Ein Docker-Reverse-Proxy ist ein einzelner Einstiegspunkt vor Ihren Containern, der jede eingehende Anfrage anhand des Hostnamens an den richtigen Dienst weiterleitet. Dieser Leitfaden vergleicht die beiden beliebtesten Optionen dafür, nginx-proxy und Traefik, jeweils mit einer funktionierenden docker-compose.yml, automatischem Let’s-Encrypt-TLS und einer klaren Entscheidungsmatrix.

Der Fokus ist bewusst eng gefasst: Es geht darum, einen Docker-Reverse-Proxy vor Ihren eigenen selbst gehosteten Containern zu betreiben. Nicht behandelt wird das Proxying ausgehenden Datenverkehrs, das ein völlig anderes Werkzeug erfordert und im Hinweis gegen Ende erläutert wird.

DataImpulse ist ein ethischer Proxy-Anbieter mit mehr als 90 Millionen privaten, mobilen und Rechenzentrums-IP-Adressen in 195 Ländern. Er nutzt ein Pay-as-you-go-Modell ab 1 Dollar pro GB mit nicht ablaufendem Datenvolumen und wird für Web Scraping, Anzeigenverifizierung, Preisüberwachung, Marktforschung und die Verwaltung mehrerer Konten eingesetzt.

Welchen Docker-Reverse-Proxy sollten Sie verwenden?

Verwenden Sie nginx-proxy für eine kleine, stabile Gruppe von Web-Containern, wenn Sie möglichst wenige bewegliche Teile wünschen. Nutzen Sie Traefik, wenn Container häufig kommen und gehen und das Routing über Labels gesteuert werden soll. Beide bieten einen öffentlichen Port, TLS-Terminierung und automatische Zertifikatserneuerung.

Wenn Ihre Dienste überwiegend statisch sind und Sie nur selten neue hinzufügen, ist nginx-proxy samt acme-companion der kürzeste Weg zu funktionierendem HTTPS. Wenn Sie häufig bereitstellen, viele kurzlebige Container betreiben oder ein Dashboard und Middleware wünschen, lohnt sich die steilere Lernkurve von Traefik. Caddy ist eine wissenswerte dritte Option und liegt zwischen beiden.

Was ist ein Docker-Reverse-Proxy und warum sollte man ihn verwenden?

Ein Docker-Reverse-Proxy ist ein Container, der den gesamten eingehenden Web-Datenverkehr auf den Ports 80 und 443 annimmt und jede Anfrage anhand des angeforderten Hostnamens oder Pfads an den richtigen Backend-Container weiterleitet. Ohne ihn müsste jeder Container mit öffentlichem Zugriff einen eigenen Host-Port veröffentlichen, und TLS-Zertifikate wären über die Dienste verteilt.

Um einen beliebigen Aufbau zu verstehen, hilft es, die Komponenten zu benennen. Nennen wir ihn den 5-stufigen Container-Reverse-Proxy-Stack: Einstiegspunkt, Router, Diensterkennung, TLS, Container. Der Einstiegspunkt ist der öffentliche Port. Der Router ordnet einen Hostnamen einer Regel zu. Über die Diensterkennung erfährt der Proxy, welche Container existieren. Bei TLS werden Zertifikate ausgestellt und beendet. Der Container ist Ihre eigentliche Anwendung. Jedes der folgenden Werkzeuge setzt dieselben fünf Stufen um; sie unterscheiden sich nur darin, wie viel davon automatisch geschieht.

• Routing: ein Hostname pro App, alles über einen einzigen Einstiegspunkt, sodass Sie nur die Ports 80 und 443 im Internet freigeben.
• TLS-Terminierung: Zertifikate werden zentral angefordert, gespeichert und erneuert, statt in jeder einzelnen Anwendung.
• Ein Einstiegspunkt: ein zentraler Kontrollpunkt für Protokollierung, Ratenlimits und Zugriffsregeln.

Wie haben wir die Reverse-Proxy-Optionen verglichen?

Jedes Werkzeug wurde anhand der fünf oben genannten Stufen sowie des Einrichtungsaufwands bewertet, ausschließlich auf Basis des auf der offiziellen Website des jeweiligen Projekts dokumentierten Verhaltens. Ziel war die Beurteilung des täglichen Betriebs, nicht ein Durchsatz-Benchmark.

Der Vergleich berücksichtigt vier praktische Faktoren: wie automatisch die Diensterkennung erfolgt, wie TLS bezogen und erneuert wird, wie gut die Konfiguration bei wachsenden Diensten lesbar bleibt und wie viel Vorwissen Erstnutzer benötigen. Die Funktionsbeschreibungen stammen aus der Traefik-Dokumentation (traefik.io, Stand: 2026-07-22), den Projektseiten von nginx-proxy und acme-companion (github.com/nginx-proxy, Stand: 2026-07-22) sowie der Caddy-Dokumentation (caddyserver.com, Stand: 2026-07-22). Hier werden keine Leistungszahlen erfunden, da sie stark von Ihrer Hardware und Arbeitslast abhängen.

Wie richtet man einen Docker-Reverse-Proxy-Server ein?

Definieren Sie den Proxy als einen Dienst in docker-compose.yml, weisen Sie ihm die beiden öffentlichen Ports zu und binden Sie den Docker-Socket schreibgeschützt ein, damit er Ihre anderen Container erkennen kann. Hier ist ein minimaler Traefik-Einstiegspunkt mit aktiviertem automatischem TLS.

services:
  traefik:
    image: traefik:v3.1
    command:
      - "--providers.docker=true"
      - "--providers.docker.exposedbydefault=false"
      - "--entrypoints.web.address=:80"
      - "--entrypoints.websecure.address=:443"
      - "--certificatesresolvers.le.acme.tlschallenge=true"
      - "[email protected]"
      - "--certificatesresolvers.le.acme.storage=/letsencrypt/acme.json"
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - "/var/run/docker.sock:/var/run/docker.sock:ro"
      - "./letsencrypt:/letsencrypt"

Ein Backend-Dienst nimmt dann mit Labels teil. Traefik liest sie über die Docker API, erstellt einen Router und fordert über den Resolver namens le ein Zertifikat an. Beim Start des Containers ist kein Neustart des Proxys nötig.

  whoami:
    image: traefik/whoami
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.whoami.rule=Host(`app.example.com`)"
      - "traefik.http.routers.whoami.entrypoints=websecure"
      - "traefik.http.routers.whoami.tls.certresolver=le"

nginx-proxy überwacht den Docker-Socket und erstellt seine nginx-Konfiguration neu, sobald ein Container mit der Umgebungsvariable VIRTUAL_HOST erscheint; ein Begleitcontainer verwaltet dabei die Let’s-Encrypt-Zertifikate. Sie deklarieren Ihre Absicht über Umgebungsvariablen statt über Labels.

services:
  nginx-proxy:
    image: nginxproxy/nginx-proxy
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - "/var/run/docker.sock:/tmp/docker.sock:ro"
      - "certs:/etc/nginx/certs"
      - "vhost:/etc/nginx/vhost.d"
      - "html:/usr/share/nginx/html"
  acme:
    image: nginxproxy/acme-companion
    volumes_from:
      - nginx-proxy
    volumes:
      - "/var/run/docker.sock:/var/run/docker.sock:ro"
      - "acme:/etc/acme.sh"
    environment:
      - "[email protected]"
  app:
    image: traefik/whoami
    environment:
      - "VIRTUAL_HOST=app.example.com"
      - "LETSENCRYPT_HOST=app.example.com"
volumes:
  certs:
  vhost:
  html:
  acme:

Caddy ist eine schlankere dritte Option. Standardmäßig bezieht und erneuert es Zertifikate automatisch, und seine Konfigurationsdatei bleibt kurz. Definieren Sie den Dienst in Compose und binden Sie ein Caddyfile sowie ein Datenvolume für die Zertifikate ein.

services:
  caddy:
    image: caddy:2
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - "./Caddyfile:/etc/caddy/Caddyfile"
      - "caddy_data:/data"
volumes:
  caddy_data:

Das Caddyfile selbst besteht aus einem einzeiligen Proxy mit automatischem TLS.

app.example.com {
    reverse_proxy app:8080
}

Wie vergleichen sich nginx-proxy, Traefik und Caddy?

Alle drei terminieren TLS und routen nach Hostnamen; sie unterscheiden sich vor allem im Konfigurationsstil und im Grad der Automatisierung. Die Tabelle fasst die praktischen Abwägungen zusammen.

Welchen Reverse Proxy sollten Sie wann wählen?

Wählen Sie das Werkzeug danach aus, wie häufig sich Ihre Container ändern und wie viel Konfiguration Sie selbst verwalten möchten. Die folgenden Regeln machen aus dem Vergleich eine direkte Entscheidung.

• Verwenden Sie nginx-proxy, wenn Sie eine feste Gruppe von Web-Apps betreiben und mit fast keiner Konfiguration funktionierendes HTTPS möchten.
• Verwenden Sie Traefik, wenn Container häufig erstellt und gelöscht werden oder Sie ein Dashboard, Middleware und labelgesteuertes Routing wünschen.
• Verwenden Sie Caddy, wenn Sie die kürzestmögliche Konfiguration wünschen und automatisches TLS Ihre Hauptanforderung ist.
• Vermeiden Sie nginx-proxy, wenn Ihre Dienste ständig hoch- und herunterskalieren, da die Erkennung über Umgebungsvariablen bei diesem Tempo unhandlich wird.
• Vermeiden Sie Traefik, wenn Ihr Team noch nie mit seiner Label-Syntax gearbeitet hat und Sie nur zwei oder drei stabile Websites per Proxy bereitstellen müssen.

Welche Einschränkungen und Vorbehalte gibt es?

Ein Docker-Reverse-Proxy löst eingehendes Routing und TLS, kann aber nicht alles beheben und birgt reale Risiken. Das Einbinden des Docker-Sockets, selbst schreibgeschützt, verschafft dem Proxy umfassende Einsicht in Ihren Host. Behandeln Sie diesen Container daher als sicherheitskritisch und halten Sie ihn aktuell.

Weitere häufige Fallstricke: Automatische Zertifikate schlagen fehl, wenn DNS noch nicht auf den Host zeigt oder die Ports 80 und 443 blockiert sind. Prüfen Sie DNS daher vor Ihrer ersten Bereitstellung. Backend-Container müssen ein Docker-Netzwerk mit dem Proxy teilen, sonst liefert das Routing stillschweigend Fehler. Die Ratenlimits von Let’s Encrypt bedeuten, dass Sie zuerst dessen Staging-Umgebung testen sollten, bevor Sie zu Produktionszertifikaten wechseln. Schließlich schafft ein Reverse Proxy keine zusätzliche Kapazität; ist ein Backend langsam, leitet der Proxy die Langsamkeit nur weiter.

Hinweis: Forward Proxy vs. Reverse Proxy. Dieser gesamte Artikel handelt von einem Reverse Proxy, der Datenverkehr verarbeitet, der in Ihre Container gelangt. Die entgegengesetzte Aufgabe, Datenverkehr von Ihrem Rechner über eine andere IP für Aufgaben wie Web Scraping oder Geo-Tests auszusenden, erfordert stattdessen einen Forward Proxy. Die beiden werden häufig verwechselt; der Unterschied wird in Reverse Proxy vs. Forward Proxy erklärt. Für diese ausgehende Seite bietet DataImpulse ethisch beschaffte Residential Proxies ab 1 Dollar pro GB. Es ist kein Reverse Proxy und leitet keinen Datenverkehr in Ihre Container, halten Sie die beiden Rollen daher getrennt.

Häufig gestellte Fragen

Verwandte Leitfäden

• NGINX-Reverse-Proxy
• Cloudflare-Reverse-Proxy
• NGINX-Forward-Proxy

Benötigen Sie ausgehende Proxys, nicht nur eingehendes Routing?

Wenn Ihr Projekt außerdem das Web von vielen Standorten aus erreichen muss, bietet DataImpulse ethisch beschaffte private, mobile und Rechenzentrums-IP-Adressen in 195 Ländern, Pay as you go ab 1 Dollar pro GB ohne Abonnement. Erstellen Sie ein kostenloses Konto, um den Dienst zusammen mit Ihrem Reverse-Proxy-Aufbau auszuprobieren.