Caddy Reverse Proxy einrichten: HTTPS ohne Certbot

Wer mehr als einen Dienst selbst betreibt, steht irgendwann vor derselben Wand: Nextcloud, Vaultwarden und Immich wollen alle Port 443, und den gibt es pro IP-Adresse nur einmal. Ein Caddy Reverse Proxy nimmt sämtliche Anfragen auf den Ports 80 und 443 entgegen, entscheidet anhand des angefragten Hostnamens, welcher Dienst gemeint ist, und reicht die Anfrage intern weiter — an einen Dienst, der selbst nie mit dem Internet spricht.

Der Unterschied zu einem gewöhnlichen Proxy liegt in der Richtung. Ein normaler Proxy steht vor euch und schützt euch gegenüber dem Server. Ein Reverse Proxy steht vor den Servern und nimmt ihnen die Aussenwelt ab. Für den Browser existiert nur eine einzige Adresse, ein einziges Zertifikat, ein einziger Einstiegspunkt. Was dahinter läuft, auf welchem Port, in welchem Container, auf welchem Rechner im lokalen Netz — davon bekommt der Client nichts mit.

Der naheliegende Gegenvorschlag lautet: einfach jedem Dienst einen eigenen Port geben und die Sache über example.ch:8080 ansprechen. Das funktioniert, bis ihr das erste Mal aus einem fremden WLAN, einem Firmennetz oder einem Hotelnetzwerk zugreifen wollt. Dort ist alles ausser 80 und 443 üblicherweise dicht. Dazu kommt, dass jedes dieser Ziele ein eigenes gültiges Zertifikat braucht und jeder Dienst seine TLS-Konfiguration selbst pflegen müsste — mit dem Ergebnis, dass drei Programme drei verschiedene Meinungen darüber haben, welche Cipher noch in Ordnung sind.

Genau an dieser Stelle setzt dieser Artikel an: eine vollständige Einrichtung von Caddy als Reverse Proxy unter Debian und Ubuntu, von der Installation über die erste Caddyfile bis zu Wildcard-Zertifikaten per DNS-Challenge. Wer bisher mit Apache und Certbot gearbeitet hat, findet den vertrauten Weg in unserer Anleitung zum SSL-Zertifikat für den Nextcloud-Homeserver. Hier geht es um den Weg, bei dem dieser Schritt schlicht entfällt.

Warum Caddy und nicht nginx

Caddy ist ein in Go geschriebener Webserver, der unter der Apache-2.0-Lizenz steht und ohne externe Abhängigkeiten auskommt. Die aktuelle stabile Version ist v2.11.4 vom 3. Juni 2026. Das Alleinstellungsmerkmal steht im Untertitel des Projekts und ist keine Marketingfloskel: automatisches HTTPS, und zwar als Standardverhalten, nicht als Zusatzpaket.

Automatisches HTTPS ist eingebaut, nicht angeflanscht

Bei nginx oder Apache läuft die Zertifikatsbeschaffung über ein zweites Programm. Certbot legt Dateien ab, schreibt in die Konfiguration hinein, richtet einen Timer ein und startet den Webserver neu. Vier bewegliche Teile, die alle einzeln kaputtgehen können. Caddy spricht ACME selbst. Es erkennt aus der Konfiguration, für welche Hostnamen es Zertifikate braucht, holt sie, erneuert sie und leitet HTTP auf HTTPS um — ohne dass ihr das irgendwo hinschreibt.

Wie gross der Unterschied im Alltag ist, zeigt das Projekt Immich selbst. In der offiziellen Reverse-Proxy-Dokumentation steht eine nginx-Konfiguration mit erhöhtem Upload-Limit, abgeschaltetem Request-Buffering, gesetzten Weiterleitungs-Headern und Timeouts von 600 Sekunden. Direkt darunter steht die Caddy-Variante, vollständig:

immich.example.org {
    reverse_proxy http://127.0.0.1:2283
}

Das ist kein verkürztes Beispiel. Die drei Dinge, die nginx dort von Hand braucht, sind in Caddy Standard. Das Upload-Limit: nginx begrenzt den Request-Body per Vorgabe auf 1 MB und antwortet darüber mit einem 413, was bei Foto- und Video-Uploads sofort auffällt. Caddy kennt kein solches Vorgabelimit, die Direktive request_body müsst ihr setzen, wenn ihr begrenzen wollt. Die Weiterleitungs-Header: Caddy setzt X-Forwarded-For, X-Forwarded-Proto und X-Forwarded-Host von sich aus und verwirft eingehende Werte dieser Felder, damit sie nicht gefälscht werden können. Und WebSockets laufen einfach durch, ohne die aus nginx bekannte Upgrade-Klausel.

Wo Caddy nginx nicht ersetzt

Ehrlichkeitshalber gehört die Gegenrichtung dazu. nginx hat ein deutlich grösseres Ökosystem an Modulen, mehr Feinsteuerung beim Caching und mehr Personen, die sich damit auskennen. Wer bereits eine gewachsene, funktionierende nginx-Konfiguration hat, gewinnt durch einen Wechsel wenig. Und Caddy hat eine architektonische Eigenheit, die überrascht: Erweiterungen sind einkompilierte Go-Module. Ein Plugin nachzurüsten bedeutet, das Binary neu zu bauen. Dafür gibt es einen bequemen Befehl, aber es bleibt ein anderes Modell als eine nachinstallierte .so-Datei — mit einer Nebenwirkung, auf die wir weiter unten zurückkommen.

Voraussetzungen für den Reverse Proxy

Vier Dinge müssen stimmen, bevor die erste Zeile Konfiguration Sinn ergibt.

• Ein Server mit Debian 12/13 oder Ubuntu 24.04 und Root- beziehungsweise sudo-Rechten. Ein Raspberry Pi reicht für den Heimgebrauch vollkommen aus, der Proxy selbst ist genügsam.
• Eine Domain, deren DNS-Einträge auf eure öffentliche IP zeigen. Bei wechselnder IP am Hausanschluss braucht es dafür einen dynamischen Eintrag, wie in unserer Anleitung zum DynDNS-Eintrag bei dynamischer IP beschrieben. Für jeden Dienst legt ihr eine eigene Subdomain an.
• Die Ports 80 und 443 müssen von aussen auf den Proxy zeigen. Wie das am Schweizer Router eingerichtet wird, steht in unserem Beitrag zur Portweiterleitung auf Swisscom- und UPC-Modems. Hängt ihr an einem DS-Lite-Anschluss ohne öffentliche IPv4-Adresse, hilft keine Weiterleitung — dann führt der Weg über einen VPS als Brücke, wie in Webdienste hinter DS-Lite verfügbar machen mit Wireguard gezeigt.
• Die Dienste laufen bereits und lauschen lokal. Ob nativ installiert oder über Docker, spielt keine Rolle. Wichtig ist, dass sie auf 127.0.0.1 gebunden sind und nicht auf 0.0.0.0 — sonst ist der Proxy umgehbar.

Läuft auf dem Rechner bereits ein Apache oder nginx auf Port 80 und 443, stoppt und deaktiviert ihn vorher. Zwei Programme auf demselben Port ergeben beim Start nur eine Fehlermeldung.

Caddy unter Debian und Ubuntu installieren

Die Distributionspakete hinken der Entwicklung meist hinterher. Nehmt deshalb das offizielle Repository des Projekts:

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

Das Paket bringt eine systemd-Unit mit und startet den Dienst sofort. Prüft danach die Version:

caddy version
systemctl status caddy

Ruft ihr jetzt die IP des Servers im Browser auf, begrüsst euch eine Startseite. Der Dienst läuft unter dem Benutzer caddy, die Konfiguration liegt in /etc/caddy/Caddyfile, und die Zertifikate landen später unter /var/lib/caddy/.local/share/caddy. Diese drei Pfade solltet ihr euch merken, sie beantworten später die meisten Fragen.

Die erste Caddyfile: ein Dienst, ein Zertifikat

Öffnet /etc/caddy/Caddyfile, löscht den mitgelieferten Inhalt und schreibt stattdessen:

{
	email admin@example.ch
}

cloud.example.ch {
	reverse_proxy 127.0.0.1:8080
}

Das war die vollständige Konfiguration für einen Dienst mit gültigem Zertifikat und automatischer Weiterleitung von HTTP auf HTTPS. Der geschweifte Block ganz oben ist der globale Optionsblock. Er muss der erste Block der Datei sein und darf nur einmal vorkommen. Die Adresse unter email wird für das ACME-Konto verwendet; darüber informiert euch die Zertifizierungsstelle, wenn eine Erneuerung dauerhaft scheitert. Der zweite Block ist ein Site-Block: alles zwischen den Klammern gilt für Anfragen an diesen Hostnamen.

Formatiert und prüft die Datei, bevor ihr sie aktiviert:

sudo caddy fmt --overwrite /etc/caddy/Caddyfile
sudo caddy validate --config /etc/caddy/Caddyfile
sudo systemctl reload caddy

Ein Hinweis zur Einrückung: Die Caddyfile erwartet Tabulatoren, keine Leerzeichen. caddy fmt --overwrite räumt das für euch auf, weshalb dieser Befehl der erste von dreien ist. Alle Unterbefehle sind dokumentiert, im Alltag braucht ihr vor allem diese drei.

Was beim ersten Neuladen tatsächlich passiert

Caddy liest aus dem Site-Block heraus, dass es ein Zertifikat für cloud.example.ch braucht, und beginnt sofort damit. Primäre Zertifizierungsstelle ist Let's Encrypt, bei Fehlern weicht Caddy automatisch auf ZeroSSL aus. Zur Validierung stehen die HTTP-Challenge über Port 80 und die TLS-ALPN-Challenge über Port 443 bereit; Caddy wählt zunächst zufällig und merkt sich, welcher Weg bei euch verlässlich funktioniert. Nach wenigen Sekunden ist das Zertifikat da und der Dienst über HTTPS erreichbar.

Zusehen könnt ihr dabei im Journal:

journalctl -u caddy -f

Und hier lauert die erste ernsthafte Falle. Solange die DNS-Einträge noch nicht stimmen oder die Portweiterleitung fehlt, scheitert die Validierung — und Let's Encrypt zählt mit. Nach den offiziellen Rate Limits sind pro Bezeichner und Konto fünf fehlgeschlagene Autorisierungen pro Stunde erlaubt, pro registrierter Domain 50 Zertifikate in sieben Tagen und für einen exakt gleichen Satz von Bezeichnern fünf Zertifikate in sieben Tagen. Wer eine Konfiguration in Ruhe durchprobieren will, schaltet deshalb vorher auf die Testumgebung um:

{
	email admin@example.ch
	acme_ca https://acme-staging-v02.api.letsencrypt.org/directory
}

Die Zertifikate der Testumgebung sind im Browser ungültig, das ist beabsichtigt. Wenn alles steht, nehmt ihr die Zeile wieder heraus und ladet neu. Praktisch heisst das: erst mit Staging bauen, dann scharf schalten. Wer diese zwei Minuten überspringt, sitzt im schlechtesten Fall eine Woche auf einem gesperrten Bezeichner.

Drei Dienste hinter einer Adresse

Der eigentliche Gewinn zeigt sich erst ab dem zweiten Dienst. Jeder bekommt seinen eigenen Site-Block, jeder sein eigenes Zertifikat, alle teilen sich denselben Port:

{
	email admin@example.ch
}

cloud.example.ch {
	reverse_proxy 127.0.0.1:8080
}

vault.example.ch {
	reverse_proxy 127.0.0.1:8000
}

fotos.example.ch {
	reverse_proxy 127.0.0.1:2283
}

Die Ports sind die Vorgaben der jeweiligen Projekte: 8000 für Vaultwarden, 2283 für Immich, 8080 für einen Nextcloud-Container hinter dem Proxy. Bemerkenswert ist vor allem, was hier nicht steht. Keine Upload-Grenze für Immich. Keine WebSocket-Klausel für Vaultwarden, dessen eigenes Caddy-Beispiel im Projekt-Wiki ebenfalls mit einer einzigen reverse_proxy-Zeile auskommt. Keine Zertifikatspfade, keine Cipher-Listen, kein Redirect-Block.

Liegt ein Dienst auf einem anderen Rechner im lokalen Netz, tragt ihr dort statt 127.0.0.1 dessen IP ein. Und wenn das Backend selbst schon HTTPS spricht, etwa mit einem selbstsignierten Zertifikat, sieht das so aus:

nas.example.ch {
	reverse_proxy https://192.168.1.50:5001 {
		transport http {
			tls_insecure_skip_verify
		}
	}
}

Das Überspringen der Zertifikatsprüfung ist hier vertretbar, weil die Strecke im eigenen Netz liegt und die Verschlüsselung nach aussen der Proxy übernimmt. Auf einer Verbindung über das Internet wäre es ein Fehler.

Nextcloud hinter dem Reverse Proxy richtig konfigurieren

Nextcloud ist der Dienst, bei dem am häufigsten etwas schiefgeht — nicht wegen Caddy, sondern weil Nextcloud sich selbst hinter einem Proxy falsch einschätzt. Es sieht eine unverschlüsselte Anfrage von 127.0.0.1 und baut daraus Links mit http://. Ergebnis: Anmeldeschleifen, kaputte Vorschaubilder, und im Log steht bei jedem Zugriff dieselbe IP-Adresse. Ergänzt deshalb in config/config.php:

'trusted_domains' => [
  'cloud.example.ch',
],
'trusted_proxies' => ['127.0.0.1'],
'forwarded_for_headers' => ['HTTP_X_FORWARDED_FOR'],
'overwriteprotocol' => 'https',
'overwritehost' => 'cloud.example.ch',
'overwrite.cli.url' => 'https://cloud.example.ch',

Die Bedeutung der Werte steht in der kommentierten Beispielkonfiguration im Nextcloud-Repository. trusted_proxies erlaubt Nextcloud, den weitergereichten Client-IPs überhaupt zu glauben, forwarded_for_headers legt fest, welchem Header dabei vertraut wird, und die drei overwrite-Werte korrigieren die Selbsteinschätzung bei der URL-Erzeugung. Läuft Nextcloud in einem Container, gehört unter trusted_proxies nicht 127.0.0.1, sondern die Adresse des Docker-Netzes.

Sicherheitskopfzeilen an einer Stelle statt in jedem Dienst

Der zweite grosse Vorteil eines zentralen Einstiegspunkts: Kopfzeilen, die für alle Dienste gelten sollen, schreibt ihr genau einmal. Caddy kennt dafür wiederverwendbare Bausteine, sogenannte Snippets, die in runden Klammern definiert und mit import eingebunden werden:

{
	header {
		Strict-Transport-Security "max-age=31536000"
		X-Content-Type-Options "nosniff"
		X-Frame-Options "SAMEORIGIN"
		Referrer-Policy "no-referrer"
		-Server
	}
}

cloud.example.ch {
	import sicherheit
	reverse_proxy 127.0.0.1:8080
}

vault.example.ch {
	import sicherheit
	reverse_proxy 127.0.0.1:8000
}

Das führende Minus vor Server löscht die Kopfzeile aus der Antwort. Bei Strict-Transport-Security ist Vorsicht angebracht: Die Anweisung sagt jedem Browser, diese Domain für die angegebene Dauer ausschliesslich über HTTPS anzusprechen — hier ein Jahr. Das ist erwünscht, aber es lässt sich nicht kurzfristig zurücknehmen. Nehmt die Zusätze includeSubDomains und preload erst dazu, wenn wirklich jede Subdomain dauerhaft per HTTPS erreichbar ist.

Zertifikate ohne offene Ports: die DNS-Challenge

HTTP- und TLS-ALPN-Challenge setzen voraus, dass die Zertifizierungsstelle euren Server von aussen erreicht. Das ist nicht immer der Fall: an einem DS-Lite-Anschluss fehlt die öffentliche IPv4-Adresse, manche Provider sperren Port 80, und für Dienste, die absichtlich nur im VPN erreichbar sind, gibt es gar keinen Weg von aussen. Ausserdem lassen sich Wildcard-Zertifikate ausschliesslich per DNS ausstellen.

Die DNS-Challenge dreht die Beweisrichtung um: Statt einer Datei auf eurem Server legt Caddy einen TXT-Eintrag in eurer DNS-Zone an. Damit braucht es keinen einzigen offenen Port — aber Schreibzugriff auf die Zone.

Plugin nachrüsten mit caddy add-package

Für jeden DNS-Anbieter gibt es ein eigenes Modul, und weil Caddy-Erweiterungen einkompiliert werden, braucht es ein neues Binary. Der eingebaute Befehl erledigt das:

sudo caddy add-package github.com/caddy-dns/cloudflare
caddy list-modules --packages | grep cloudflare
sudo systemctl restart caddy

Und damit zur angekündigten Nebenwirkung: caddy add-package ersetzt das vom Paketmanager installierte Binary. Beim nächsten apt upgrade überschreibt apt es wieder mit der Standardversion — das Plugin ist weg, die Caddyfile verweist auf ein Modul, das es nicht mehr gibt, und der Dienst startet nicht. Wer das vermeiden will, führt add-package nach jedem Upgrade erneut aus oder aktualisiert stattdessen mit caddy upgrade, das die installierten Module beibehält. Notiert euch die Zeile mit euren Paketen an einer Stelle, an der ihr sie wiederfindet.

Den API-Token sauber übergeben

Der Token gehört nicht in die Caddyfile, sondern in die Umgebung des Dienstes. Bei Cloudflare braucht er laut Modul-Dokumentation genau zwei Berechtigungen: Zone.Zone:Read und Zone.DNS:Edit, beschränkt auf die betroffenen Zonen. Legt ein systemd-Override an:

sudo systemctl edit caddy

Und tragt dort ein:

[Service]
Environment="CF_API_TOKEN=euer_token_hier"

In der Caddyfile wird der Wert dann als Platzhalter referenziert:

intern.example.ch {
	tls {
		dns cloudflare {env.CF_API_TOKEN}
	}
	reverse_proxy 127.0.0.1:3000
}

Die ältere Schreibweise mit getrennten zone_token- und api_token-Feldern taucht in vielen Anleitungen im Netz noch auf. Das Modul bezeichnet sie ausdrücklich als veraltet und behält sie nur aus Kompatibilitätsgründen — nehmt die einzeilige Variante.

Wildcard-Zertifikate

Steht die DNS-Challenge, könnt ihr ein einziges Zertifikat für alle Subdomains ausstellen lassen. Das reduziert die Zahl der ACME-Anfragen erheblich und hält euch von den Rate Limits fern:

*.example.ch {
	tls {
		dns cloudflare {env.CF_API_TOKEN}
	}

	@cloud host cloud.example.ch
	handle @cloud {
		reverse_proxy 127.0.0.1:8080
	}

	@vault host vault.example.ch
	handle @vault {
		reverse_proxy 127.0.0.1:8000
	}

	handle {
		abort
	}
}

Die mit @ beginnenden Ausdrücke sind Matcher, die den passenden Hostnamen herausgreifen. Der letzte handle-Block ohne Matcher fängt alles ab, was zu keinem Dienst gehört, und bricht die Verbindung ab — sonst würde jede erfundene Subdomain irgendwo landen. Beachtet dabei, dass ein Wildcard-Zertifikat nur eine Ebene abdeckt: *.example.ch gilt für cloud.example.ch, aber nicht für a.b.example.ch.

Betrieb: prüfen, neu laden, Logs lesen

Im laufenden Betrieb sind es vor allem drei Handgriffe. Nach jeder Änderung an der Caddyfile gilt dieselbe Reihenfolge wie oben: formatieren, validieren, neu laden. systemctl reload caddy übernimmt die neue Konfiguration ohne Verbindungsabbruch — ein restart ist nur nötig, wenn ihr das Binary getauscht oder die systemd-Unit geändert habt.

Standardmässig landet alles im Journal. Für einen einzelnen Dienst lohnt sich ein eigenes Zugriffsprotokoll, etwa um es später an CrowdSec zu übergeben:

cloud.example.ch {
	log {
		output file /var/log/caddy/cloud.log {
			roll_size 10MiB
			roll_keep 5
		}
	}
	reverse_proxy 127.0.0.1:8080
}

Das Verzeichnis muss dem Benutzer caddy gehören. Und ein Punkt, der gern vergessen wird: In eure Sicherung gehört nicht nur /etc/caddy, sondern auch /var/lib/caddy/.local/share/caddy. Dort liegen die Zertifikate, die privaten Schlüssel und der ACME-Kontoschlüssel. Ohne dieses Verzeichnis holt ein neu aufgesetzter Server zwar alle Zertifikate neu — aber jeder solche Durchlauf zählt auf die Rate Limits.

Stolperfallen, die euch einen Abend kosten

• Port 80 zugemacht. Viele schliessen ihn, weil ohnehin alles über HTTPS läuft. Dann fehlt die Weiterleitung für Besucher, die ohne Präfix tippen, und die HTTP-Challenge fällt als Ausweichweg weg. Lasst ihn offen, ausser ihr nutzt ausschliesslich die DNS-Challenge.
• Alter Webserver läuft noch. Ein address already in use im Journal bedeutet fast immer einen vergessenen Apache oder nginx.
• Dienst lauscht auf 0.0.0.0. Dann ist er direkt über seinen Port erreichbar, unverschlüsselt und ohne die gesetzten Kopfzeilen. Bindet Backends an 127.0.0.1 und blockt die Ports zusätzlich in der Firewall.
• Cloudflare-Proxy davor. Steht in eurem DNS die orange Wolke, terminiert Cloudflare TLS selbst und die TLS-ALPN-Challenge scheitert zwangsläufig. Dann führt der Weg über die DNS-Challenge.
• Konfiguration nicht validiert. systemctl reload mit einer fehlerhaften Datei lässt die alte Konfiguration aktiv und meldet den Fehler nur im Journal. Wer nicht hinsieht, wundert sich, warum die Änderung nichts bewirkt.
• Leerzeichen statt Tabulatoren. Erzeugt Fehlermeldungen, die auf den ersten Blick nichts mit Einrückung zu tun haben. caddy fmt --overwrite zuerst.

Was ihr tun könnt

• Legt für jeden Dienst eine eigene Subdomain an, statt Ports nach aussen zu öffnen. Das kostet nichts und ist die Grundlage für alles Weitere.
• Baut die erste Konfiguration gegen den Staging-Endpunkt von Let's Encrypt. Zwei zusätzliche Minuten, die euch im Fehlerfall eine Woche Wartezeit ersparen.
• Bindet alle Backends auf 127.0.0.1 und prüft mit ss -tlnp, ob sich noch etwas an einer öffentlichen Adresse festhält.
• Zieht die Sicherheitskopfzeilen in ein Snippet und importiert es in jeden Site-Block, statt sie in jedem Dienst einzeln zu pflegen.
• Nehmt /var/lib/caddy/.local/share/caddy in die Sicherung auf.
• Wenn ihr Plugins nachrüstet: haltet die add-package-Zeile fest und prüft nach jedem Systemupdate mit caddy list-modules --packages, ob sie noch da sind.

Fazit: Caddy macht TLS zur Standardeinstellung statt zur Bastelaufgabe

Die verbreitete Kombination aus nginx und Certbot funktioniert seit Jahren zuverlässig, und niemand muss sie ersetzen. Aber sie besteht aus vier Teilen, die zusammenarbeiten müssen: Webserver, ACME-Client, Timer und Konfigurationsdateien, die zwei Programme gleichzeitig bearbeiten. Jeder dieser Teile hat schon einmal jemandem ein abgelaufenes Zertifikat beschert.

Caddy schneidet diese Kette auf ein Teil zusammen. Sechs Zeilen Konfiguration reichen für einen Dienst mit gültigem Zertifikat, automatischer Erneuerung, HTTP-Weiterleitung, HTTP/2, HTTP/3 und funktionierenden WebSockets. Dass Immich in der eigenen Dokumentation eine halbe Seite nginx neben drei Zeilen Caddy stellt, ist keine Werbung des Caddy-Projekts, sondern die Einschätzung eines unbeteiligten Dritten.

Der Preis dafür sind weniger Stellschrauben und ein Erweiterungsmodell, das bei jedem Systemupdate Aufmerksamkeit verlangt. Für die überwiegende Mehrheit selbst gehosteter Installationen ist das ein guter Handel. Verschlüsselung sollte der unauffällige Normalzustand sein und nicht die Aufgabe, die dreimal im Jahr um drei Uhr morgens Alarm schlägt — und genau daran gemessen ist Caddy für Selfhoster derzeit die vernünftigste Wahl.

Quellen und weiterführende Links

• Caddy Documentation — Install, offizielle Installationswege inklusive apt-Repository
• Caddy Documentation — Automatic HTTPS, Ablauf der Zertifikatsbeschaffung und Challenge-Auswahl
• Caddy Documentation — reverse_proxy, Syntax, gesetzte Header, Transport und Lastverteilung
• Caddy Documentation — tls, DNS-Challenge, Propagation und alternative Zertifizierungsstellen
• Caddy Documentation — Global Options, globaler Optionsblock mit email und acme_ca
• Caddy Documentation — Command Line, validate, fmt, reload, add-package und upgrade
• Caddy Documentation — Keeping Caddy Running, systemd-Dienst, Benutzer und Datenverzeichnisse
• Caddy Documentation — request_body, Begrenzung der Anfragegrösse
• caddyserver/caddy — Releases, Versionsstand v2.11.4 vom 3. Juni 2026
• caddy-dns/cloudflare, Konfigurationssyntax und benötigte Token-Berechtigungen
• Let's Encrypt — Rate Limits, verbindliche Grenzwerte für Ausstellung und Fehlversuche
• nginx — client_max_body_size, Vorgabewert 1 MB und Verhalten bei Überschreitung
• Immich — Reverse Proxy, Vergleich der nginx- und Caddy-Konfiguration
• Vaultwarden Wiki — Proxy examples, Caddy-Beispiel des Projekts
• Nextcloud — config.sample.php, kommentierte Referenz zu trusted_proxies und den overwrite-Werten