Caddy einrichten: Reverse Proxy mit automatischem HTTPS

Wer Dienste im Heimnetz oder auf einem kleinen Server betreibt, kennt das Muster: Ein Dienst läuft intern auf einem Port, etwa Home Assistant auf 8123 oder eine Webanwendung auf 9000. Soll er von außen erreichbar sein, braucht es einen Reverse Proxy und ein gültiges TLS-Zertifikat, sonst warnt der Browser. Mit nginx oder Apache heißt das üblicherweise zwei Baustellen: den Server konfigurieren und daneben ein ACME-Werkzeug wie Certbot betreiben, das die Zertifikate beschafft und erneuert.

Titelbild: Bildquelle: caddyserver/caddy

Bei Caddy entfällt die zweite Baustelle. Der Webserver richtet HTTPS von sich aus ein, beschafft Zertifikate automatisch und hält sie erneuert 1, 2. Die kurze Antwort auf die Frage dieses Artikels: Du installierst Caddy, schreibst eine Caddyfile mit wenigen Zeilen, und Caddy übernimmt Zertifikat, Erneuerung und die Weiterleitung von HTTP auf HTTPS selbst. In diesem Artikel zeige ich diese Schritte konkret, erkläre, was dabei im Hintergrund passiert, und behandle die Fehler, die in der Praxis am häufigsten auftreten.

Alle Befehle und Konfigurationszeilen stammen aus der offiziellen Dokumentation; die Zahlen in eckigen Klammern verweisen auf die Quellen am Ende. Ich beschreibe keine Benchmarks und keine Funktionen, die ich nicht in den Quellen geprüft habe.

Kurzantwort

So richtest du den Go-Webserver Caddy als Reverse Proxy ein: Installation, Caddyfile, automatische HTTPS-Zertifikate und die häufigsten Fehler. Kurz gesagt: Caddy Reverse Proxy einrichten ist vor allem dann relevant, wenn du schnell verstehen willst, was konkret dahinter steckt, welche Grenzen es gibt und welche Entscheidung daraus folgt. Die Details, Quellen und Einschränkungen stehen in den folgenden Abschnitten.

Was Caddy anders macht

Caddy ist ein in Go geschriebener Webserver und Reverse Proxy, dessen auffälligstes Merkmal das automatische HTTPS ist. Das Projekt beschreibt sich selbst mit dem Satz „Every site on HTTPS“ und dem Grundsatz, TLS standardmäßig zu verwenden 1. Nach eigener Darstellung war Caddy der erste Webserver, der HTTPS automatisch und standardmäßig einsetzt 1, 2.

Die Funktionen sind in einer modularen Architektur gebündelt. Die Konfiguration erfolgt wahlweise über die Caddyfile, ein bewusst einfaches Textformat, oder über die native JSON-Konfiguration. Daneben gibt es Adapter, die andere Formate wie YAML, TOML oder sogar nginx-Konfigurationen in die JSON-Struktur übersetzen 1. Standardmäßig werden HTTP/1.1, HTTP/2 und HTTP/3 unterstützt 1. Fast die gesamte Konfiguration steckt in einem einzigen Dokument, statt über CLI-Flags, Umgebungsvariablen und eine Datei verstreut zu sein; Änderungen lassen sich ohne Unterbrechung zur Laufzeit über die API einspielen 1.

Zwei technische Eigenschaften trennen Caddy von den großen Servern der C-Klasse. Erstens ist es als Go-Programm in einer Sprache mit Speichersicherheitsgarantien geschrieben, was nach Einschätzung der Electronic Frontier Foundation eine ganze Klasse typischer Sicherheitslücken ausschließt, die bei in C geschriebenen Servern wie Apache und nginx auftreten 5. Zweitens kommt Caddy als einzelne statische Binärdatei ohne externe Laufzeitabhängigkeiten aus, laut Projekt sogar ohne libc 1.

Die Lizenz ist Apache-2.0, das Projekt ist Teil von ZeroSSL 1, 6. Eine Eigenheit, die beim Schreiben über Caddy zählt: Der Name ist „Caddy“, nicht „Caddy Server“ oder „CaddyServer“, und „Caddy“ ist eine eingetragene Marke von Stack Holdings GmbH 1.

Caddy Reverse Proxy einrichten – Illustration 2

Bildquelle: github.com

Installation

Der einfachste, plattformübergreifende Weg ist eine statische Binärdatei aus den GitHub-Releases, die in ein Verzeichnis aus dem PATH gelegt wird 1, 3. Für produktive Systeme empfiehlt das Projekt die offiziellen Pakete der Distribution, die Caddy als systemd-Dienst mit dem Namen caddy einrichten und starten 3.

Auf Debian, Ubuntu oder Raspbian sind das diese Schritte 3:

sudo apt install --yes 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 chmod o+r /usr/share/keyrings/caddy-stable-archive-keyring.gpg
sudo chmod o+r /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install caddy

Der letzte Befehl installiert Caddy und startet den Dienst direkt. Auf Fedora oder RHEL/CentOS läuft es über das COPR-Repository @caddy/caddy mit dnf install caddy, auf Arch mit pacman -Syu caddy 3. Wer Container bevorzugt, zieht das offizielle Image mit docker pull caddy 3.

Nach der Installation lässt sich die Version prüfen und bestätigen, dass Caddy im PATH liegt:

caddy version
caddy list-modules

Der zweite Befehl listet die eingebauten Module auf; er ist eine schnelle Kontrolle, ob die Binärdatei die erwarteten Komponenten mitbringt 1. Bei einer statischen Binärdatei vereinfacht caddy upgrade den späteren Versionswechsel; bei den offiziellen Paketen übernimmt ihn der Paketmanager 3.

Bildquelle: github.com

Der erste Reverse Proxy

Für einen schnellen Test ohne Konfigurationsdatei genügt der eingebaute Befehl. Er leitet einen Port auf einen dahinter liegenden Dienst weiter, etwa von Port 2080 auf einen Prozess auf Port 9000 4:

caddy reverse-proxy --from :2080 --to :9000

Anschließend lässt sich der Proxy mit curl -v 127.0.0.1:2080 ansprechen 4. Der reverse-proxy-Befehl ist für schnelle Einrichtungen gedacht, nicht als Ersatz für eine saubere Konfiguration.

Für alles Dauerhafte ist die Caddyfile der übliche Weg. Sie besteht aus der Adresse der Seite und den darunter gesetzten Anweisungen. Das ist ein produktionsfähiger Reverse Proxy für eine öffentliche Domain 4:

example.com
reverse_proxy :9000

Diese zwei Zeilen reichen für automatisches HTTPS, sofern die Voraussetzungen stimmen. Caddy bemerkt den Hostnamen example.com, beschafft ein öffentlich vertrauenswürdiges Zertifikat und leitet HTTP auf HTTPS um 2, 4. Der Dienst auf Port 9000 muss dafür nur auf der Maschine laufen und erreichbar sein. Leitet Caddy auf ein anderes Ziel als den aufrufenden Hostnamen weiter und soll die Verbindung zum Backend ebenfalls über HTTPS laufen, muss der Host-Header auf das Ziel umgestellt werden, damit er zum TLS-Server-Name des Backends passt und der TLS-Handschlag gelingt. Beim Kommandozeilen-Befehl caddy reverse-proxy geschieht das mit dem Flag --change-host-header; in der Caddyfile setzt man dafür die Option header_up Host {upstream_hostport} 4. Seit Caddy v2.11 übernimmt Caddy das automatisch.

Für eine statische Website, die Caddy direkt ausliefert, lautet das Gegenstück 1:

example.com {
    root * /var/www/site
    encode zstd gzip
    file_server
}

root legt das Verzeichnis fest, encode aktiviert die Komprimierung, file_server liefert die Dateien aus. Ändert sich die Caddyfile, wird die Konfiguration mit caddy reload neu geladen; bei dem aus den Paketen installierten Dienst geschieht das auch über systemctl reload caddy 3.

Wie das automatische HTTPS funktioniert

Das Versprechen klingt größer, als die Mechanik dahinter ist, und genau das macht es verständlich. Zwei Fälle sind zu unterscheiden 2.

Für öffentliche Domainnamen nutzt Caddy das ACME-Protokoll und beantragt Zertifikate bei einer öffentlichen Zertifizierungsstelle, standardmäßig Let’s Encrypt oder ZeroSSL 2. Dazu muss die Zertifizierungsstelle prüfen, dass der Antragsteller die Domain kontrolliert. Caddy unterstützt dafür drei Challenge-Typen: die HTTP-Challenge über Port 80, bei der ein temporärer Wert über HTTP abgefragt wird, die TLS-ALPN-Challenge über Port 443 und die DNS-Challenge, bei der ein TXT-Eintrag gesetzt wird. Die ersten beiden sind standardmäßig aktiv; die DNS-Challenge braucht Zugangsdaten zum DNS-Anbieter und wird erst durch Konfiguration aktiviert 2. Zwei dokumentierte Erweiterungen gehen über den Standard hinaus: On-Demand-TLS beschafft ein Zertifikat erst beim ersten Handschlag, der es verlangt, statt es beim Laden der Konfiguration zu beantragen, was sich lohnt, wenn die Domainnamen nicht von vornherein feststehen. Und mehrere Caddy-Instanzen, die denselben Speicher teilen, gelten als Cluster und koordinieren sich automatisch, mit Fallback zwischen mehreren Zertifizierungsstellen 1, 2.

Für interne Hostnamen und IP-Adressen, etwa localhost oder 127.0.0.1, erzeugt Caddy eine eigene lokale Zertifizierungsstelle und signiert damit Zertifikate. Die Wurzel wird beim ersten Mal in den Vertrauensspeicher des Systems installiert, wofür Caddy unter Umständen nach einem Passwort fragt. Dieses lokale HTTPS nutzt kein ACME und keine DNS-Validierung, es gilt nur auf der Maschine selbst und nur dort, wo das Wurzelzertifikat vertraut ist 2.

Die automatische Aktivierung hängt an einer einfachen Bedingung: Caddy aktiviert das automatische HTTPS, sobald es einen Hostnamen oder eine IP-Adresse kennt, die es bedient. Kennt es keinen, bleibt es bei HTTP. Ausdrücklich deaktivieren lässt sich das Ganze, etwa indem der Site-Adresse in der Caddyfile ein http:// vorangestellt wird 2.

Für einen öffentlichen Namen müssen mehrere Dinge zusammenkommen: Der A- beziehungsweise AAAA-Eintrag der Domain zeigt auf den Server, die Ports 80 und 443 sind von außen erreichbar, Caddy kann an diese Ports binden oder sie werden dorthin weitergeleitet, und das Datenverzeichnis ist beschreibbar und dauerhaft 2. Fehlt einer dieser Punkte, schlägt die Zertifikatsausstellung fehl. Das ist keine Caddy-Eigenheit, sondern dieselbe Voraussetzung wie bei jedem ACME-Werkzeug; der Unterschied ist nur, dass Caddy sie stillschweigend voraussetzt.

Prüfen, ob es funktioniert

Der wichtigste Test ist, die Seite von außen oder über einen zweiten Rechner abzurufen, nicht nur vom Server selbst. curl -v https://example.com zeigt in der Ausgabe, ob das Zertifikat gültig ist und von welcher Stelle es stammt 4. Im Browser genügt ein Blick auf das Schloss-Symbol: Ein öffentlich vertrauenswürdiges Zertifikat erzeugt keine Warnung, ein lokales Caddy-Zertifikat warnt auf jedem Gerät, das Caddys Wurzelzertifikat nicht kennt 2.

Vor dem ersten scharfen Versuch lohnt ein Umweg über die Testumgebung. Wer seine Konfiguration gegen den Produktiv-Endpunkt testet, kann in Ratenlimits der Zertifizierungsstelle laufen, die den Zugriff auf HTTPS bis zu einer Woche blockieren. Die Dokumentation empfiehlt deshalb, für Tests die Staging-URL von Let’s Encrypt zu verwenden, die denselben Ratenlimits nicht unterliegt 2:

https://acme-staging-v02.api.letsencrypt.org/directory

Für lokale Dienste ist der Nachweis, dass das interne HTTPS steht, ein Abruf wie curl -v https://localhost 4. Erscheint dabei eine Warnung über ein nicht vertrauenswürdiges Zertifikat, fehlt lediglich das installierte Wurzelzertifikat; der Dienst selbst läuft bereits über TLS.

Den Zustand der Zertifikate und ihrer Erneuerung prüft man über die Verwaltungs-API beziehungsweise das Log. Caddy erneuert verwaltete Zertifikate automatisch, solange der Prozess läuft 2. Ein Neustart des Dienstes nach Änderungen an der Caddyfile sollte nicht nötig sein; reload genügt 3.

Typische Fehler und ihre Behebung

Der häufigste Fehler ist ein fehlgeschlagener Handshake bei einem öffentlichen Namen, obwohl die Caddyfile stimmt. Die Ursache liegt fast immer in einer der oben genannten Voraussetzungen: Der DNS-Eintrag zeigt noch auf die alte Adresse, oder Port 80 beziehungsweise 443 ist am Router nicht weitergeleitet. Die HTTP-Challenge läuft über Port 80, die TLS-ALPN-Challenge über Port 443; ist keiner von beiden erreichbar, kann keine Zertifizierungsstelle die Kontrolle bestätigen 2. Die Prüfung ist konkret: dig example.com für den DNS-Eintrag und ein Port-Test von außen für die Weiterleitung. Als erster Blick lohnt daneben das Log des Dienstes: Da das Debian-Paket Caddy als systemd-Dienst caddy betreibt, zeigt journalctl -u caddy die Meldungen der Zertifikatsausstellung samt ACME-Fehlermeldung der Zertifizierungsstelle im Klartext 3.

Der zweite häufige Fall ist das lokale Zertifikat, das auf dem eigenen Rechner eine Warnung erzeugt. Das ist kein Fehler, sondern das erwartete Verhalten interner Namen 2. Abhilfe schafft caddy trust, das die Installation des Wurzelzertifikats als privilegierter Nutzer nachholt, wenn sie beim ersten Start ohne Rechte gescheitert ist 2.

Der dritte Fall betrifft die Ports. Auf Linux braucht ein Prozess erhöhte Rechte, um an Port 80 und 443 zu binden. Statt Caddy als Root laufen zu lassen, setzt man gezielt die Fähigkeit 1, 4:

sudo setcap cap_net_bind_service=+ep $(which caddy)

Damit darf Caddy an niedrige Ports binden, ohne vollständige Root-Rechte zu besitzen. Für einen schnellen Test ohne diese Rechte lässt sich stattdessen ein hoher Port wie 8443 verwenden 4.

Der vierte Fall ist das versehentlich deaktivierte HTTPS. Steht in der Caddyfile ein http:// vor der Adresse oder fehlt der Hostname ganz, bleibt Caddy bei HTTP 2. Wer sich wundert, warum kein Zertifikat auftaucht, sollte zuerst die Adresszeile der Caddyfile lesen, nicht die Netzwerkkonfiguration.

Wann Caddy die richtige Wahl ist

Die Entscheidung für oder gegen Caddy lässt sich an zwei Fragen festmachen, für die es belastbare Einordnung gibt.

Die erste Frage: Wie wichtig ist dir, dass HTTPS von Anfang an eingebaut ist statt nachgerüstet? Die Electronic Frontier Foundation, die mit Certbot selbst das bekannteste Nachrüst-Werkzeug entwickelt, beschreibt genau diesen Unterschied. Certbot muss als externes Werkzeug die Konfiguration von Apache oder nginx nachträglich lesen und verändern, und dabei entstehen die bekannten Reibungen, wenn das Werkzeug die Konfiguration anders versteht als der Server, den es anpasst. Caddy implementiert ACME intern und aktiviert HTTPS standardmäßig, was diesen Zwischenschritt und seine Fehlerquellen entfallen lässt. Die EFF hält es deshalb für plausibel, dass Werkzeuge wie Caddy Certbot für einen Teil der Nutzer vollständig ersetzen, betont aber ausdrücklich, dass kein Ansatz für jeden passt 5.

Die zweite Frage: Wie viel Aufwand ist dir die Einarbeitung wert, und passt die Konfigurationssprache zu dir? Eine Besprechung bei Ars Technica aus der Einführung von Caddy 2 hält die Konfigurationssyntax für einfacher als die des Apache-Webservers, weist aber darauf hin, dass das Format der Version 2 mit dem der Vorgängerversion weitgehend inkompatibel ist 6. Wer von Caddy 1 migriert, migriert die Konfiguration also wirklich, nicht nur die Binärdatei.

Dazu kommt ein nüchterner Datenpunkt zur Verbreitung: Nach Erhebung von W3Techs liefen im März 2026 rund 0,2 Prozent der untersuchten Websites mit Caddy 6. Das ist ein kleiner Anteil gegenüber nginx und Apache. Für die eigene Entscheidung heißt das zweierlei: Die Dokumentation ist gut, die Gemeinschaft aber kleiner, und wer sich an Foren und Beispielen anderer orientiert, findet zu Caddy weniger Material als zu den Platzhirschen.

In der Praxis spricht für Caddy, wer einen einzelnen Dienst oder wenige Dienste hinter HTTPS legen will und dafür keine separate Zertifikats-Infrastruktur pflegen möchte. Dagegen spricht es, wenn ein Team bereits auf nginx-Konfigurationen und -Wissen aufgebaut hat oder wenn es zwingend ein Ökosystem braucht, in dem jede Frage schon hundertfach beantwortet ist.

Grenzen und offene Punkte

Was Caddy nicht ersetzt, ist die Vorarbeit am Netzwerk. Ein DNS-Eintrag, der nicht stimmt, und weitergeleitete Ports, die nicht ankommen, machen auch das automatische HTTPS wirkungslos 2. Wer das erwartet, hält das automatische HTTPS für einen Fehler im Werkzeug, wo es eine fehlende Voraussetzung ist.

Auch die lokale Variante hat eine klare Grenze: Das interne HTTPS für localhost und interne Namen vertraut nur die Maschine, die das Wurzelzertifikat kennt 2. Es ist ein Komfort für Entwicklung und Tests, kein Ersatz für öffentlich vertrauenswürdige Zertifikate auf einem Gerät, das andere erreichen sollen.

Die DNS-Challenge wiederum, die für Wildcard-Zertifikate oder interne Namen ohne offene Ports nötig ist, verlangt Zugangsdaten zum DNS-Anbieter und dessen Unterstützung durch ein passendes Plugin; sie ist eine bewusste Zusatzkonfiguration und nicht der Standardweg 2.

Zuletzt ein Punkt zur Projektlage, der sich jederzeit ändern kann: Die Angaben zu Funktionen, zur Marke und zur Trägerschaft stammen aus dem README des Repositorys zum Zeitpunkt dieses Artikels 1. Wer darauf Entscheidungen stützt, prüft die aktuelle Dokumentation unter caddyserver.com/docs, bevor er in Produktion geht.

Weiterführende Artikel

Passende Produktrecherchen

Wenn du die praktische Seite vertiefen möchtest: Diese konkreten Produkte passen zum Thema dieses Artikels. Es ist keine Rangliste und keine Kaufpflicht, sondern eine kurze Auswahl mit Begründung, für wen sie interessant sein kann:

Raspberry Pi 5 mit 8 GB und Netzteil – für Einsteiger, die einen dedizierten kleinen Server aufbauen möchten – als kompakter, sparsamer Host für Caddy und einzelne Dienste im Heimnetz
Raspberry Pi 5 mit NVMe-Kit und aktivem Kühler – für Homelabs mit mehreren lokalen Diensten und höherem Speicherbedarf – für einen Caddy-Host mit schnellem lokalem Speicher und aufgeräumtem Dauerbetrieb

Hinweis: Als Amazon-Partner verdient kalika.de an qualifizierten Verkäufen. Für dich ändert sich der Preis nicht.

Wenn du Alternativen für deinen Internetzugang vergleichen möchtest:

Starlink-Verfügbarkeit und Konditionen prüfen

Hinweis: Dieser Link ist ein Starlink-Empfehlungslink. Wenn du darüber bestellst, können für dich und kalika.de Vorteile nach den jeweils geltenden Starlink-Bedingungen entstehen.

Bildquelle: caddyserver.com

Entscheidungshilfe: Wann ist das sinnvoll?

Eher sinnvoll, wenn du Caddy Reverse Proxy einrichten nicht nur als Nachricht lesen willst, sondern eine praktische Einordnung brauchst: Was ändert sich, wen betrifft es und welche nächsten Schritte sind realistisch?

Eher abwarten, wenn die Quellenlage noch dünn ist, wichtige technische Details fehlen oder der Nutzen nur aus Hersteller- oder Projektversprechen besteht. Dann ist Beobachten besser als vorschnelles Umstellen.

Worauf du achten solltest: konkrete Verfügbarkeit, nachvollziehbare Kosten, offene Einschränkungen, Sicherheits- oder Datenschutzfolgen und belastbare Quellen statt bloßer Ankündigungen.

Caddy Reverse Proxy einrichten – Illustration 3

Bildquelle: caddyserver.com

Transparenzhinweis

Dieser Beitrag wurde mit Unterstützung künstlicher Intelligenz erstellt und automatisiert auf Quellen, Fakten und Qualitätskriterien geprüft.

Quellen

[1] Caddy – README (caddyserver/caddy auf GitHub)

[2] Automatic HTTPS – Caddy Documentation

[3] Install – Caddy Documentation

[4] Reverse proxy quick-start – Caddy Documentation

[5] Should Caddy and Traefik Replace Certbot? – Electronic Frontier Foundation (Brad Warren)

[6] Caddy (web server) – Wikipedia