Nginx, Caddy oder Traefik: Welcher Proxy passt?

Nginx vs Caddy vs Traefik: die kurze Antwort

Nginx, Caddy und Traefik übernehmen als Reverse Proxy dieselbe Aufgabe: Sie lauschen an Port 443, lesen den Hostnamen jeder Anfrage aus und leiten die Anfrage an den richtigen Dienst auf Ihrem VPS weiter. Jede der drei Lösungen kann vier selbst gehostete Anwendungen hinter einer öffentlichen IP-Adresse bereitstellen. Alle sind schnell genug, sodass Ihre Anwendungen den langsameren Teil bilden. Die Unterschiede liegen darin, wie die jeweilige Lösung ein TLS-Zertifikat (Transport Layer Security) bezieht und wie viel Konfigurationsaufwand jede zusätzliche Anwendung verursacht. Der zweite Unterschied zeigt sich später, wenn Sie etwas benötigen, das in den üblichen Anleitungen nicht behandelt wird.

Wählen Sie Caddy, wenn HTTPS automatisch für Sie verwaltet werden soll und Ihre Dienste gewöhnliche Webanwendungen sind. Wählen Sie Traefik, wenn alles in Docker Compose läuft und Sie alle paar Wochen einen neuen Dienst hinzufügen. Wählen Sie Nginx, wenn Sie es bereits einsetzen oder wenn Sie Response-Caching, Client-Zertifikate, die Weiterleitung von rohem TCP oder eine umfangreiche bestehende Konfiguration benötigen, die Sie nicht neu schreiben möchten.

Wie erhält jede Variante ein TLS-Zertifikat?

Diese Achse entscheidet für die meisten Anwender, daher beginnen Sie hier. Am Ende verwenden alle drei dasselbe Zertifikat derselben Zertifizierungsstelle. Der Weg dorthin ist jedoch unterschiedlich.

Caddy fordert das Zertifikat an, weil Sie einen Hostnamen angegeben haben. Tragen Sie app.example.com als Site-Adresse ein. Caddy fordert dann über ACME (automatic certificate management environment) ein Zertifikat von Let's Encrypt an, wechselt bei einem Fehler zu ZeroSSL, stellt die HTTP-zu-HTTPS-Weiterleitung auf Port 80 bereit und erneuert das Zertifikat selbstständig. Sie benötigen kein zweites Tool und keinen Timer zur Kontrolle. Die Zertifikate liegen im Datenverzeichnis des Benutzers caddy, bei einer Paketinstallation unter /var/lib/caddy/.local/share/caddy. Nehmen Sie diesen Pfad daher in Ihre Backups auf oder akzeptieren Sie nach einer erneuten Installation eine neue Ausstellung. Für einen nicht öffentlichen Hostnamen signiert tls internal stattdessen mit der lokalen Zertifizierungsstelle von Caddy. Das entspricht dem Erstellen eines selbstsignierten Zertifikats unter Ubuntu, wobei die Erneuerung automatisch erfolgt.

Nginx verfügt über keinen ACME-Client. Certbot ruft das Zertifikat ab. Sein --nginx-Plugin ändert Ihren Server-Block und fügt den Listener für 443 sowie die Weiterleitung hinzu. Die Erneuerung läuft über einen systemd-Timer, den das Paket installiert. Es gibt daher zwei Komponenten und zwei Dinge zu prüfen: systemctl list-timers | grep certbot zeigt, dass der Timer vorhanden ist, und sudo certbot renew --dry-run bestätigt, dass der Erneuerungsprozess weiterhin funktioniert. Die Schritt-für-Schritt-Anleitung finden Sie unter Certbot unter Ubuntu 24.04 mit Nginx. Dasselbe Tool unterstützt ein Wildcard-Zertifikat über die DNS-01-Challenge, wenn Sie mehr Subdomains haben, als Sie einzeln angeben möchten.

Traefik enthält einen eigenen ACME-Client. Sie konfigurieren einen Zertifikats-Resolver in der statischen Konfiguration. Danach kann jeder Router diesen Resolver verwenden. Der gesamte Status, einschließlich Account-Key und Zertifikaten, liegt in einer einzigen acme.json-Datei. Traefik verwendet diese Datei nicht, wenn sie für andere Benutzer als den Eigentümer lesbar ist. Bevor Traefik den Resolver entfernt, weist es darauf hin:

The ACME resolver "le" is skipped from the resolvers list because: unable to get ACME account: permissions 660 for /letsencrypt/acme.json are too open, please use 600

Binden Sie ein Verzeichnis ein und lassen Sie Traefik die Datei selbst erstellen. Erstellen Sie das Verzeichnis zunächst mit touch. Dadurch übernimmt es Ihre umask. So erfüllen die meisten Anwender diese Vorgabe.

Eine Eigenschaft gilt für alle drei Varianten. Die HTTP-01-Challenge benötigt Port 80, der aus dem Internet erreichbar ist, weil die Zertifizierungsstelle eine Verbindung dorthin aufbaut. Wenn Sie nur 443 öffnen, schlägt die Ausstellung fehl. Die Fehlermeldung wirkt dabei wie ein DNS-Problem.

Das gleiche Routing für zwei Anwendungen in drei Konfigurationen

Die Aufgabe: app.example.com wird an einen Dienst auf 127.0.0.1:8080 weitergeleitet, files.example.com an einen Dienst auf 127.0.0.1:8081, beide über HTTPS. Hier sehen Sie die vollständige Konfiguration für jeden Proxy. Dadurch wird der Unterschied im Umfang sichtbar, statt nur behauptet zu werden.

Nginx

# /etc/nginx/sites-available/app.example.com
server {
    listen 80;
    server_name app.example.com;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Verknüpfen Sie die Konfiguration anschließend, testen Sie sie, laden Sie sie neu und fügen Sie das Zertifikat hinzu.

sudo ln -s /etc/nginx/sites-available/app.example.com /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx
sudo certbot --nginx -d app.example.com

nginx -t mit syntax is ok und test is successful auszugeben, ist die Prüfung, die Sie vor jedem Reload ausführen sollten. Die zweite Anwendung verwendet denselben Block, wobei Hostname und Port geändert werden. Die proxy_set_header-Zeilen sind keine Dekoration: Wenn proxy_pass eine Adresse angibt, sendet nginx standardmäßig Host: 127.0.0.1:8080 an das Backend. Eine Anwendung, die absolute URLs aus dem Host-Header erzeugt, würde Ihre Benutzer dadurch an localhost weiterleiten.

Caddy

app.example.com {
	reverse_proxy 127.0.0.1:8080
}

files.example.com {
	reverse_proxy 127.0.0.1:8081
}

sudo caddy validate --config /etc/caddy/Caddyfile
sudo systemctl reload caddy

Das ist die vollständige Datei. reverse_proxy setzt X-Forwarded-For, X-Forwarded-Proto und X-Forwarded-Host selbst. Standardmäßig ignoriert es die Werte, die der Client in diesen Headern gesendet hat. Eine Anfrage kann Ihr Backend dadurch nicht über ihre Herkunft täuschen. Zertifikate, die Weiterleitung von Port 80 und die Erneuerung ergeben sich aus den beiden Site-Adressen. Im Dateiinhalt ist keine weitere Konfiguration dafür erforderlich.

Traefik

Traefik benötigt eine statische Konfiguration, bevor es Anfragen weiterleiten kann. Als Compose-Dienst mit dem im August 2026 aktuellen Image-Tag sieht sie so aus:

services:
  traefik:
    image: traefik:v3.7
    command:
      - "--providers.docker=true"
      - "--providers.docker.exposedbydefault=false"
      - "--entrypoints.web.address=:80"
      - "--entrypoints.websecure.address=:443"
      - "--certificatesresolvers.le.acme.email=you@example.com"
      - "--certificatesresolvers.le.acme.storage=/letsencrypt/acme.json"
      - "--certificatesresolvers.le.acme.httpchallenge.entrypoint=web"
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - ./letsencrypt:/letsencrypt

Jede Anwendung erhält anschließend ihre eigene Weiterleitung über Labels in ihrer eigenen Compose-Datei:

    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.app.rule=Host(`app.example.com`)"
      - "traefik.http.routers.app.entrypoints=websecure"
      - "traefik.http.routers.app.tls.certresolver=le"
      - "traefik.http.services.app.loadbalancer.server.port=8080"

loadbalancer.server.port ist der Port innerhalb des Containers und kein veröffentlichter Port, weil Traefik den Container über ein gemeinsam genutztes Docker-Netzwerk erreicht. Die Anwendung benötigt überhaupt keine ports:-Zeile. Das ist der eigentliche Vorteil: Nur Traefik wird veröffentlicht. Den vollständigen Aufbau einschließlich des gemeinsam genutzten Netzwerks und der Redirect-Middleware finden Sie unter Mehrere Anwendungen mit Traefik und Docker Compose routen.

Wie viel Konfiguration kostet jede weitere Anwendung?

[
  {
    "tool": "Nginx",
    "proxy_setup_lines": 0,
    "lines_per_app": 11
  },
  {
    "tool": "Caddy",
    "proxy_setup_lines": 0,
    "lines_per_app": 3
  },
  {
    "tool": "Traefik",
    "proxy_setup_lines": 17,
    "lines_per_app": 5
  }
]

Aus den obigen Blöcken gezählt. Der Nginx-Server-Block umfasst 11 nicht leere Zeilen und wird für jeden Hostnamen erneut angelegt. Der Caddy-Site-Block umfasst 3 Zeilen. Traefik benötigt 17 Zeilen statischer Konfiguration, bevor die erste Anfrage verarbeitet wird, und anschließend 5 Labels pro Anwendung.

Betrachten Sie die Unterschiede, nicht nur den Sieger. Traefik verursacht vor der ersten Anwendung den größten Aufwand und danach pro weiterer Anwendung den geringsten. Die beiden Gesamtwerte treffen sich ungefähr bei der dritten Site. Unterhalb davon ist die statische Konfiguration zusätzlicher Aufwand, den Sie nicht benötigen. Oberhalb davon liegen die Labels vorn und der Abstand wächst weiter, weil die Weiterleitung direkt neben dem Dienst definiert ist, für den sie gilt. Löschen Sie den Dienst, wird auch seine Route gelöscht. Genau das ist eine Schwäche einer zentralen Konfigurationsdatei: veraltete Server-Blöcke für Anwendungen, die seit Monaten nicht mehr existieren.

Die Zeilenzahl stellt Nginx außerdem günstiger dar, als es ist. Für jeden dieser Blöcke benötigen Sie zusätzlich einen Symlink, ein nginx -t, einen Reload und einen certbot-Aufruf. Eine Änderung an Caddy erfordert dagegen einen Reload, eine Änderung an Traefik überhaupt keinen Befehl. Alle drei können neu geladen werden, ohne bestehende Verbindungen zu unterbrechen. Der Unterschied besteht darin, wie viele einzelne Schritte Sie sich um ein Uhr morgens merken müssen.

Welcher Proxy kennt Ihre Container?

Traefik überwacht den Docker-Socket und erstellt anhand von Container-Labels Router, sobald Container gestartet oder beendet werden. Kein anderes Produkt in diesem Vergleich erledigt das automatisch. Bei Nginx und Caddy müssen Sie die Konfiguration bearbeiten und neu laden, wenn ein neuer Container hinzukommt. Außerdem benötigen beide eine erreichbare Adresse: entweder einen auf dem Loopback-Interface veröffentlichten Port oder ein gemeinsames Docker-Netzwerk, mit dem der Proxy verbunden ist.

Diese Funktion hat einen Preis, den man klar benennen sollte. Traefik liest /var/run/docker.sock. Jeder, der mit diesem Socket kommunizieren kann, kann einen Container starten und darin das Host-Dateisystem einhängen. Damit erhält er root-Zugriff auf den Host. Die schreibgeschützte Einbindung reduziert das Risiko, beseitigt es aber nicht. Wenn dies für Ihr Bedrohungsmodell relevant ist, schalten Sie einen Socket-Proxy dazwischen. Dieser sollte nur die Endpunkte für die Containerliste bereitstellen, die Traefik benötigt.

Caddy kann die Erkennung anhand von Labels über ein Community-Plugin durchführen. Caddy-Plugins werden jedoch fest einkompiliert. Sie müssen daher eine eigene Binärdatei oder ein eigenes Image mit xcaddy erstellen und sind anschließend für diesen Build und seine Updates verantwortlich. Bei drei oder vier Diensten ist das Bearbeiten einer Caddyfile weniger Arbeit.

WebSockets und Streaming: Was ausfällt und warum

Nginx benötigt hierbei zusätzliche Konfiguration. Eine WebSocket-Verbindung beginnt als HTTP-Anfrage mit Upgrade: websocket. nginx leitet Hop-by-Hop-Header nicht an das Backend weiter, sofern Sie dies nicht ausdrücklich konfigurieren.

# /etc/nginx/conf.d/upgrade-map.conf
map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

Im location-Block müssen anschließend drei Zeilen vorhanden sein:

        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;

Wenn diese Zeilen fehlen, zeigt die Browserkonsole WebSocket connection to 'wss://app.example.com/ws' failed an, während das Backend-Log einen gewöhnlichen GET verzeichnet. map ist erforderlich, weil ein fest eingetragenes Connection: upgrade bei jeder Anfrage gesendet würde, auch bei normalen Anfragen, die close enthalten sollten.

Zwei weitere Nginx-Standardeinstellungen verursachen Probleme. proxy_read_timeout beträgt 60 Sekunden und gilt nach dem Upgrade für den Tunnel. Ein WebSocket ohne Datenverkehr wird daher nach einer Minute vom Proxy geschlossen. Server-Sent Events treffen außerdem verspätet oder in Blöcken ein, bis Sie für diesen Standort proxy_buffering off; setzen, weil nginx die Antwort in seinem Puffer zurückhält, während Ihre Seite darauf wartet.

Caddy führt das Upgrade durch und wechselt ohne zusätzliche Direktiven in einen bidirektionalen Tunnel. Bei einer Antwort mit text/event-stream oder ohne bekannte Länge leert Caddy den Puffer ebenfalls sofort. Streaming funktioniert daher ohne weitere Anpassungen. Traefik leitet Upgrades weiter und puffert Antworten nicht, sofern Sie nicht selbst seine buffering-Middleware hinzufügen. Wenn Ihre Dienste Chat, ein Webterminal, Log-Ausgaben oder Live-Dashboards umfassen, wirkt sich das deutlich darauf aus, wie viel Konfiguration Sie schreiben und untersuchen müssen.

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

server {
    listen 80;
    server_name app.example.com;
    client_max_body_size 64m;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
        proxy_read_timeout 3600s;
        proxy_buffering off;
    }
}

Was geschieht, wenn Sie etwas Ungewöhnliches benötigen?

Hier spielt Nginx seine zusätzlichen Konfigurationszeilen aus.

• Clientzertifikate, auch mTLS (mutual TLS) genannt, bei denen der Client ebenfalls ein Zertifikat vorlegen muss. Nginx benötigt ssl_client_certificate /etc/ssl/ca.pem; und ssl_verify_client on; im Server-Block. Caddy benötigt einen client_auth-Block innerhalb von tls. Traefik-Labels können dies überhaupt nicht ausdrücken: Sie definieren eine TLS-Option in einem File-Provider und verweisen mit traefik.http.routers.app.tls.options=mtls@file vom Router darauf. Das Modell, bei dem alles über Labels konfiguriert wird, hat also eine Ausnahme, sobald Sie diese Funktion benötigen.
• Große Uploads. Nginx begrenzt Request-Bodies standardmäßig auf 1 MB. Ein größerer Upload führt zu 413 Request Entity Too Large, und das Error-Log enthält client intended to send too large body. Erhöhen Sie den Wert mit client_max_body_size. Caddy und Traefik setzen standardmäßig kein Body-Limit, daher erreicht der Request Ihre Anwendung, und das anwendungseigene Limit entscheidet.
• Response-Caching. Nginx bietet proxy_cache, und diese Funktion ist ausgereift. Für Caddy muss ein Plugin einkompiliert werden. Der Open-Source-Build von Traefik enthält überhaupt keinen HTTP-Cache. Das überrascht Anwender, die davon ausgehen, dass jeder Proxy cached.
• Unverarbeitetes TCP oder UDP, beispielsweise für einen Datenbankport oder einen Gameserver. Nginx bietet das stream-Modul. Traefik verfügt über TCP- und UDP-Router an eigenen EntryPoints. Für Caddy wird ein weiteres Plugin benötigt, also ein weiterer eigener Build.
• Ein Webserver, der bereits hinter dem Proxy läuft. Wenn es sich bei dem Dienst um eine klassische PHP-Anwendung handelt, enthält ein LAMP-Stack auf Ubuntu 24.04 bereits Apache. Wenn Sie davor zusätzlich einen Proxy schalten, gibt es zwei Stellen, die Header setzen, und zwei Stellen, die eine URL umschreiben können. Legen Sie fest, welcher Dienst TLS terminiert. Lassen Sie den anderen anschließend über unverschlüsseltes HTTP an loopback gebunden laufen.

Die Firewall-Falle, die aus dieser Entscheidung folgt

Der Zweck eines Reverse Proxy besteht darin, dass nur 80 und 443 geöffnet sind. Docker hebt das unbemerkt auf. Das Veröffentlichen eines Ports mit -p 8080:80 schreibt eine DNAT-Regel in die nat-Tabelle. Diese Regel wird vor den INPUT-Regeln ausgewertet, die ufw verwaltet. Daher blockiert ufw deny 8080 den Zugriff nicht. Ihre Anwendung ist dann neben dem sorgfältig konfigurierten Proxy im öffentlichen Internet erreichbar. Binden Sie veröffentlichte Ports mit 127.0.0.1:8080:80 an das Loopback-Interface. Alternativ lassen Sie ports: vollständig weg und ermöglichen dem Proxy den Zugriff auf den Container über ein Docker-Netzwerk. Genau das macht das Traefik-Beispiel oben. Die Funktionsweise und die Lösung werden unter warum von Docker veröffentlichte Ports ufw umgehen beschrieben.

Testen Sie dies von einem Rechner, der nicht der VPS ist. Eine Prüfung, die direkt auf dem Server ausgeführt wird, ist immer erfolgreich:

curl --max-time 5 http://your.server.address:8080

Connection refused oder ein Timeout ist das gewünschte Ergebnis. Eine HTTP-Antwort bedeutet, dass die Anwendung ohne Ihren Proxy erreichbar ist. Dann sind alle oben vorgenommenen Konfigurationen wirkungslos.

Welchen Proxy sollten Sie auswählen?

Überwiegend statische Websites und zusätzlich eine oder zwei Anwendungen: Caddy. Automatisches HTTPS beseitigt den größten wiederkehrenden Administrationsaufwand. Die Konfiguration bleibt kurz genug, um sie auf einem Bildschirm zu lesen. Eine statische Website besteht innerhalb desselben Site-Blocks aus einer root-Zeile und einer file_server-Zeile. Der Nachteil ist eine kleinere Auswahl an fertigen Antworten zum Kopieren, wenn etwas unerwartet ausfällt.

Ein docker-compose-Homelab, das Sie laufend erweitern: Traefik. Ab dem dritten Dienst ist die Arbeit mit Labels einfacher als das Bearbeiten einer zentralen Datei. Wenn Sie einen Dienst löschen, wird auch seine Route entfernt. Planen Sie für die Ersteinrichtung einen Nachmittag ein. Entrypoints, Router, Services und Middlewares sind zunächst neue Begriffe. Ein Tippfehler in einem Label führt normalerweise zu einem 404 von Traefik und nicht dazu, dass der Dienst nicht startet. Lesen Sie daher docker logs traefik auf den Parse-Fehler, bevor Sie von einem Fehler der Anwendung ausgehen.

Eine vorhandene Nginx-Konfiguration oder eine der oben genannten Anforderungen: Nginx. Nginx bietet bereits Lösungen für Response-Caching und Client-Zertifikate. Außerdem setzen fast alle Anleitungen von Drittanbietern Nginx voraus. Der Nachteil ist, dass Sie Zertifikate und WebSocket-Unterstützung konfigurieren müssen. Sie sind nicht automatisch verfügbar.

Eine Regel gilt unabhängig von Ihrer Auswahl. Genau ein Prozess lauscht auf der öffentlichen Schnittstelle. Alle anderen Prozesse lauschen auf Loopback oder in einem privaten Docker-Netzwerk.

FAQ

Welcher Reverse Proxy eignet sich am besten für einige Docker-Anwendungen auf einem VPS?

Für drei oder vier Dienste, die Sie nur gelegentlich hinzufügen, lohnt sich Traefik. Jede Anwendung enthält ihre eigenen Routing-Labels. Eine zentrale Datei muss nicht bearbeitet werden. Wenn die Dienste stabil sind und Sie hauptsächlich möchten, dass HTTPS nicht mehr Ihre Aufgabe ist, müssen Sie bei Caddy weniger lernen und können weniger falsch konfigurieren. Wählen Sie Nginx, wenn Sie damit bereits vertraut sind oder eine Funktion benötigen, die den anderen beiden fehlt, beispielsweise Response-Caching oder einen einfachen TCP-Listener.

Benötigt Caddy wirklich keine Zertifikatkonfiguration?

Im Normalfall ja. Ein öffentlicher Hostname als Site-Adresse ist die vollständige Konfiguration. Caddy fordert das Zertifikat über ACME an, liefert die Weiterleitung von Port 80 aus und erneuert das Zertifikat vor dem Ablauf. Zwei Voraussetzungen müssen trotzdem erfüllt sein. Port 80 muss für die HTTP-01-Challenge aus dem Internet erreichbar sein. Außerdem muss der DNS-A- oder AAAA-Record des Hostnamens bereits auf den VPS zeigen, weil die Zertifizierungsstelle den Namen auflöst und eine Verbindung zu ihm herstellt.

Kann ich Nginx und Traefik auf demselben VPS ausführen?

Nicht auf denselben Ports. Der Proxy, der als Zweiter startet, kann den Port nicht binden. nginx meldet bind() to 0.0.0.0:443 failed (98: Address already in use). Traefik protokolliert einen ähnlichen Bind-Fehler und beendet sich. Lassen Sie einen Proxy auf 80 und 443 laufen. Leiten Sie alle anderen Dienste dahinter weiter. Wenn Sie migrieren, verschieben Sie die Hostnamen nacheinander. Lassen Sie den Front-Proxy bis zur Umstellung der letzten Site an den alten Proxy auf einem Loopback-Port weiterleiten.

Warum werden meine WebSockets hinter Nginx nach 60 Sekunden getrennt?

proxy_read_timeout verwendet standardmäßig 60 Sekunden. Der Wert gilt für den Tunnel, sobald das Upgrade abgeschlossen ist. Eine Verbindung ohne Datenverkehr wird nach einer Minute vom Proxy und nicht von Ihrer Anwendung geschlossen. Erhöhen Sie den Wert für diesen Location-Block mit proxy_read_timeout 3600s;. Alternativ kann die Anwendung alle 30 Sekunden einen Ping-Frame senden. Caddy und Traefik schließen aktualisierte Verbindungen ohne Datenverkehr nicht nach einem Timer von einer Minute. Deshalb kann dieselbe Anwendung hinter ihnen stabil wirken, hinter Nginx jedoch instabil.