VPS & Server
Nginx vs. Caddy vs. Traefik: den richtigen Reverse Proxy wählen
Mache deinen Setup production-ready Teil 3
von Ludwig Roth7. Juli 2026
Mache deinen Setup production-ready Teil 3
Fast jeder Dienst auf deinem Server landet früher oder später hinter einem Reverse Proxy: Er nimmt Anfragen auf Port 80/443 entgegen, kümmert sich um HTTPS und verteilt den Traffic an die richtigen Container. Aber welcher soll es sein? Nginx ist der Klassiker, Caddy der Einfachste, Traefik der Docker-Spezialist. In diesem Teil der Reihe „Der produktionsreife Server" vergleichen wir alle drei am selben Beispiel — damit du eine Entscheidung treffen kannst, die zu deinem Setup passt, nicht zur lautesten Empfehlung im Netz.
Für die meisten VPS-Setups mit einer Handvoll Diensten ist Caddy die beste Wahl: automatisches HTTPS, minimale Konfiguration. Traefik lohnt sich, wenn ständig Container dazukommen und verschwinden. Nginx bleibt richtig, wenn du maximale Kontrolle brauchst, exotische Konfigurationen fährst — oder es schlicht schon läuft.
Bevor wir vergleichen, kurz das gemeinsame Fundament. Ein Reverse Proxy übernimmt auf deinem Server vier Aufgaben: Er lauscht als einziger Dienst auf den Ports 80 und 443, terminiert TLS (also HTTPS samt Zertifikaten), routet Anfragen anhand der Domain an den passenden internen Dienst und schirmt deine Container vom direkten Internetzugriff ab. Deine Dienste selbst binden nur noch an 127.0.0.1 oder bleiben komplett im Docker-Netzwerk — genau so haben wir es in Teil 1 mit Grafana gemacht.
Damit der Vergleich fair ist, lösen alle drei Kandidaten dieselbe Aufgabe: Grafana unter grafana.deine-domain.de per HTTPS bereitstellen, mit automatischer Weiterleitung von HTTP.
Nginx betreibt einen erheblichen Teil des Internets, ist extrem performant und kann praktisch alles: Reverse Proxy, Load Balancing, Caching, Rate Limiting, statische Auslieferung. Der Preis dafür ist Handarbeit — vor allem beim Thema Zertifikate, die du separat mit Certbot verwaltest.
Dazu kommt das Zertifikat, das Certbot ausstellt und automatisch erneuert:
Stärken: unschlagbare Flexibilität, riesige Community, zu fast jedem Problem existiert eine dokumentierte Lösung. Sehr sparsam bei RAM und CPU. De-facto-Standard, den jeder Admin kennt.
Schwächen: Die Konfiguration ist geschwätzig — die proxy_set_header-Zeilen oben musst du kennen, sonst funktionieren WebSockets (die Grafana nutzt) nicht. HTTPS ist ein separates System mit eigener Fehlerquelle. Jede Änderung heißt: Datei editieren, nginx -t, reload.
Dieselbe Aufgabe in Caddy, komplett:
Das ist kein gekürztes Beispiel. Caddy holt das Zertifikat selbst bei Let's Encrypt, erneuert es automatisch, leitet HTTP auf HTTPS um, setzt die richtigen Proxy-Header und unterstützt WebSockets ohne Zusatzkonfiguration. Wie du Caddy aufsetzt, zeigt unser Caddy-Tutorial.
Stärken: Automatisches HTTPS als Kernfeature, nicht als Anbau. Die Konfiguration ist so kurz, dass Fehler kaum Platz haben. Sinnvolle, sichere Defaults (moderne TLS-Versionen, HTTP/2 und HTTP/3 ab Werk). Für jeden weiteren Dienst kommen drei Zeilen dazu.
Schwächen: Bei sehr speziellen Anforderungen — komplexes Caching, ausgefallene Rewrite-Logik — wird die Dokumentation dünner und die Community kleiner als bei Nginx. Wer fertige Konfigurationen aus dem Netz übernehmen will, findet fast immer Nginx-Beispiele und muss übersetzen.
Traefik dreht das Prinzip um: Statt einer zentralen Konfigurationsdatei liest es den Docker-Socket und konfiguriert sich selbst anhand von Labels an deinen Containern. Der Proxy selbst wird einmal aufgesetzt:
Danach passiert alles Weitere direkt am jeweiligen Dienst — Grafana bekommt in der Compose-Datei nur Labels:
Startet der Container, existiert die Route. Stoppt er, verschwindet sie. Kein Reload, keine zentrale Datei anfassen.
Stärken: Perfekt, wenn Dienste dynamisch kommen und gehen — die Routing-Konfiguration lebt beim Dienst selbst, nicht in einer zentralen Datei. Automatisches HTTPS wie Caddy. Eingebautes Dashboard zeigt alle Routen und deren Status.
Schwächen: Die steilste Lernkurve der drei — Router, Services, Middlewares, EntryPoints und Resolver sind eigene Konzepte, die man erst verinnerlichen muss. Für Dienste außerhalb von Docker (etwa eine lokale Anwendung direkt auf dem Host) ist die Konfiguration umständlicher als bei den anderen beiden. Und Tippfehler in Labels schlagen leise fehl: Der Container startet normal, nur die Route fehlt.
Traefik (und jedes andere Tool mit Zugriff auf /var/run/docker.sock) hat damit faktisch Root-Rechte auf dem Host. Mounte den Socket wie im Beispiel nur read-only und ziehe für exponierte Setups einen Socket-Proxy in Betracht, der die API auf Lesezugriffe beschränkt.
| Kriterium | Nginx | Caddy | Traefik |
|---|---|---|---|
| Konfigurationsaufwand | Hoch | Minimal | Mittel |
| Automatisches HTTPS | Nein (Certbot nötig) | Ja, eingebaut | Ja, eingebaut |
| Docker-Integration | Manuell | Manuell | Automatisch per Labels |
| WebSockets | Manuell konfigurieren | Automatisch | Automatisch |
| Lernkurve | Mittel | Flach | Steil |
| Community & Beispiele | Riesig | Solide | Solide |
| Ressourcenbedarf | Sehr gering | Gering |
Zur Performance ein ehrliches Wort: Auf einem typischen VPS mit einer Handvoll Diensten ist sie kein Entscheidungskriterium. Alle drei bewältigen problemlos mehr Traffic, als deine Anwendungen dahinter verarbeiten können. Benchmarks, in denen Nginx ein paar Prozent vorne liegt, betreffen Lastbereiche, die du auf einem einzelnen Server nie erreichst — entscheide nach Wartbarkeit, nicht nach synthetischen Zahlen.
Nimm Caddy, wenn du einen VPS mit einer überschaubaren Zahl an Diensten betreibst und einfach willst, dass HTTPS funktioniert — ohne Zertifikats-Cronjobs, ohne Header-Studium. Das trifft auf die meisten Self-Hosting-Setups zu, weshalb auch unsere Tutorials Caddy als Standard verwenden.
Nimm Traefik, wenn dein Setup lebt: viele Container, häufige Deployments, vielleicht mehrere Projekte auf einem Host. Sobald du beim Gedanken „neuer Dienst = zentrale Proxy-Config anfassen" die Stirn runzelst, bist du Traefik-Kandidat.
Nimm (oder behalte) Nginx, wenn du seine Flexibilität wirklich brauchst — feingranulares Caching, komplexe Rewrites, Rate Limiting — oder wenn ein gewachsenes Nginx-Setup existiert, das zuverlässig läuft. Ein funktionierender Reverse Proxy ist kein Migrationsgrund.
Und falls du wechseln willst: Der Umstieg ist dankbar, weil die Dienste dahinter nichts davon mitbekommen. Neuen Proxy parallel auf anderen Ports aufsetzen, eine unkritische Subdomain testweise umziehen, dann Domain für Domain nachziehen. Nur die Let's-Encrypt-Zertifikate nimmst du nicht mit — der neue Proxy holt sich einfach eigene.
Es gibt keinen „besten" Reverse Proxy, aber es gibt den passenden für dein Setup: Caddy für unkompliziertes Self-Hosting, Traefik für dynamische Container-Landschaften, Nginx für Spezialfälle und Bestandssysteme. Wichtiger als die Wahl ist, dass dahinter alles sauber aufgesetzt ist — deine Dienste nicht öffentlich gebunden, die Firewall konfiguriert und das Monitoring aus Teil 1 im Blick.
Im nächsten Teil der Reihe „Der produktionsreife Server" richten wir Uptime-Monitoring mit Uptime Kuma ein — damit du auch dann gewarnt wirst, wenn dein Dienst von außen nicht mehr erreichbar ist, obwohl auf dem Server alles grün aussieht.
Dauerhaft ist das selten sinnvoll, aber für eine Migration funktioniert es gut: Der neue Proxy lauscht zunächst auf anderen Ports (z. B. 8080/8443), du testest eine Subdomain, und erst zum Schluss tauschst du die Ports 80/443. Nur ein Prozess kann einen Port belegen.
Praktisch nein: Caddy und Traefik holen sich beim ersten Start automatisch neue Zertifikate von Let's Encrypt, das dauert Sekunden. Ein manueller Export alter Certbot-Zertifikate ist unnötig.
In synthetischen Benchmarks meist Nginx — auf einem typischen VPS mit normalen Web-Anwendungen ist der Unterschied aber irrelevant, weil die Anwendung dahinter der Flaschenhals ist. Entscheide nach Wartbarkeit und Team-Wissen, nicht nach Benchmark-Balken.
VPS auf AMD EPYC mit NVMe SSD, volle Kontrolle, gehostet in Deutschland.
VPS konfigurieren
| Gering |
| Ideal für | Spezialfälle, Bestand | 1–20 Dienste auf einem VPS | Dynamische Container-Flotten |
Apache kann als Reverse Proxy dienen, spielt seine Stärken aber eher als klassischer Webserver aus. HAProxy ist ein exzellenter Load Balancer für große Setups, bringt jedoch kein automatisches HTTPS mit. Für den typischen VPS-Anwendungsfall sind die drei verglichenen Kandidaten die praktischere Wahl.
grafana.deine-domain.de {
reverse_proxy localhost:3000
}server {
listen 80;
server_name grafana.deine-domain.de;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl;
http2 on;
server_name grafana.deine-domain.de;
ssl_certificate /etc/letsencrypt/live/grafana.deine-domain.de/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/grafana.deine-domain.de/privkey.pem;
location / {
proxy_pass http://localhost:3000;
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 "upgrade";
}
}sudo certbot --nginx -d grafana.deine-domain.deservices:
traefik:
image: traefik:v3
container_name: traefik
restart: unless-stopped
command:
- "--providers.docker=true"
- "--providers.docker.exposedbydefault=false"
- "--entrypoints.web.address=:80"
- "--entrypoints.websecure.address=:443"
- "--entrypoints.web.http.redirections.entrypoint.to=websecure"
- "[email protected]"
- "--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
networks:
- monitoring grafana:
image: grafana/grafana-oss:latest
# ... bestehende Konfiguration ...
labels:
- "traefik.enable=true"
- "traefik.http.routers.grafana.rule=Host(`grafana.deine-domain.de`)"
- "traefik.http.routers.grafana.entrypoints=websecure"
- "traefik.http.routers.grafana.tls.certresolver=le"