Was ist mit Apache oder HAProxy?

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.

Uptime-Monitoring self-hosted mit Uptime Kuma

Uptime-Monitoring self-hosted mit Uptime Kuma | ComputeBox

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.

20 minEinsteigerGetestet auf Ubuntu 24.04, DockerAktualisiert 2026-07-07

Kurz gesagt

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.

Was ein Reverse Proxy leistet#

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.

Kandidat 1: Nginx — der Klassiker#

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 und zwar 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.

Kandidat 2: Caddy — der Einfache#

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, wie 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.

Kandidat 3: Traefik — der Docker-Native#

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.

Docker-Socket = Root-Zugriff

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.

Der direkte Vergleich#

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.

Entscheidungshilfe#

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, wie 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, stattdessen holt sich der neue Proxy eigene.

Konfiguriere dein VPS bei Uns

Fazit und Ausblick#

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 wirst du auch dann gewarnt, wenn dein Dienst von außen nicht mehr erreichbar ist, obwohl auf dem Server alles grün aussieht.

FAQ#

Häufige Fragen

Kann ich zwei Reverse Proxys parallel betreiben?

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.

Verliere ich beim Wechsel meine Zertifikate?

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.

Welcher Proxy ist am schnellsten?

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.

Wie geht es weiter?

Der Unterbau für deinen Reverse Proxy

VPS auf AMD EPYC mit NVMe SSD, volle Kontrolle, gehostet in Deutschland.

VPS konfigurieren

nginx

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";
    }
}

yaml

services:
  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