Caddy als Reverse Proxy einrichten in 2026 (automatisches HTTPS, Docker und wann Sie sich dafür entscheiden sollten)

Ein Caddy-Reverse-Proxy stellt einen einzigen kleinen, schnellen Webserver vor Ihre Anwendungen und versorgt jede davon automatisch mit einem gültigen HTTPS-Zertifikat – ohne certbot, ohne cron-Erneuerungen und in der Regel mit nicht mehr als drei Zeilen Konfiguration. Richten Sie eine Domain auf Ihren Server, schreiben Sie example.com { reverse_proxy localhost:8080 }, starten Sie Caddy, und Sie haben eine produktionsreife HTTPS-Eingangstür. Dieser Leitfaden führt Sie durch die Installation von Caddy, das Schreiben des Caddyfile, den Betrieb in Docker und die Entscheidung, wann Caddy der richtige Reverse Proxy ist – im Vergleich zu Nginx, Traefik oder einem Cloudflare Tunnel.

Was ist ein Caddy-Reverse-Proxy, und warum sollten Sie ihn verwenden?

Ein Reverse Proxy sitzt zwischen dem öffentlichen Internet und Ihren Anwendungen. Statt jede App über einen eigenen Port bereitzustellen (der klassische Wildwuchs aus server-ip:8080, server-ip:3000), lauscht der Proxy auf den Ports 80 und 443, terminiert TLS und leitet jede eingehende Anfrage anhand des Hostnamens oder Pfads an das richtige Backend weiter. Das verschafft Ihnen saubere URLs, einen zentralen Ort für die Zertifikatsverwaltung und einen einzigen Engpass für Security-Header und Rate-Limits.

Caddy hebt sich ab, weil automatisches HTTPS standardmäßig aktiviert ist: Sobald Caddy Ihren Domainnamen kennt, stellt es ein Let's Encrypt- oder ZeroSSL-Zertifikat für Sie bereit, erneuert es und behält diese Erneuerung dauerhaft bei. Nginx und Traefik können das ebenfalls, aber Caddy benötigt dafür die geringste Konfiguration. Wie XDA es ausdrückt, ist Caddy "eine wirklich einfache Möglichkeit, SSL-Zertifikate für Ihre selbst gehosteten Apps zu erhalten" – genau die Aufgabe, für die die meisten Menschen einen Reverse Proxy einsetzen möchten.

Caddy unter Ubuntu oder Debian installieren

Auf einem frischen Ubuntu- oder Debian-VPS installieren Sie Caddy aus dem offiziellen apt-Repository. Dies sind die aktuellen Befehle aus der Caddy-Dokumentation:

sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install caddy

Die Installation über apt richtet Caddy als systemd-Dienst ein, der beim Systemstart hochfährt und seine Konfiguration aus /etc/caddy/Caddyfile liest. Prüfen Sie die Version mit caddy version; Stand Mitte 2026 ist Caddy 2.11.4 (Juni 2026) die aktuelle stabile Version, und die jüngsten 2.11.x-Releases haben Sicherheitslücken behoben, darunter CVE-2026-27590 und CVE-2026-27589 (beide in 2.11.1 gefixt) – setzen Sie also einen aktuellen Build ein und nicht das, was vor einem Jahr ausgeliefert wurde. Wenn Sie den Host lieber gar nicht anfassen möchten, springen Sie direkt zum Docker-Abschnitt. Bevor Sie irgendetwas öffentlich zugänglich machen, stellen Sie zuerst sicher, dass der Server selbst abgesichert ist – gemäß unserem Leitfaden zu der sicheren ersten Stunde auf einem neuen VPS.

Das minimale Caddyfile: eine Zeile für automatisches HTTPS

Der ganze Sinn von Caddy liegt darin, wie wenig Sie schreiben müssen. Bearbeiten Sie /etc/caddy/Caddyfile so, dass es einen Site-Block mit Ihrer echten Domain und der lokalen Adresse der App enthält, die Sie bereitstellen möchten:

example.com {
    reverse_proxy localhost:8080
}

Laden Sie mit sudo systemctl reload caddy neu (oder caddy reload, wenn Sie es manuell betreiben), und Sie sind fertig. Beim Start lauscht Caddy auf den Ports 80 und 443, fordert ein vertrauenswürdiges Zertifikat für example.com an und leitet den Datenverkehr an Ihre App auf Port 8080 weiter. Zwei Dinge müssen erfüllt sein, damit das Zertifikat ausgestellt wird: Ein A/AAAA-DNS-Eintrag für die Domain muss auf den Server zeigen, und die Ports 80 und 443 müssen zum öffentlichen Internet hin offen sein, damit die ACME-Challenge abgeschlossen werden kann. Für einen schnellen lokalen Test ohne Domain verwenden Sie localhost als Site-Adresse, und Caddy installiert sein eigenes selbstsigniertes Zertifikat. Machen Sie es sich zur Gewohnheit, vor jedem Reload caddy validate --config /etc/caddy/Caddyfile auszuführen; das fängt Tippfehler ab, bevor sie eine Site lahmlegen.

Mehrere Apps und Subdomains proxen

Mehrere Dienste hinter einem einzigen Server zu betreiben, ist genau der Punkt, an dem sich ein Reverse Proxy bezahlt macht. Jede App erhält ihren eigenen Block, und Caddy leitet automatisch anhand des Hostnamens weiter und stellt für jede Domain ein eigenes Zertifikat bereit:

app.example.com {
    reverse_proxy localhost:3000
}

grafana.example.com {
    reverse_proxy localhost:3001
}

api.example.com {
    reverse_proxy localhost:5000
}

Sie können auch innerhalb einer Domain nach Pfad aufteilen, indem Sie einen handle_path- oder route-Block verwenden, was praktisch ist, wenn eine App unter example.com/api statt unter einer eigenen Subdomain liegen soll. Caddy verarbeitet WebSocket-Upgrades automatisch, sodass Echtzeit-Apps ohne zusätzliche Direktiven funktionieren, und seit Caddy 2.11 schreibt es den Upstream-Host-Header für HTTPS-Upstreams automatisch um, was eine häufige Quelle für Fehler nach dem Muster "es funktioniert auf Port 8080, aber nicht über den Proxy" beseitigt. Dieses Muster aus einer Subdomain pro App passt naturgemäß zu einer Flotte kleiner Dienste, wie sie in unserem Durchgang zum Selbsthosten Ihrer Apps auf einem VPS behandelt werden.

Caddy in Docker mit Docker Compose

Die meisten Selbsthoster betreiben Caddy in einem Container neben den Apps, die er bedient. Das offizielle caddy-Image macht daraus wenige Zeilen Compose. Das eine Detail, das oft übersehen wird, ist das caddy_data-Volume: Es speichert Ihre ausgestellten Zertifikate, und ohne es fordert jeder Container-Neustart die Zertifikate erneut an und kann in die Rate-Limits von Let's Encrypt laufen.

services:
  caddy:
    image: caddy:2.11
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - caddy_data:/data
      - caddy_config:/config
  app:
    image: your-app-image
    restart: unless-stopped

volumes:
  caddy_data:
  caddy_config:

Da beide Container ein Compose-Netzwerk teilen, kann das Caddyfile die App über ihren Dienstnamen statt über localhost erreichen:

app.example.com {
    reverse_proxy app:8080
}

Das ist das gesamte Setup: docker compose up -d, und Caddy bedient app.example.com über HTTPS mit automatisch erneuerten Zertifikaten. Wenn Sie das lieber von einem Dashboard aus steuern lassen möchten, verpackt eine Plattform wie Coolify dieselbe Idee; siehe unseren Leitfaden zum Deployen jeder App mit Coolify.

Caddy vs. Nginx vs. Traefik: Welchen Reverse Proxy sollten Sie wählen?

Alle drei sind solide, und die richtige Wahl hängt davon ab, wie Sie deployen. Caddy gewinnt bei der Einfachheit und dem sofort einsatzbereiten HTTPS, Nginx gewinnt bei der schieren Verbreitung und der Tuning-Tiefe, und Traefik gewinnt, wenn der Proxy sich selbst aus Container-Labels konfigurieren soll.

Reverse Proxy	Konfigurationsstil	Automatisches HTTPS	Docker-Eignung	Am besten geeignet für
Caddy	Caddyfile (wenige Zeilen)	Ja, standardmäßig	Einfache, explizite Konfiguration	Selbsthoster, die HTTPS mit fast keinem Setup wollen
Nginx	nginx.conf-Direktiven	Nein (benötigt certbot)	Manuell, sehr ausgereift	Tuning für hohen Traffic und bestehende Nginx-Umgebungen
Traefik	Container-Labels / YAML	Ja, mit Einrichtung	Erkennt Container automatisch	Dynamische, label-gesteuerte Docker- und Kubernetes-Flotten

Wenn Sie neu anfangen und einfach nur eine Handvoll Dienste über HTTPS bereitstellen möchten, ist Caddy der schnellste Weg. Wählen Sie Nginx, wenn Sie es bereits kennen oder sein riesiges Ökosystem an Modulen und die feingranularen Performance-Steuerungen benötigen. Wählen Sie Traefik, wenn Ihr Stack hochdynamisch ist und Sie möchten, dass sich der Proxy selbst neu konfiguriert, während Container kommen und gehen – und wenn Sie dafür mehr bewegliche Teile in Kauf nehmen.

Wo Caddy im Vergleich zu einem Cloudflare Tunnel passt

Ein Reverse Proxy und ein Tunnel lösen überlappende Probleme auf entgegengesetzte Weise, und es lohnt sich zu wissen, was Sie tatsächlich brauchen. Caddy setzt voraus, dass die eingehenden Ports 80 und 443 offen sind, damit es öffentlichen Datenverkehr annehmen und Zertifikate direkt ausstellen kann. Das ist ideal auf einem VPS mit öffentlicher IP. Ein Cloudflare Tunnel baut stattdessen eine ausgehende Verbindung zu Cloudflare auf und benötigt überhaupt keine offenen eingehenden Ports, was die bessere Wahl hinter einem Heimrouter oder einem restriktiven NAT ist, wo Sie keine Ports weiterleiten können.

Sie schließen sich nicht gegenseitig aus. Ein gängiges Setup betreibt Caddy als lokalen Reverse Proxy, der zu Ihren Apps weiterleitet und internes TLS terminiert, während ein Cloudflare Tunnel die öffentliche Bereitstellung und den Edge-Schutz übernimmt. Wenn Ihr Server eine öffentliche IP hat und Sie den denkbar einfachsten Stack wollen, genügt Caddy allein. Wenn Sie von einem Heimanschluss aus hosten oder Cloudflares DDoS-Schutz davor haben möchten, greifen Sie zum Tunnel – oder kombinieren Sie beides.

Häufig gestellte Fragen

Ist Caddy kostenlos nutzbar? Ja. Caddy ist Open Source unter der Apache 2.0-Lizenz und für jede Nutzung kostenlos, einschließlich der kommerziellen. Es gibt keine kostenpflichtige Stufe für die Reverse-Proxy-Funktionen, und automatisches HTTPS über Let's Encrypt und ZeroSSL kostet nichts.

Erneuert Caddy SSL-Zertifikate automatisch? Ja. Sobald Caddy ein Zertifikat für eine Domain ausgestellt hat, übernimmt es die Erneuerung selbstständig, typischerweise deutlich vor Ablauf, ohne cron-Job oder certbot. Halten Sie das Verzeichnis /data (bzw. das Docker-Volume caddy_data) persistent, damit Zertifikate Neustarts überstehen.

Caddy vs. Nginx: Was ist besser für einen Reverse Proxy? Für die meisten selbst gehosteten Setups ist Caddy einfacher, weil HTTPS automatisch ist und die Konfiguration nur wenige Zeilen umfasst. Nginx ist besser, wenn Sie sein ausgereiftes Modul-Ökosystem benötigen, für sehr hohen Traffic tunen oder es bereits betreiben. Beide sind produktionsreife Reverse Proxies.

Kann ich Caddy als Reverse Proxy in Docker betreiben? Ja, und das ist die gängigste Art, ihn zu betreiben. Verwenden Sie das offizielle caddy-Image, mounten Sie Ihr Caddyfile und halten Sie das caddy_data-Volume persistent, damit Zertifikate nicht bei jedem Neustart erneut angefordert werden. Referenzieren Sie Apps über ihren Compose-Dienstnamen statt über localhost.

Muss ich irgendwelche Ports öffnen? Caddy benötigt die Ports 80 und 443 aus dem Internet erreichbar, um öffentliche Zertifikate auszustellen und Datenverkehr zu bedienen. Wenn Sie keine eingehenden Ports öffnen können, verwenden Sie stattdessen einen Cloudflare Tunnel, der über eine ausgehende Verbindung funktioniert.

Quellen

• Caddy — Reverse-Proxy-Schnellstart: offizielles minimales Caddyfile, die einzeilige Befehlsform und wie automatisches HTTPS die Ports 80/443 nutzt.
• Caddy — Installationsdokumentation: aktuelle Debian/Ubuntu-apt-Befehle und das offizielle Docker-Image.
• Caddy — GitHub-Releases: 2.11.4 stabil (Juni 2026), der automatische Upstream-Host-Header für HTTPS-Upstreams seit 2.11 und die Fixes für CVE-2026-27590 / 27589 (2.11.1).
• XDA — Caddy ist mein neuer Lieblings-Reverse-Proxy: Einschätzung eines Dritten zur Leichtigkeit, mit der Caddy SSL für selbst gehostete Apps bereitstellt.
• Traefik-Dokumentation: label-gesteuerter, sich selbst erkennender Reverse Proxy für dynamische Docker/Kubernetes-Flotten.