Erweiterte Header für Nginx konfigurieren
Schritt-für-Schritt: Origin-Agent-Cluster für Prozess-Isolation, HTTPS-Redirect per 301, WWW-Normalisierung und veraltete Header entfernen — mit fertigen Nginx-Konfigurationen.
Erweiterte Header auf Nginx
Nginx ist der weltweit meistgenutzte Webserver und Reverse Proxy. Dank der add_header-Direktive und separaten Server-Blöcken für Port 80 lassen sich alle erweiterten Sicherheitsmaßnahmen in wenigen Zeilen Konfiguration umsetzen. Diese Anleitung deckt vier Themen ab: Origin-Agent-Cluster für Prozess-Isolation, HTTPS-Redirect mit 301, WWW-Normalisierung und das Entfernen veralteter Header.
Alle Beispiele folgen dem Nginx-Antipattern-Guide: Kein if ($scheme), kein rewrite für einfache Redirects — stattdessen separate Server-Blöcke mit return. Verwenden Sie immer das always-Keyword, damit Header auch bei Fehlerseiten (404, 500) gesetzt werden. Die erweiterten Header bringen 4 von 166 Punkten im Wolf-Agents Web Security Check.
Origin-Agent-Cluster setzen
Der Header Origin-Agent-Cluster: ?1 weist den Browser an, die Seite in einem eigenen Prozess basierend auf der Origin zu isolieren. Das verhindert Spectre-Seitenkanal-Angriffe zwischen Subdomains. In Nginx wird er mit add_header gesetzt — das Schlüsselwort always stellt sicher, dass der Header auch bei Fehlerantworten übertragen wird.
# /etc/nginx/conf.d/security-headers.conf
server {
listen 443 ssl http2;
server_name example.com;
# Prozess-Isolation gegen Spectre (RFC 8941 Structured Header)
add_header Origin-Agent-Cluster "?1" always;
# Server-Token minimieren (Versionsnummer entfernen)
server_tokens off;
} Origin-Agent-Cluster deaktiviert document.domain-Setter. Falls Ihre Anwendung Cross-Subdomain-Kommunikation über document.domain nutzt, müssen Sie auf postMessage oder CORS umstellen. Chrome 115+ deaktiviert dies ohnehin standardmäßig.
HTTPS-Redirect (301) konfigurieren
HTTP-Anfragen müssen mit einem 301 (Moved Permanently) auf HTTPS weitergeleitet werden. Nginx-Best-Practice: Einen eigenen Server-Block für Port 80 anlegen und mit return 301 alle Anfragen umleiten. Kein if ($scheme = http) — das ist ein Nginx-Antipattern.
# Separater Server-Block für HTTP → HTTPS Redirect
server {
listen 80;
listen [::]:80;
server_name example.com www.example.com;
# Permanenter Redirect — Browser cached diesen dauerhaft
return 301 https://$host$request_uri;
}
# KEIN if ($scheme = http) — "if is evil" in Nginx! | Methode | Nginx-Empfehlung | Warum |
|---|---|---|
return 301 https://... | Empfohlen | Effizient, klar, kein Regex-Overhead |
if ($scheme = http) | Vermeiden | "if is evil" — subtile Bugs möglich |
rewrite ^ https://... | Vermeiden | Langsamer als return, veraltet |
Strict-Transport-Security) eliminieren Sie künftige HTTP-Anfragen ganz — der Browser ruft die Seite dann direkt über HTTPS auf, ohne den Redirect. WWW-Normalisierung einrichten
www.example.com und example.com sind für Suchmaschinen zwei verschiedene Domains. Ohne 301-Weiterleitung auf eine kanonische Variante verteilt sich der SEO-Wert. Die empfohlene Variante für moderne Websites ist non-www. Richten Sie einen separaten Server-Block für die www-Variante ein.
# WWW → non-WWW Normalisierung (301 Redirect)
server {
listen 443 ssl http2;
server_name www.example.com;
return 301 https://example.com$request_uri;
}
# Optimiert: HTTP www → HTTPS non-www in einem Schritt
server {
listen 80;
server_name www.example.com;
return 301 https://example.com$request_uri;
} *.example.com) oder als SAN-Zertifikat mit example.com und www.example.com. Let's Encrypt unterstützt beide Optionen. Veraltete Header entfernen
Einige Header sollten nicht gesetzt, sondern entfernt werden. X-XSS-Protection wurde 2023 aus allen Browsern entfernt — der Header hat keine Wirkung und kann in alten Browsern sogar XSS ermöglichen. X-Powered-By und der Server-Header verraten Technologie-Details und gehören minimiert oder entfernt.
# Veraltete Header entfernen (ngx_http_headers_more Modul)
more_clear_headers Server;
more_clear_headers X-Powered-By;
# Ohne headers_more: Versionsnummer aus Server-Header entfernen
server_tokens off;
# X-XSS-Protection NICHT setzen — in allen Browsern entfernt (2023)
# add_header X-XSS-Protection "1; mode=block"; ← FALSCH!
# Konfiguration prüfen und neu laden
sudo nginx -t && sudo systemctl reload nginx Nach dem Reload prüfen: curl -sI https://example.com | grep -iE "(origin-agent|server|x-powered|x-xss)". Origin-Agent-Cluster sollte erscheinen, X-Powered-By und X-XSS-Protection sollten fehlen.
Wie steht Ihre Domain bei Erweiterte Header?
Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 166 Prüfpunkte.
Häufig gestellte Fragen
Wie setze ich Origin-Agent-Cluster in Nginx?
Mit der Direktive add_header Origin-Agent-Cluster "?1" always; im server- oder location-Block. Das Schlüsselwort always stellt sicher, dass der Header auch bei Fehlerantworten (4xx, 5xx) gesendet wird. Der Wert ?1 ist die Structured-Header-Schreibweise für "true" gemäß RFC 8941.
Warum sollte der HTTPS-Redirect in Nginx ein 301 und kein 302 sein?
Ein 301 (Moved Permanently) wird von Browsern dauerhaft gecacht — nach dem ersten Aufruf sendet der Browser keine HTTP-Anfragen mehr. Ein 302 ist temporär: Der Browser fragt jedes Mal über HTTP an, was ein kurzes Zeitfenster für Man-in-the-Middle-Angriffe öffnet und unnötige Latenz erzeugt.
Warum einen eigenen Server-Block für Port 80 statt einer if-Direktive?
Nginx-Dokumentation und Best Practices raten von if ($scheme = http) ab — "if is evil" ist ein bekannter Nginx-Antipattern. Ein separater Server-Block für Port 80 mit return 301 ist effizienter, klarer und vermeidet subtile Bugs bei komplexen Konfigurationen.
Wie entferne ich den Server-Header in Nginx?
Mit server_tokens off; im http- oder server-Block entfernt Nginx die Versionsnummer aus dem Server-Header (z.B. "nginx/1.24.0" → "nginx"). Für eine vollständige Entfernung benötigen Sie das Modul ngx_http_headers_more (more_clear_headers Server;) oder OpenResty.
Verursacht die WWW-Normalisierung doppelte Redirects?
Nein, wenn Sie es richtig konfigurieren. Der Port-80-Block leitet zuerst auf HTTPS um. Der HTTPS-Server-Block für www leitet dann auf non-www um. Idealerweise kombinieren Sie beides: Der Port-80-Block leitet http://www.example.com direkt auf https://example.com weiter — ein einziger Redirect.
Muss ich nginx -t vor dem Reload ausführen?
Ja, immer. nginx -t prüft die Syntax und Konfigurationslogik ohne den laufenden Server zu beeinflussen. Erst nach erfolgreichem Test: systemctl reload nginx. Ein fehlerhafter Reload kann bei nginx -s reload dazu führen, dass die alte Konfiguration weiter läuft — ein Syntaxfehler hingegen verhindert den Start beim nächsten Neustart.
Gilt add_header in Nginx für alle Location-Blöcke?
Nein — das ist ein häufiger Nginx-Fehler. add_header im server-Block wird nicht automatisch in location-Blöcke vererbt, wenn der location-Block eigene add_header-Direktiven hat. Verwenden Sie add_header in jedem relevanten location-Block oder nutzen Sie die Direktive im http-Block mit Bedacht.