Caddy: Reverse Proxy mit automatischem HTTPS

Caddy ist ein moderner Webserver und Reverse-Proxy, der eine Sache anders macht als alle Etablierten: HTTPS ist Standard, nicht Add-on. Wer Caddy installiert und in der Config eine Domain einträgt, bekommt automatisch ein Let’s-Encrypt-Zertifikat — ohne certbot, ohne Renew-Cronjob, ohne Nachfragen.

Bei DATAZONE setzen wir Caddy seit einiger Zeit für kleine bis mittlere Reverse-Proxy-Aufgaben ein — überall dort, wo Nginx mit certbot mehr Ceremonie wäre als Mehrwert. Dieser Artikel zeigt das Setup, drei konkrete Beispiele und die Grenzen, an denen Nginx wieder die bessere Wahl ist.

Was Caddy anders macht

Caddy ist in Go geschrieben, statisch gelinkt, ein einzelnes Binary. Es kommt mit einer eigenen Config-Sprache namens Caddyfile — bewusst minimalistisch, deklarativ, ohne der Komplexität eines Nginx- oder Apache-Configs.

Der entscheidende Unterschied:

Aspekt	Caddy	Nginx + certbot
HTTPS-Setup	Automatisch	certbot/acme.sh, Renew-Cron
Config-Syntax	Caddyfile (deklarativ)	nginx.conf (imperative Blöcke)
Default-Verhalten	HTTPS überall	HTTP außer explizit konfiguriert
HTTP/3 / QUIC	Out of the box	ngx_quic-Module, Build-Aufwand
TLS-Schlüsselmaterial	In /var/lib/caddy	In /etc/letsencrypt
Hot-Reload	caddy reload	nginx -s reload
Plugin-Modell	Build-Time (xcaddy)	Dynamic Modules

Wer aus der Nginx-Welt kommt, vermisst bei Caddy zwei Dinge: Kernel-mode-Optimierungen und die schiere Performance unter extremen Lastspitzen. Für 95 % aller Self-Hosted-Use-Cases ist das egal — Caddy hält locker zehntausende Requests pro Sekunde.

Installation

Auf Debian/Ubuntu via Cloudsmith-Repo (offizielle Variante):

sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl
curl -fsSL https://dl.cloudsmith.io/public/caddy/stable/gpg.key \
  | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -fsSL 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 -y caddy

Caddy startet danach als caddy.service mit Config-Datei /etc/caddy/Caddyfile. Die Standard-Konfiguration ist ein einfacher HTTP-Server auf Port 80. Wir ersetzen sie gleich durch unsere eigene.

Auf TrueNAS, in einem LXC-Container oder als Docker:

docker run -d \
  --name caddy \
  --network host \
  -v /etc/caddy/Caddyfile:/etc/caddy/Caddyfile \
  -v caddy_data:/data \
  -v caddy_config:/config \
  caddy:latest

Das erste Caddyfile: Reverse-Proxy auf einen Backend-Dienst

nextcloud.example.com {
    reverse_proxy 192.168.1.20:8080
}

Das ist die komplette Konfiguration. Was passiert beim Start:

1. Caddy fragt bei Let’s Encrypt ein Zertifikat für nextcloud.example.com an (per HTTP-01-Challenge auf Port 80)
2. Caddy lauscht auf Port 443 mit dem Zertifikat
3. Eingehende Requests werden an 192.168.1.20:8080 weitergegeben
4. HTTP-Anfragen auf Port 80 werden automatisch auf HTTPS umgeleitet
5. Bei Cert-Ablauf in ~90 Tagen erneuert Caddy automatisch im Hintergrund

Vergleich Nginx + certbot: Dasselbe Resultat braucht eine Server-Block-Definition mit listen 80-Redirect, eine zweite mit listen 443 ssl, einen proxy_pass-Block, einen certbot --nginx-Aufruf, und einen Cron-Job für Renewals. Insgesamt 30–50 Zeilen Config plus zwei Tools, die zusammenarbeiten müssen.

Beispiel 1: Drei Self-Hosted-Dienste hinter einer öffentlichen IP

Realistisches Szenario: Eine kleine Firma betreibt Nextcloud, Mailcow (Mailserver mit Webmail) und Vaultwarden (Passwort-Manager) auf drei verschiedenen Backend-Hosts, alle hinter einer öffentlichen IP. Caddy soll als zentraler Reverse-Proxy fungieren.

# /etc/caddy/Caddyfile

# Nextcloud
cloud.example.com {
    reverse_proxy 192.168.1.20:8080

    # Caldav/Carddav redirects
    redir /.well-known/carddav /remote.php/dav 301
    redir /.well-known/caldav /remote.php/dav 301

    # Größere Uploads erlauben
    request_body {
        max_size 10GB
    }

    # Sicherheits-Header
    header {
        Strict-Transport-Security "max-age=31536000; includeSubDomains"
        X-Content-Type-Options "nosniff"
        Referrer-Policy "no-referrer"
    }
}

# Mailcow
mail.example.com {
    reverse_proxy 192.168.1.21:8443 {
        transport http {
            tls
            tls_insecure_skip_verify
        }
    }
}

# Vaultwarden
vault.example.com {
    reverse_proxy 192.168.1.22:8000

    # WebSocket für Live-Sync
    reverse_proxy /notifications/hub 192.168.1.22:3012

    header {
        Strict-Transport-Security "max-age=31536000; includeSubDomains"
    }
}

Drei Domains, drei Backends, ein zentraler TLS-Endpunkt. Das ist die komplette Konfiguration für ein Setup, das mit Nginx ca. 80–120 Zeilen kosten würde — und manuelle Cert-Verwaltung mit certbot.

Beispiel 2: TLS mit DNS-01-Challenge

Wenn Port 80 nicht von außen erreichbar ist (z.B. interne Dienste hinter einer Firewall, die nur 443 freigibt), reicht die HTTP-01-Challenge nicht. Stattdessen funktioniert die DNS-01-Challenge, bei der Caddy einen TXT-Eintrag in der DNS-Zone setzt.

Das funktioniert mit den großen DNS-Providern (Cloudflare, AWS Route 53, DigitalOcean, Hetzner DNS, deSEC, Gandi etc.). Für Cloudflare sieht das so aus:

{
    acme_dns cloudflare YOUR_CLOUDFLARE_API_TOKEN
}

intranet.example.com {
    reverse_proxy 192.168.1.30:8080
}

monitoring.example.com {
    reverse_proxy 192.168.1.31:3000
}

Für DNS-01 braucht Caddy ein DNS-Provider-Plugin. Das offizielle Standard-Caddy hat es nicht eingebaut — man baut sich entweder eine eigene Variante mit xcaddy oder lädt eine vorgefertigte Variante von der Caddy-Download-Seite, bei der man DNS-Provider per Webfront auswählt.

Beispiel 3: Lokales Self-Signed-Setup ohne Internet

Caddy hat einen eingebauten internen CA-Modus für Lab- und Test-Setups, in denen keine öffentliche Domain existiert. Mit tls internal erzeugt Caddy eine eigene Mini-CA und stellt darüber Zertifikate aus:

{
    local_certs
}

dev.lab {
    tls internal
    reverse_proxy 127.0.0.1:8080
}

Browser zeigen das natürlich als nicht-vertrauenswürdig an — für Test- und Entwicklungsumgebungen ist das aber genau richtig, weil keine externe CA-Anfrage ausgelöst wird und das Setup auch offline funktioniert.

Sicherheits-Defaults — und ihre Grenzen

Caddy aktiviert standardmäßig:

• TLS 1.2 und 1.3, kein SSLv3/TLS 1.0/1.1
• Moderne Cipher-Suiten mit Forward Secrecy
• HTTP/2 und seit v2.6 HTTP/3 / QUIC out of the box
• OCSP-Stapling automatisch

Das deckt das ab, was 90 % aller Reverse-Proxy-Aufgaben brauchen. Für strengere Anforderungen (PCI-DSS, BSI-Grundschutz mit konkreten Cipher-Listen) lässt sich das per tls-Direktive überschreiben:

example.com {
    tls {
        protocols tls1.3
        ciphers TLS_AES_256_GCM_SHA384 TLS_AES_128_GCM_SHA256
    }
    reverse_proxy 192.168.1.20:8080
}

Was Caddy nicht mitbringt:

• WAF-Funktionalität (ModSecurity-Niveau) — dafür braucht es eine separate WAF davor oder Caddys coraza-Plugin
• Brute-Force-Schutz — Fail2ban auf dem Caddy-Host als Ergänzung
• Rate-Limiting nach IP — eingebaut nur in begrenztem Umfang, Plugin-Module ergänzen das
• Application-Aware-Inspection — auf Layer 7 prüft Caddy nur Routing, nicht Anwendungs-Semantik

Für höhere Anforderungen ergänzen wir bei DATAZONE typischerweise eine OPNsense mit Suricata davor — Caddy macht TLS und Routing, OPNsense macht die Paket-Inspektion.

Performance: Wo Caddy gut ist — und wo nicht

Caddy ist nicht der schnellste Webserver der Welt. Aber er ist schnell genug für alles unterhalb von “hundertausende Requests pro Sekunde aus einer einzigen Instanz”.

Für eine 4-Core-VM auf Proxmox haben wir typische Werte (TLS-terminiert, kleine Static-Files):

• HTTP/2: ~10.000–30.000 req/s
• HTTP/3: vergleichbar, manchmal etwas langsamer wegen QUIC-Overhead
• Reverse-Proxy auf Backend: meist durch Backend-Latenz limitiert, nicht durch Caddy

Wer mehr braucht — z.B. einen CDN-Edge mit massiv parallelen TLS-Sessions — sollte Nginx mit kernel-mode TLS oder HAProxy einsetzen. Für Self-Hosted KMU-Workloads ist Caddy nahezu immer ausreichend.

Tipps aus dem Alltag

Logs strukturiert in JSON

{
    log default {
        output file /var/log/caddy/access.log
        format json
    }
}

Damit lassen sich Logs nach Vector/Loki/Elasticsearch piepen, ohne nginx-Logparser-Akrobatik.

API-Backend mit gRPC

api.example.com {
    reverse_proxy h2c://192.168.1.40:50051
}

Caddy spricht HTTP/2 ohne TLS (h2c) gegen Backend-Services — wichtig für gRPC.

Wildcard-Zertifikat statt N Subdomains

*.intern.example.com {
    tls {
        dns cloudflare YOUR_TOKEN
    }

    @nextcloud host nextcloud.intern.example.com
    handle @nextcloud {
        reverse_proxy 192.168.1.20:8080
    }

    @vault host vault.intern.example.com
    handle @vault {
        reverse_proxy 192.168.1.22:8000
    }
}

Ein Zertifikat deckt alle Subdomains ab, was bei vielen Diensten Rate-Limits bei Let’s Encrypt umgeht.

Maintenance-Mode pro Domain

example.com {
    @maintenance file /var/www/maintenance/enabled
    handle @maintenance {
        respond "Wartungsfenster aktiv. Bitte später wiederkommen." 503
    }
    reverse_proxy 192.168.1.20:8080
}

touch /var/www/maintenance/enabled aktiviert den Maintenance-Mode, rm deaktiviert ihn.

Wann Nginx noch die bessere Wahl ist

Es gibt Szenarien, in denen wir Nginx weiter empfehlen:

• Extrem hohe Performance (CDN-Edge, > 50.000 req/s pro Node)
• Statisches Serving mit Kernel-mode sendfile — Nginx-Stärke seit Jahren
• Existing Stack mit Nginx-Knowhow — keine Migration ohne Mehrwert
• Ingress-Controller in Kubernetes — Nginx-Ingress hat größere Community

Für fast alles andere — Self-Hosted, kleine bis mittlere Anwendungen, schnelle Aufgaben — ist Caddy unsere erste Wahl, weil die Config-Größe und die HTTPS-Automatik operative Zeit sparen, die bei Nginx in certbot-Renew-Skripten verschwindet.

Verwandte DATAZONE-Artikel

• Nginx Reverse Proxy: Dienste sicher veröffentlichen
• Let’s Encrypt: ACME-Zertifikate automatisieren
• Linux Server Hardening
• Vaultwarden: Self-Hosted Passwort-Manager

Fazit

Caddy ist nicht der schnellste, nicht der konfigurierbarste, nicht der meistverbreitete Reverse-Proxy. Aber er ist der unkomplizierteste, wenn HTTPS-Automation, kurze Configs und ein einzelnes Binary die Prioritäten sind. Für eine Self-Hosted-Welt mit drei bis dreißig Diensten hinter einer öffentlichen IP ist Caddy unsere Standard-Empfehlung — gerade dort, wo nicht ständig jemand am Reverse-Proxy schraubt, sondern wo “läuft seit Jahren” das Ziel ist.

Quellen

• Caddy: offizielle Dokumentation
• Caddyfile-Syntax-Referenz
• Caddy auf GitHub
• xcaddy: Custom Builds mit DNS-Plugins
• Caddy-Forum: praktische Anwendungsbeispiele