Caddy Webserver: Automatisches HTTPS und konfigurationsfreier Reverse Proxy

Caddy ist ein moderner, quelloffener Webserver, geschrieben in Go, der sich durch eine herausragende Funktion auszeichnet: automatisches HTTPS. Waehrend traditionelle Webserver wie Nginx und Apache eine manuelle Zertifikatseinrichtung mit Certbot oder aehnlichen Tools erfordern, bezieht und erneuert Caddy TLS-Zertifikate von Let’s Encrypt, sobald Sie eine Domain darauf richten. Kombiniert mit seiner minimalen Konfigurationssyntax, dem integrierten Reverse Proxy und HTTP/3-Unterstuetzung ist Caddy zur bevorzugten Wahl fuer Entwickler geworden, die sichere, produktionsreife Web-Bereitstellung mit minimalem Aufwand wuenschen.

Was ist Caddy?

Caddy ist eine erweiterbare Webserver-Plattform, die Benutzerfreundlichkeit und sichere Standardeinstellungen priorisiert. Er wurde 2015 von Matt Holt erstellt und wird als einzelne, statisch kompilierte Binaerdatei ohne externe Abhaengigkeiten verteilt.

Hauptmerkmale von Caddy:

• Automatisches HTTPS — Beschafft und erneuert TLS-Zertifikate von Let’s Encrypt oder ZeroSSL ohne jegliche Konfiguration
• HTTP/2 und HTTP/3 — Standardmaessig fuer alle HTTPS-Sites aktiviert
• Reverse Proxy — Integrierter Reverse Proxy mit Lastverteilung, Gesundheitspruefungen und Header-Manipulation
• Konfigurationsfreier Modus — Ein einfaches zweizeiliges Caddyfile kann eine komplette Site mit HTTPS bereitstellen
• Plattformuebergreifend — Laeuft auf Linux, macOS, Windows und BSD
• Plugin-Oekosystem — Erweitern Sie die Funktionalitaet mit Modulen fuer DNS-Anbieter, Authentifizierung, Ratenbegrenzung und mehr

Caddy wird unter der Apache 2.0-Lizenz vertrieben und ist fuer den persoenlichen wie kommerziellen Einsatz kostenlos.

Caddy vs Nginx

Wenn Sie derzeit Nginx verwenden und sich fragen, ob Caddy fuer Ihr Projekt geeignet ist, hier ein direkter Vergleich:

Eigenschaft	Caddy	Nginx
HTTPS	Automatisch (integrierter ACME-Client)	Manuell (erfordert Certbot oder aehnliches)
Konfigurationssyntax	Caddyfile (minimal, gut lesbar)	nginx.conf (leistungsstark, aber ausfuehrlich)
HTTP/2	Standardmaessig aktiviert	Erfordert explizite Konfiguration
HTTP/3 (QUIC)	Integriert, standardmaessig aktiviert	Experimentell (erfordert separaten Build)
Reverse Proxy	Integrierte Direktive	Integriertes Modul
Lastverteilung	Integriert mit mehreren Richtlinien	Integriert (Round-Robin, least_conn, etc.)
Konfigurations-Neuladen	Ohne Ausfallzeit via API oder SIGHUP	Ohne Ausfallzeit via nginx -s reload
Sprache	Go (speichersicher)	C (hohe Leistung)
Speicherverbrauch	Niedrig (~20-50 MB)	Sehr niedrig (~5-15 MB)
Rohdurchsatz	Sehr gut	Ausgezeichnet (Millionen von RPS)
Community und Oekosystem	Waechst schnell	Riesig, Jahrzehnte an Dokumentation

Wann Caddy waehlen: Sie wollen automatisches HTTPS, minimale Konfiguration und einen modernen Funktionsumfang ohne manuelle Zertifikatsverwaltung. Ideal fuer selbst gehostete Anwendungen, persoenliche Projekte und kleine bis mittlere Deployments.

Wann Nginx waehlen: Sie benoetigen extrem granulare Kontrolle, maximalen Rohdurchsatz fuer Millionen gleichzeitiger Verbindungen oder umfangreiche Modulkompatibilitaet aus Jahrzehnten der Oekosystem-Entwicklung.

Voraussetzungen

Bevor Sie Caddy installieren, stellen Sie sicher, dass Sie Folgendes haben:

• Einen Linux-Server mit Ubuntu 22.04+ oder Debian 12+ (andere Distributionen werden ebenfalls unterstuetzt)
• Einen Domainnamen mit DNS A/AAAA-Eintraegen, die auf die oeffentliche IP-Adresse Ihres Servers zeigen
• Ports 80 und 443 in Ihrer Firewall geoeffnet (erforderlich fuer ACME HTTP-Challenge und HTTPS)
• Root- oder Sudo-Zugang zum Server
• Keinen anderen Webserver (Nginx, Apache), der bereits auf den Ports 80/443 lauscht

Ueberpruefen Sie, ob Ihre Firewall die erforderlichen Ports zulaesst:

# Bei Verwendung von UFW
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw status

Caddy auf Ubuntu installieren

Die empfohlene Installationsmethode verwendet das offizielle Caddy APT-Repository, das automatische Updates bereitstellt:

# Erforderliche Abhaengigkeiten installieren
sudo apt update
sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl

# Caddys GPG-Schluessel hinzufuegen
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg

# Das Caddy-Repository hinzufuegen
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list

# Caddy installieren
sudo apt update
sudo apt install -y caddy

Ueberpruefen Sie die Installation:

caddy version

Sie sollten eine Ausgabe wie v2.8.4 h1:... sehen, die bestaetigt, dass Caddy installiert ist. Die Paketinstallation erstellt auch einen systemd-Dienst, ein Standard-Caddyfile unter /etc/caddy/Caddyfile und einen caddy-Benutzer zum Ausfuehren des Prozesses.

Alternative: Installation von der Binaerdatei

Wenn Sie eine manuelle Installation bevorzugen oder eine bestimmte Version benoetigen:

# Die neueste Version herunterladen
curl -Lo caddy.tar.gz "https://github.com/caddyserver/caddy/releases/latest/download/caddy_2.8.4_linux_amd64.tar.gz"

# Entpacken und in den PATH verschieben
tar xzf caddy.tar.gz
sudo mv caddy /usr/bin/caddy
sudo chmod +x /usr/bin/caddy

# Ueberpruefen
caddy version

Das Caddyfile verstehen

Das Caddyfile ist die Konfigurationsdatei von Caddy. Seine Syntax ist bewusst minimal — Sie beschreiben, was Sie wollen, nicht wie es erreicht werden soll. Caddy fuellt die sinnvollen Standardwerte aus.

Das Caddyfile befindet sich unter /etc/caddy/Caddyfile, wenn es ueber den Paketmanager installiert wurde. Hier ist die grundlegende Struktur:

# Globale Optionen (optional)
{
    email admin@example.com
}

# Site-Block
example.com {
    root * /var/www/html
    file_server
}

Zentrale Konzepte:

• Site-Adresse — Die Domain oder IP vor der oeffnenden Klammer. Die Verwendung eines Domainnamens loest automatisch HTTPS aus.
• Direktiven — Befehle innerhalb des Site-Blocks wie root, file_server, reverse_proxy.
• Globale Optionen — Einstellungen innerhalb eines {}-Blocks auf oberster Ebene ohne Adresse. Werden fuer E-Mail (fuer ACME-Registrierung), Logging-Standardwerte usw. verwendet.
• Matcher — Muster wie * oder /api/*, die steuern, auf welche Anfragen eine Direktive angewendet wird.

Nach dem Bearbeiten des Caddyfiles validieren und neu laden:

# Syntax validieren
caddy validate --config /etc/caddy/Caddyfile

# Ohne Ausfallzeit neu laden
sudo systemctl reload caddy

Statische Dateien bereitstellen

Die Bereitstellung einer statischen Website mit Caddy erfordert nur wenige Zeilen:

example.com {
    root * /var/www/mysite
    file_server
}

Das ist alles. Caddy wird:

1. Automatisch ein TLS-Zertifikat fuer example.com beziehen
2. Dateien aus /var/www/mysite bereitstellen
3. HTTP/2 und HTTP/3 aktivieren
4. HTTP auf HTTPS umleiten

Fuer eine vollstaendigere Konfiguration statischer Sites mit Komprimierung und Caching:

example.com {
    root * /var/www/mysite

    # Gzip- und Zstd-Komprimierung aktivieren
    encode gzip zstd

    # Statische Dateien bereitstellen mit deaktiviertem Verzeichnis-Browsing
    file_server {
        hide .git .env
    }

    # Benutzerdefinierte Fehlerseiten
    handle_errors {
        rewrite * /{err.status_code}.html
        file_server
    }

    # Statische Ressourcen cachen
    @static path *.css *.js *.png *.jpg *.gif *.svg *.woff2
    header @static Cache-Control "public, max-age=2592000, immutable"

    # Sicherheits-Header
    header {
        X-Content-Type-Options "nosniff"
        X-Frame-Options "DENY"
        Referrer-Policy "strict-origin-when-cross-origin"
    }
}

Erstellen Sie das Web-Stammverzeichnis und eine Testseite:

sudo mkdir -p /var/www/mysite
echo '<h1>Hello from Caddy</h1>' | sudo tee /var/www/mysite/index.html
sudo chown -R caddy:caddy /var/www/mysite

Automatisches HTTPS

Automatisches HTTPS ist die Kernfunktion von Caddy. Das Verstaendnis der Funktionsweise hilft Ihnen bei der Fehlerbehebung und Anpassung des Verhaltens.

Wie es funktioniert

Wenn Caddy einen Site-Block mit einem oeffentlichen Domainnamen (nicht localhost oder eine IP) findet, fuehrt es automatisch folgende Schritte aus:

1. DNS-Pruefung — Ueberprueft, ob die Domain auf die oeffentliche IP des Servers aufloest
2. Zertifikatsanfrage — Kontaktiert Let’s Encrypt (oder ZeroSSL als Fallback) ueber das ACME-Protokoll
3. HTTP-01-Challenge abschliessen — Beweist den Domainbesitz durch Bereitstellung eines Tokens auf Port 80
4. Zertifikat installieren — Konfiguriert TLS mit dem erhaltenen Zertifikat und Schluessel
5. HTTP auf HTTPS umleiten — Erstellt eine automatische Umleitung auf Port 80
6. Erneuerung planen — Erneuert das Zertifikat vor Ablauf (typischerweise 30 Tage im Voraus)

Das ACME-Protokoll

ACME (Automatic Certificate Management Environment) ist das Protokoll, das Let’s Encrypt zur Ueberpruefung des Domainbesitzes verwendet. Caddy enthaelt einen vollstaendigen ACME-Client, der Folgendes unterstuetzt:

• HTTP-01-Challenge — Stellt eine Token-Datei per HTTP auf Port 80 bereit (Standard)
• TLS-ALPN-01-Challenge — Verwendet TLS-Aushandlung auf Port 443
• DNS-01-Challenge — Erstellt einen DNS-TXT-Eintrag (erfordert ein DNS-Provider-Plugin)

ACME-E-Mail konfigurieren

Legen Sie eine E-Mail-Adresse fuer Zertifikatsablauf-Benachrichtigungen und Kontoregistrierung fest:

{
    email admin@example.com
}

example.com {
    reverse_proxy localhost:3000
}

Eine Staging-CA fuer Tests verwenden

Waehrend der Entwicklung verwenden Sie die Staging-Umgebung von Let’s Encrypt, um Ratenbegrenzungen zu vermeiden:

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

example.com {
    reverse_proxy localhost:3000
}

Wichtig: Staging-Zertifikate werden von Browsern nicht als vertrauenswuerdig eingestuft. Entfernen Sie die acme_ca-Direktive beim Wechsel in die Produktion.

Interne (selbstsignierte) Zertifikate

Fuer die lokale Entwicklung oder interne Dienste, die keine oeffentlichen Zertifikate benoetigen:

{
    local_certs
}

localhost {
    reverse_proxy localhost:3000
}

Caddy generiert ein selbstsigniertes Zertifikat und installiert seine Root-CA im System-Vertrauensspeicher, damit Browser es lokal akzeptieren.

Reverse-Proxy-Konfiguration

Die reverse_proxy-Direktive von Caddy bietet einen voll ausgestatteten Reverse Proxy mit minimaler Konfiguration.

Einfacher Reverse Proxy

app.example.com {
    reverse_proxy localhost:3000
}

Diese einzelne Zeile leitet den gesamten Datenverkehr von app.example.com an ein Backend auf Port 3000 weiter, mit automatischem HTTPS, HTTP/2 und korrekter Header-Weiterleitung.

Mehrere Backends auf einer Domain

Verwenden Sie pfadbasiertes Routing, um verschiedene Pfade an verschiedene Backends weiterzuleiten:

example.com {
    reverse_proxy /api/* localhost:8000
    reverse_proxy /admin/* localhost:9000

    # Alles andere stellt statische Dateien bereit
    root * /var/www/frontend
    file_server
}

Mehrere Domains (Virtuelle Hosts)

app.example.com {
    reverse_proxy localhost:3000
}

api.example.com {
    reverse_proxy localhost:8000
}

admin.example.com {
    reverse_proxy localhost:9000 {
        header_up X-Custom-Header "admin-panel"
    }
}

Jede Domain erhaelt automatisch ihr eigenes TLS-Zertifikat.

Client-Informationen bewahren

Caddy setzt automatisch die Header X-Forwarded-For, X-Forwarded-Proto und X-Forwarded-Host. Sie koennen Header hinzufuegen oder ueberschreiben:

app.example.com {
    reverse_proxy localhost:3000 {
        header_up Host {upstream_hostport}
        header_up X-Real-IP {remote_host}
        header_up X-Forwarded-Port {server_port}
    }
}

WebSocket-Unterstuetzung

Caddy leitet WebSocket-Verbindungen transparent weiter — keine zusaetzliche Konfiguration erforderlich:

ws.example.com {
    reverse_proxy localhost:4000
}

Die Upgrade- und Connection-Header werden automatisch vom Reverse Proxy von Caddy verarbeitet.

Lastverteilung

Caddy unterstuetzt die Lastverteilung ueber mehrere Backend-Instanzen mit verschiedenen Richtlinien.

Round-Robin (Standard)

app.example.com {
    reverse_proxy localhost:3001 localhost:3002 localhost:3003
}

Lastverteilungsrichtlinien

app.example.com {
    reverse_proxy localhost:3001 localhost:3002 localhost:3003 {
        lb_policy least_conn
    }
}

Verfuegbare Richtlinien:

Richtlinie	Beschreibung
random	Waehlt ein zufaelliges Backend
least_conn	Sendet an das Backend mit den wenigsten aktiven Verbindungen
round_robin	Durchlaeuft die Backends sequenziell (Standard)
first	Verwendet immer das erste verfuegbare Backend
ip_hash	Routet basierend auf der Client-IP fuer Sitzungsaffinitaet
uri_hash	Routet basierend auf dem Anfrage-URI
header	Routet basierend auf einem Anfrage-Header-Wert
cookie	Routet basierend auf einem Cookie-Wert fuer Sitzungspersistenz

Gesundheitspruefungen

Aktivieren Sie aktive Gesundheitspruefungen, um fehlerhafte Backends zu erkennen und zu entfernen:

app.example.com {
    reverse_proxy localhost:3001 localhost:3002 localhost:3003 {
        lb_policy least_conn

        health_uri /health
        health_interval 10s
        health_timeout 5s
        health_status 200

        # Passive Gesundheitspruefungen
        fail_duration 30s
        max_fails 3
        unhealthy_latency 500ms
    }
}

Header, Komprimierung und Caching

Benutzerdefinierte Antwort-Header

example.com {
    header {
        # Sicherheits-Header
        Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
        X-Content-Type-Options "nosniff"
        X-Frame-Options "DENY"
        Referrer-Policy "strict-origin-when-cross-origin"
        Permissions-Policy "camera=(), microphone=(), geolocation=()"

        # Server-Identifikation entfernen
        -Server

        # Cache-Steuerung fuer dynamische Inhalte
        Cache-Control "no-store, no-cache, must-revalidate"
    }

    reverse_proxy localhost:3000
}

Komprimierung

Aktivieren Sie transparente Komprimierung mit encode:

example.com {
    encode zstd gzip

    reverse_proxy localhost:3000
}

Caddy handelt automatisch den besten Komprimierungsalgorithmus basierend auf dem Accept-Encoding-Header des Clients aus. Zstandard (zstd) wird bevorzugt, wenn es unterstuetzt wird, da es bessere Komprimierungsraten und schnellere Dekomprimierung als gzip bietet.

Caching statischer Ressourcen

example.com {
    @static path *.css *.js *.png *.jpg *.gif *.svg *.woff2 *.ico
    header @static Cache-Control "public, max-age=31536000, immutable"

    @dynamic not path *.css *.js *.png *.jpg *.gif *.svg *.woff2 *.ico
    header @dynamic Cache-Control "no-cache, must-revalidate"

    reverse_proxy localhost:3000
}

Caddy als systemd-Dienst ausfuehren

Die APT-Paketinstallation erstellt automatisch einen systemd-Dienst. Hier sind die wesentlichen Befehle:

# Caddy starten
sudo systemctl start caddy

# Caddy stoppen
sudo systemctl stop caddy

# Caddy neu starten (kurze Ausfallzeit)
sudo systemctl restart caddy

# Konfiguration ohne Ausfallzeit neu laden
sudo systemctl reload caddy

# Caddy beim Booten aktivieren
sudo systemctl enable caddy

# Dienststatus pruefen
sudo systemctl status caddy

# Logs anzeigen
sudo journalctl -u caddy --no-pager -f

Die Caddy-Dienstdatei

Die Standard-systemd-Unit-Datei befindet sich unter /lib/systemd/system/caddy.service. Sie fuehrt Caddy als caddy-Benutzer aus und laedt /etc/caddy/Caddyfile:

[Unit]
Description=Caddy
Documentation=https://caddyserver.com/docs/
After=network.target network-online.target
Requires=network-online.target

[Service]
Type=notify
User=caddy
Group=caddy
ExecStart=/usr/bin/caddy run --environ --config /etc/caddy/Caddyfile
ExecReload=/usr/bin/caddy reload --config /etc/caddy/Caddyfile --force
TimeoutStopSec=5s
LimitNOFILE=1048576
LimitNPROC=512
PrivateTmp=true
ProtectSystem=full
AmbientCapabilities=CAP_NET_BIND_SERVICE

[Install]
WantedBy=multi-user.target

Hinweis: Wenn Sie Caddy manuell installiert haben (nicht aus dem Paket), muessen Sie diese Dienstdatei selbst erstellen und den caddy-Benutzer mit sudo useradd --system --home /var/lib/caddy --shell /usr/sbin/nologin caddy hinzufuegen.

Die Installation ueberpruefen

Nachdem Sie Caddy gestartet haben, ueberpruefen Sie, ob es Ihre Site bereitstellt:

# Pruefen, ob Caddy lauscht
sudo ss -tlnp | grep caddy

# HTTPS testen (ersetzen Sie durch Ihre Domain)
curl -I https://example.com

# Zertifikatsdetails pruefen
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -subject -dates

Caddyfile-Direktiven Referenz

Hier ist eine Referenz der am haeufigsten verwendeten Caddyfile-Direktiven:

Direktive	Zweck	Beispiel
reverse_proxy	Anfragen an Backend-Server weiterleiten	reverse_proxy localhost:3000
file_server	Statische Dateien von der Festplatte bereitstellen	file_server
root	Das Dokumentenstammverzeichnis festlegen	root * /var/www/html
encode	Antwortkomprimierung aktivieren	encode gzip zstd
header	Antwort-Header setzen, hinzufuegen oder entfernen	header X-Frame-Options "DENY"
redir	Anfragen auf eine neue URL umleiten	redir /old /new permanent
rewrite	Die Anfrage-URI intern umschreiben	rewrite /app/* /index.html
basicauth	Routen mit HTTP Basic Auth schuetzen	basicauth /admin/* { ... }
tls	TLS-Einstellungen manuell konfigurieren	tls internal
log	Zugriffs-Logging konfigurieren	log { output file /var/log/caddy/access.log }
handle	Direktiven fuer gegenseitige Exklusivitaet gruppieren	handle /api/* { ... }
handle_path	Wie handle, entfernt aber das passende Praefix	handle_path /api/* { ... }
respond	Eine statische Antwort zurueckgeben	respond "OK" 200
import	Eine andere Datei oder ein Snippet einbinden	import /etc/caddy/snippets/*
php_fastcgi	PHP-Anfragen an PHP-FPM weiterleiten	php_fastcgi unix//run/php/php-fpm.sock

Wiederverwendbare Snippets

Definieren Sie wiederverwendbare Konfigurationsbloecke mit Snippets:

# Snippet definieren
(security_headers) {
    header {
        Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
        X-Content-Type-Options "nosniff"
        X-Frame-Options "DENY"
        Referrer-Policy "strict-origin-when-cross-origin"
        -Server
    }
}

# Snippet in Site-Bloecken verwenden
app.example.com {
    import security_headers
    reverse_proxy localhost:3000
}

api.example.com {
    import security_headers
    reverse_proxy localhost:8000
}

Fehlerbehebung

Zertifikatsprobleme

Wenn Caddy kein Zertifikat beziehen kann, pruefen Sie diese haeufigen Ursachen:

# DNS-Aufloesung ueberpruefen
dig +short example.com

# Sicherstellen, dass Ports 80 und 443 erreichbar sind
sudo ss -tlnp | grep -E ':80|:443'

# Pruefen, ob ein anderer Dienst Port 80 verwendet
sudo lsof -i :80

# Caddy-Logs auf ACME-Fehler pruefen
sudo journalctl -u caddy --no-pager | grep -i "acme\|certificate\|tls"

Haeufige Ursachen fuer Zertifikatsfehler:

• DNS zeigt nicht auf Ihren Server — Die Domain muss auf die oeffentliche IP des Servers aufloesen
• Port 80 durch Firewall blockiert — Erforderlich fuer die HTTP-01-Challenge
• Ein anderer Dienst verwendet Port 80 — Stoppen Sie Nginx, Apache oder jeden anderen Webserver
• Ratenbegrenzungen — Let’s Encrypt begrenzt die Zertifikatsausstellung auf 5 pro Domain pro Woche

502 Bad Gateway

Dies bedeutet, dass Caddy das Upstream-Backend nicht erreichen kann:

# Ueberpruefen, ob das Backend laeuft
curl -I http://localhost:3000

# Pruefen, ob das Backend auf localhost oder allen Interfaces lauscht
sudo ss -tlnp | grep 3000

# Haeufige Loesung: Sicherstellen, dass das Backend auf 127.0.0.1 lauscht, nicht auf 0.0.0.0

Berechtigungsfehler

# Sicherstellen, dass der caddy-Benutzer Lesezugriff auf das Web-Stammverzeichnis hat
sudo chown -R caddy:caddy /var/www/mysite

# Dateiberechtigungen pruefen
ls -la /var/www/mysite/

# Wenn Caddy sich nicht an die Ports 80/443 binden kann
sudo setcap 'cap_net_bind_service=+ep' /usr/bin/caddy

Konfigurationsvalidierung

# Immer vor dem Neuladen validieren
caddy validate --config /etc/caddy/Caddyfile

# Das Caddyfile formatieren (Einrueckung korrigieren)
caddy fmt --overwrite /etc/caddy/Caddyfile

# Mit einem bestimmten Adapter testen (z.B. fuer JSON-Konfiguration)
caddy adapt --config /etc/caddy/Caddyfile

Caddy Admin-API

Caddy stellt eine lokale Admin-API auf localhost:2019 fuer die Laufzeitkonfiguration bereit:

# Aktuelle Konfiguration als JSON anzeigen
curl http://localhost:2019/config/

# Geladene Zertifikate pruefen
curl http://localhost:2019/pki/ca/local

# Konfiguration ueber API neu laden
curl -X POST http://localhost:2019/load \
  -H "Content-Type: text/caddyfile" \
  --data-binary @/etc/caddy/Caddyfile

Zusammenfassung

Caddy eliminiert die Komplexitaet der Webserver-Konfiguration, indem es automatisches HTTPS, eine minimale Caddyfile-Syntax und produktionsreife Standardwerte bereitstellt. Ob Sie statische Dateien bereitstellen, mit einem Reverse Proxy an eine Backend-Anwendung weiterleiten oder die Last ueber mehrere Instanzen verteilen — Caddy uebernimmt die schwere Arbeit, einschliesslich der TLS-Zertifikatsverwaltung, damit Sie sich auf die Entwicklung Ihrer Anwendung konzentrieren koennen.

Fuer mehr zur Reverse-Proxy-Konfiguration mit Nginx, siehe unseren Nginx Reverse Proxy Complete Guide. Wenn Sie Zertifikate manuell mit Certbot fuer Server verwalten muessen, die kein Caddy verwenden, schauen Sie sich Automate SSL Certificates with Let’s Encrypt and Certbot an.