Cache-Control für Caddy konfigurieren
Schritt-für-Schritt-Anleitung: Named Matcher für sensible Pfade definieren, Cache-Control mit der header-Direktive setzen und statische Assets mit immutable optimal cachen — mit fertigen Caddyfile-Konfigurationen.
Cache-Control in Caddy einrichten
Caddy hat eine besonders einfache und lesbare Konfigurationssyntax. Die header-Direktive kombiniert mit Named Matchern (@name) ermöglicht es, Cache-Control-Header für bestimmte Pfade in wenigen Zeilen zu setzen — ohne das always-Schlüsselwort, das Nginx benötigt.
Diese Anleitung zeigt die Konfiguration in vier Schritten: von Named Matchern für sensible Pfade über statische Assets bis zur vollständigen Caddyfile-Konfiguration.
Named Matcher für sensible Pfade definieren
Caddy Named Matcher ermöglichen es, Bedingungen einmal zu definieren und mehrfach zu verwenden. Der Matcher @sensitive für Dashboard, API und Account-Bereiche kann dann in der header-Direktive referenziert werden.
# Caddyfile — Cache-Control für sensible Endpunkte
ihre-domain.de {
# Named Matcher für sensible Pfade
@sensitive path /dashboard/* /api/* /account/*
header @sensitive Cache-Control "no-store, no-cache, must-revalidate"
# Named Matcher für Auth-Seiten
@auth path /login /logout /register /passwort-reset
header @auth Cache-Control "no-store"
reverse_proxy localhost:3000
}Anders als Nginx setzt Caddy die header-Direktive standardmäßig für alle Response-Codes — inklusive 4xx und 5xx. Das Äquivalent zu Nginxs always ist in Caddy das Standard-Verhalten.
Statische Assets optimal cachen (immutable)
Versionierte statische Assets — JavaScript-Bundles und CSS-Dateien mit Content-Hash im Dateinamen — können dauerhaft gecacht werden. Der @static-Matcher für das /assets/-Verzeichnis kombiniert mit immutable verhindert unnötige Revalidierungsanfragen.
# Statische Assets — maximales Caching (versioniert)
ihre-domain.de {
# Named Matcher für statische Assets mit Content-Hash
@static path /assets/* /static/*
header @static Cache-Control "public, max-age=31536000, immutable"
# Bilder ohne Hash: kürzere TTL
@images path *.ico *.jpg *.png *.svg *.webp
header @images Cache-Control "public, max-age=86400"
file_server
}Vollständige Caddyfile-Konfiguration
Die vollständige Konfiguration kombiniert alle Cache-Control-Regeln in einer Caddyfile: sensible Pfade mit no-store, statische Assets mit immutable, und personalisierte Bereiche mit private, no-cache plus Vary: Cookie.
# Caddyfile — Vollständige Cache-Control Konfiguration
ihre-domain.de {
@sensitive path /dashboard/* /api/* /account/*
header @sensitive Cache-Control "no-store, no-cache, must-revalidate"
@static path /assets/* /static/*
header @static Cache-Control "public, max-age=31536000, immutable"
# Vary für personalisierte Bereiche
@personalized path /profil/* /einstellungen/*
header @personalized Cache-Control "private, no-cache"
header @personalized Vary "Cookie"
reverse_proxy localhost:3000
}header-Direktiven in Caddy ist relevant: Wenn mehrere Matcher auf dieselbe URL passen, werden alle zutreffenden Direktiven ausgeführt. Stellen Sie sicher, dass @sensitive-Regeln nicht durch spätere @static-Regeln überschrieben werden. Konfiguration verifizieren
Caddy bietet mit caddy validate eine eingebaute Syntax-Prüfung. Nach dem Reload prüfen Sie, ob alle Cache-Control-Header korrekt gesetzt werden. Nutzen Sie curl für einen schnellen Check.
# 1. Caddy-Syntax prüfen
caddy validate --config /etc/caddy/Caddyfile
# 2. Konfiguration neu laden (ohne Downtime)
caddy reload --config /etc/caddy/Caddyfile
# 3. Dashboard-Endpunkt prüfen
curl -sI https://ihre-domain.de/dashboard/ | grep -i cache-control
# Erwartete Ausgabe: Cache-Control: no-store, no-cache, must-revalidate
# 4. Statische Assets prüfen
curl -sI https://ihre-domain.de/assets/main.abc123.js | grep -i cache-control
# Erwartete Ausgabe: Cache-Control: public, max-age=31536000, immutableDer Wolf-Agents Web Security Check prüft automatisch, ob Cache-Control für sensible Bereiche korrekt konfiguriert ist — als Teil der 166 Prüfpunkte mit 8 Punkten für Cache-Control.
Wie steht Ihre Domain bei Cache-Control?
Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 166 Prüfpunkte.
Häufig gestellte Fragen
Wie setze ich Cache-Control in Caddy?
In Caddy setzen Sie Cache-Control mit der header-Direktive in der Caddyfile. Kombiniert mit Named Matchern (@variablename) können Sie Header für bestimmte Pfade setzen: header @sensitive Cache-Control "no-store". Die header-Direktive kann sowohl Response-Header setzen als auch bestehende Header entfernen oder ersetzen.
Was sind Caddy Named Matcher?
Named Matcher in Caddy sind benannte Bedingungen, die mehrfach verwendet werden können. Sie werden mit @name definiert und können path, method, header und andere Kriterien kombinieren: @sensitive path /dashboard/* /api/* /account/*. Named Matcher können dann in verschiedenen Direktiven referenziert werden: header @sensitive ..., respond @sensitive ....
Setzt Caddy automatisch Cache-Control-Header?
Caddy setzt für file_server automatisch Cache-Control-Header: für statische Dateien wird Last-Modified und ETag gesetzt, aber kein Cache-Control. Für Reverse-Proxy-Konfigurationen (reverse_proxy) leitet Caddy die Header des Upstream-Servers weiter. Explizite Cache-Control-Header müssen über die header-Direktive gesetzt werden.
Wie unterscheidet sich Caddy von Nginx bei der Header-Konfiguration?
Caddy hat eine deutlich einfachere Konfigurationssyntax als Nginx. Wo Nginx add_header mit dem always-Keyword benötigt, reicht in Caddy ein einfaches header @matcher Cache-Control "value". Caddy setzt Header standardmäßig für alle Response-Codes, ohne dass ein spezielles Schlüsselwort nötig ist.
Kann ich Cache-Control in Caddy ohne Caddyfile über die API setzen?
Ja. Caddy hat eine JSON-basierte Admin-API, über die alle Konfigurationen auch ohne Caddyfile gesetzt werden können. Für Cache-Control-Header können Sie handler.response.headers.set in der JSON-Konfiguration verwenden. Die Caddyfile-Konfiguration ist jedoch einfacher zu lesen und zu warten.