Cache-Control für Nginx konfigurieren

Schritt-für-Schritt-Anleitung: Sensible Endpunkte mit no-store schützen, personalisierte Bereiche mit private absichern und statische Assets optimal cachen — mit fertigen Nginx-Konfigurationen.

Cache-Konfiguration prüfen Plattform entdecken

Nginx · Schritt für Schritt

Von Wolf-Agents Security Team · Aktualisiert: 18. März 2026

Cache-Control auf Nginx einrichten

Nginx ermöglicht es, Cache-Control-Header präzise per location-Block zu steuern. Das Schlüsselwort always in der add_header-Direktive ist entscheidend: ohne es setzt Nginx den Header nur bei 2xx- und 3xx-Antworten — fehlgeschlagene Logins (401, 403) wären dann nicht geschützt.

Diese Anleitung zeigt die Konfiguration in vier Schritten: von der Absicherung sensibler Endpunkte über personalisierte Bereiche bis zu optimaler Caching-Strategie für statische Assets.

Einführung in Cache-Control-Sicherheit

1 Schritt 1 von 4

Sensible Endpunkte absichern (no-store)

Login-Seiten, API-Endpunkte und Dashboard-Bereiche müssen mit Cache-Control: no-store abgesichert werden. Das Schlüsselwort always stellt sicher, dass der Header auch bei 4xx- und 5xx-Antworten gesetzt wird.

# nginx.conf — Cache-Control für sensible Endpunkte
server {
    listen 443 ssl;
    server_name ihre-domain.de;

    # Login-Seite: kein Caching
    location /login {
        add_header Cache-Control "no-store" always;
        proxy_pass http://backend;
    }

    # API-Endpunkte: kein Caching
    location /api/ {
        add_header Cache-Control "no-store" always;
        proxy_pass http://backend;
    }

    # Dashboard: kein Caching
    location /dashboard/ {
        add_header Cache-Control "no-store" always;
        proxy_pass http://backend;
    }
}

Warum always?

Nginx setzt add_header standardmäßig nur bei 2xx- und 3xx-Antworten. Bei fehlgeschlagenen Logins (401 Unauthorized, 403 Forbidden) würde der Header fehlen — ein potentielles Sicherheitsproblem, wenn der Browser die Fehlerseite cached.

2 Schritt 2 von 4

Personalisierte Bereiche mit private schützen

Personalisierte Seiten, die keine hochsensiblen Daten enthalten, können mit Cache-Control: no-cache, private abgesichert werden. private verhindert, dass CDNs und Proxys die Antwort cachen — der Browser-Cache darf sie behalten. Der Vary: Cookie-Header sorgt für nutzerspezifische Cache-Isolation.

# Personalisierte Bereiche — nur Browser-Cache erlaubt
location /konto/ {
    add_header Cache-Control "no-cache, private" always;

    # Vary sichert Cache-Isolation nach Cookie
    add_header Vary "Cookie" always;

    proxy_pass http://backend;
}

# Profil-Seite
location /profil {
    add_header Cache-Control "no-cache, private" always;
    add_header Vary "Cookie" always;
    proxy_pass http://backend;
}

Wenn Sie unsicher sind ob eine Seite sensible Daten enthält: setzen Sie no-store. Es ist besser zu restriktiv zu cachen als zu liberal. Performance-Einbußen durch fehlende Caches sind in den meisten Fällen vernachlässigbar.

3 Schritt 3 von 4

Statische Assets optimal cachen (immutable)

Versionierte statische Assets — JavaScript-Bundles und CSS-Dateien mit Content-Hash im Dateinamen — können dauerhaft gecacht werden. Das immutable-Keyword signalisiert Browsern, dass kein Revalidierungsversuch nötig ist, selbst beim manuellen Refresh (F5).

# Statische Assets — maximales Caching (versioniert)
location /static/ {
    # Versionierte Assets (main.abc123.js) — dauerhaft cachen
    add_header Cache-Control "public, max-age=31536000, immutable";
    root /var/www/html;
    try_files $uri =404;
}

# Assets ohne Hash — kürzere TTL
location ~* .(ico|jpg|png|svg|webp)$ {
    add_header Cache-Control "public, max-age=86400";
    root /var/www/html;
    try_files $uri =404;
}

immutable nur für Dateien verwenden, die sich niemals ändern — d.h. Dateien mit Content-Hash im Namen (z.B. main.4a8b2c.js). Für logo.png oder andere unveränderliche Dateinamen besser max-age=86400 ohne immutable nutzen.

4 Schritt 4 von 4

Konfiguration verifizieren

Nach dem Reload prüfen Sie, ob alle Cache-Control-Header korrekt gesetzt werden. Nutzen Sie curl für einen schnellen Check und die Browser DevTools (Network-Tab → Response Headers) für eine visuelle Prüfung.

# 1. Nginx-Syntax prüfen
sudo nginx -t

# 2. Konfiguration neu laden (ohne Downtime)
sudo systemctl reload nginx

# 3. Login-Endpunkt prüfen
curl -sI https://ihre-domain.de/login | grep -i cache-control
# Erwartete Ausgabe: Cache-Control: no-store

# 4. Statische Assets prüfen
curl -sI https://ihre-domain.de/static/main.abc123.js | grep -i cache-control
# Erwartete Ausgabe: Cache-Control: public, max-age=31536000, immutable

Wolf-Agents Scanner als Alternative

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

Auch verfügbar für:

Apache WordPress Next.js Cloudflare Express CaddyShopifyDemnächst

Wie steht Ihre Domain bei Cache-Control?

Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 166 Prüfpunkte.

Web Security Check starten Monitoring ab 199 EUR/Mo

Häufig gestellte Fragen

Wie setze ich Cache-Control in Nginx?

In Nginx setzen Sie Cache-Control mit der Direktive add_header in location-Blöcken. Das Schlüsselwort always stellt sicher, dass der Header auch bei Fehlerantworten (4xx, 5xx) gesetzt wird — wichtig für Login-Seiten, die 401 oder 403 zurückgeben können.

Was bedeutet always bei add_header in Nginx?

Ohne always setzt Nginx den Header nur bei 2xx- und 3xx-Antworten. Mit always wird er bei allen Statuscodes gesetzt. Für Cache-Control: no-store ist always wichtig, weil fehlgeschlagene Logins (401, 403) ebenfalls nicht gecacht werden sollen.

Überschreiben location-Blöcke in Nginx Eltern-Header?

Ja. In Nginx erben verschachtelte location-Blöcke keine add_header-Direktiven vom Eltern-Block. Wenn Sie im Server-Block einen Standard-Header setzen und in einem Location-Block einen anderen, müssen Sie alle gewünschten Header im innersten Block wiederholen.

Wie konfiguriere ich Cache-Control für einen Nginx Reverse Proxy?

Bei Nginx als Reverse Proxy können Sie proxy_hide_header Cache-Control nutzen, um Upstream-Header zu entfernen, und dann add_header Cache-Control "..." always setzen. So überschreiben Sie die Cache-Einstellungen des Backends zuverlässig.

Brauche ich auch den Expires-Header?

Cache-Control hat Vorrang vor Expires in modernen Browsern und sollte immer gesetzt werden. Für maximale Kompatibilität können Sie Expires zusätzlich setzen, aber Cache-Control allein ist ausreichend für alle Browser ab IE8+.