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.

Nginx · Schritt für Schritt

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.

1 Schritt 1 von 4

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 Origin-Agent-Cluster
# /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;
}
document.domain wird deaktiviert

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.

2 Schritt 2 von 4

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.

/etc/nginx/conf.d/http-redirect.conf 301 Redirect
# 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
Mit HSTS (Strict-Transport-Security) eliminieren Sie künftige HTTP-Anfragen ganz — der Browser ruft die Seite dann direkt über HTTPS auf, ohne den Redirect.
3 Schritt 3 von 4

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.

/etc/nginx/conf.d/www-redirect.conf WWW → non-WWW
# 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;
}
SSL-Zertifikat muss beide Varianten abdecken — entweder als Wildcard-Zertifikat (*.example.com) oder als SAN-Zertifikat mit example.com und www.example.com. Let's Encrypt unterstützt beide Optionen.
4 Schritt 4 von 4

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.

/etc/nginx/nginx.conf Aufräumen
# 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
Konfiguration verifizieren

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.