Erweiterte Header auf Hetzner konfigurieren

Origin-Agent-Cluster, HTTPS-Redirect und WWW-Normalisierung auf Ihrem Hetzner Cloud Server einrichten — die letzten Optimierungen für eine vollständige Security-Header-Konfiguration.

Header prüfen Plattform entdecken

Hetzner · Schritt für Schritt

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

Erweiterte Header auf Hetzner Cloud Servern

Erweiterte Header umfassen die letzten Stellschrauben für eine vollständige Security-Header-Konfiguration: Origin-Agent-Cluster isoliert Ihre Origin in einem eigenen Browserprozess, HTTPS-Redirects erzwingen verschlüsselte Verbindungen und die WWW-Normalisierung verhindert, dass Ihre Domain unter zwei verschiedenen Origins erreichbar ist. Im Wolf-Agents Web Security Check fließen diese Header mit 4 von 166 Punkten in die Bewertung ein.

Auf einem Hetzner Cloud Server haben Sie volle Kontrolle über Nginx oder Apache. Die besondere Herausforderung ist die korrekte Redirect-Kette: HTTP muss auf HTTPS weiterleiten, WWW auf non-WWW (oder umgekehrt) — ohne Redirect-Loops. Wenn Sie zusätzlich den Hetzner Load Balancer nutzen, übernimmt dieser möglicherweise die TLS-Terminierung und leitet Requests als HTTP an das Backend weiter, was die Redirect-Logik beeinflusst.

Ausführliche Einführung in Erweiterte Header

1 Schritt 1 von 3

Origin-Agent-Cluster und Redirects in Nginx

Origin-Agent-Cluster mit dem Wert ?1 weist den Browser an, Ihre Origin in einem eigenen Agenten-Cluster zu isolieren. Das verhindert, dass andere Origins über document.domain auf Ihre Seite zugreifen können — eine zusätzliche Schutzebene gegen Cross-Origin-Angriffe. Der Header ist ein einfaches Boolean (?1 = aktiviert).

Nginx — Origin-Agent-Cluster

# /etc/nginx/conf.d/advanced-headers.conf

# Origin-Agent-Cluster: Isoliert die Origin in einem eigenen Prozess
add_header Origin-Agent-Cluster "?1" always;

Nginx — HTTP → HTTPS

# HTTP → HTTPS Redirect (Port 80 → 443)
server {
    listen 80;
    listen [::]:80;
    server_name ihre-domain.de www.ihre-domain.de;

    # Let's Encrypt ACME-Challenge durchlassen
    location /.well-known/acme-challenge/ {
        root /var/www/certbot;
    }

    # Alles andere: 301 auf HTTPS
    location / {
        return 301 https://ihre-domain.de$request_uri;
    }
}

Nginx — WWW-Normalisierung

# WWW → non-WWW Redirect (oder umgekehrt)
server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name www.ihre-domain.de;

    ssl_certificate /etc/letsencrypt/live/ihre-domain.de/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/ihre-domain.de/privkey.pem;

    return 301 https://ihre-domain.de$request_uri;
}

# Hauptserver-Block
server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name ihre-domain.de;

    ssl_certificate /etc/letsencrypt/live/ihre-domain.de/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/ihre-domain.de/privkey.pem;

    # Origin-Agent-Cluster
    add_header Origin-Agent-Cluster "?1" always;

    # Ihre Anwendung
    location / {
        proxy_pass http://127.0.0.1:3000;
    }
}

Redirect-Reihenfolge

Die optimale Kette ist: http://www. → https://ihre-domain.de (ein Redirect). Der HTTP-Block leitet alle Varianten direkt auf die finale HTTPS-URL weiter, nicht erst auf https://www.. Das spart einen Redirect-Hop und verbessert die Performance.

2 Schritt 2 von 3

Apache-Konfiguration mit mod_headers und mod_rewrite

In Apache benötigen Sie mod_headers für den Origin-Agent-Cluster-Header und mod_rewrite für die Redirects. Aktivieren Sie beide Module mit sudo a2enmod headers rewrite. Die ACME-Challenge für Let's Encrypt muss vom Redirect ausgenommen werden, damit Zertifikatserneuerungen funktionieren.

# /etc/apache2/conf-available/advanced-headers.conf
<IfModule mod_headers.c>
    # Origin-Agent-Cluster
    Header always set Origin-Agent-Cluster "?1"
</IfModule>

# HTTP → HTTPS Redirect
<VirtualHost *:80>
    ServerName ihre-domain.de
    ServerAlias www.ihre-domain.de

    # Let's Encrypt ACME-Challenge
    Alias /.well-known/acme-challenge/ /var/www/certbot/.well-known/acme-challenge/

    RewriteEngine On
    RewriteCond %{REQUEST_URI} !^/.well-known/acme-challenge/
    RewriteRule ^(.*)$ https://ihre-domain.de$1 [R=301,L]
</VirtualHost>

# WWW → non-WWW Redirect
<VirtualHost *:443>
    ServerName www.ihre-domain.de

    SSLEngine On
    SSLCertificateFile /etc/letsencrypt/live/ihre-domain.de/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/ihre-domain.de/privkey.pem

    RewriteEngine On
    RewriteRule ^(.*)$ https://ihre-domain.de$1 [R=301,L]
</VirtualHost>

SSL-Zertifikat für WWW

Der WWW-Redirect-VirtualHost benötigt ein eigenes SSL-Zertifikat (oder ein SAN/Wildcard-Zertifikat, das beide Domains abdeckt). Ohne gültiges Zertifikat auf www.ihre-domain.de zeigt der Browser einen Zertifikatsfehler, bevor der Redirect greifen kann.

3 Schritt 3 von 3

Verifizierung

Prüfen Sie den Origin-Agent-Cluster-Header, die Redirect-Kette und die finale HTTPS-URL. Besonders wichtig: Die Redirect-Kette darf keine Loops enthalten und sollte maximal 2 Hops umfassen (HTTP→HTTPS und WWW→non-WWW).

# Nginx-Konfiguration testen und laden
sudo nginx -t && sudo systemctl reload nginx

# Origin-Agent-Cluster prüfen
curl -sI https://ihre-domain.de | grep -i origin-agent-cluster
# Erwartet: origin-agent-cluster: ?1

# HTTP → HTTPS Redirect prüfen
curl -sI http://ihre-domain.de | head -5
# Erwartet: HTTP/1.1 301 Moved Permanently
# Location: https://ihre-domain.de/

# WWW → non-WWW Redirect prüfen
curl -sI https://www.ihre-domain.de | head -5
# Erwartet: HTTP/2 301
# location: https://ihre-domain.de/

# Vollständige Redirect-Kette prüfen (keine Loops)
curl -sIL http://www.ihre-domain.de 2>&1 | grep -E "(HTTP/|location:)"
# Erwartet: maximal 2 Redirects (HTTP→HTTPS, WWW→non-WWW)

Kombinieren Sie den HTTPS-Redirect mit HSTS (Strict-Transport-Security). HSTS sorgt dafür, dass der Browser nach dem ersten Besuch automatisch HTTPS verwendet — ohne den Umweg über den HTTP-Redirect. Siehe HSTS auf Hetzner konfigurieren.

Häufige Fehler bei erweiterten Headern auf Hetzner

Redirect-Loops zwischen HTTP, HTTPS und WWW

Der häufigste Fehler: HTTP leitet auf https://www., der WWW-Block leitet auf https://non-www, und ein fehlkonfigurierter Block leitet zurück auf https://www.. Lösung: Im HTTP-Block (Port 80) direkt auf die finale URL weiterleiten (https://ihre-domain.de), nicht auf die WWW-Variante. Testen Sie mit curl -sIL und prüfen Sie die Anzahl der Redirects.

Origin-Agent-Cluster bricht Same-Origin-Kommunikation

Origin-Agent-Cluster: ?1 deaktiviert die Möglichkeit, document.domain zu setzen. Wenn Ihre Anwendung Subdomains nutzt, die über document.domain kommunizieren (z.B. app.ihre-domain.de greift auf api.ihre-domain.de zu), wird diese Kommunikation blockiert. Moderne Alternativen: postMessage(), CORS oder die Channel Messaging API.

Hetzner Load Balancer übernimmt Redirects

Wenn Sie den Hetzner Load Balancer mit TLS-Terminierung verwenden, leitet der LB Traffic als HTTP an das Backend weiter. Der Backend-Server sieht dann nur Port 80 und würde in eine Redirect-Schleife geraten. Lösung: Prüfen Sie den X-Forwarded-Proto-Header statt des Ports. In Nginx nutzen Sie eine Bedingung auf $http_x_forwarded_proto, die bei "http" einen 301-Redirect auf die HTTPS-URL auslöst. Alternativ konfigurieren Sie den Redirect direkt am Load Balancer.

Compliance-Relevanz

HTTPS-Enforcement und Origin-Isolation sind grundlegende Anforderungen moderner Sicherheitsstandards. Ohne HTTPS-Redirect können Nutzer versehentlich unverschlüsselt kommunizieren — ein direkter Verstoß gegen Datenschutzprinzipien.

NIS2 Artikel 21(j) fordert den Einsatz von Verschlüsselung. HTTPS-Redirects stellen sicher, dass alle Verbindungen verschlüsselt sind. Origin-Agent-Cluster ergänzt dies durch Prozess-Isolation im Browser.

BSI Der BSI IT-Grundschutz (APP.3.1) empfiehlt die Umleitung von HTTP auf HTTPS als Pflichtmaßnahme für Webserver. Die WWW-Normalisierung verhindert Cookie-Scoping-Probleme zwischen WWW- und non-WWW-Origin.

Auch verfügbar für:

Nginx Apache WordPress Next.js Cloudflare Express Caddy Shopify TYPO3 Laravel

Wie steht Ihre Domain bei Erweiterte Header?

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

Web Security Check starten Monitoring ab 199 EUR/Mo