Nginx-Konfiguration, die Websites schnell hält

Veröffentlicht am 19. September 2026

Eine Website kann vollkommen gesund aussehen, bis ein kleiner Fehler in der Nginx-Konfiguration ein routinemäßiges Deployment in einen 502-Fehler, eine SSL-Warnung oder eine Redirect-Schleife verwandelt, die Besucher nirgendwohin Sinnvolles führt. Nginx ist schnell und zuverlässig, aber auch anspruchsvoll: Eine einzige Direktive an der falschen Stelle kann das Verhalten einer ganzen Website verändern. Die gute Nachricht ist, dass ein sauberer Ansatz die Nginx-Konfiguration deutlich weniger rätselhaft macht.

Dieser Leitfaden konzentriert sich auf die Einstellungen, die beim Hosting von Websites am wichtigsten sind: Serverblöcke, PHP-Verarbeitung, HTTPS, Redirects, statische Dateien, Caching und sicheres Testen. Sie müssen nicht jede Nginx-Direktive auswendig lernen. Sie müssen verstehen, welche Entscheidungen sich auf Ihre Website auswirken und wie Sie sie überprüfen, bevor sie sich auf Ihre Besucher auswirken.

Mit einem klaren Layout der Nginx-Konfiguration beginnen

Die meisten Linux-Installationen trennen globale Einstellungen von individuellen Website-Einstellungen. Die Hauptkonfigurationsdatei, die sich häufig unter /etc/nginx/nginx.conf befindet, steuert Worker-Prozesse, Protokollierung, Komprimierung und eingebundene Konfigurationsverzeichnisse. Einzelne Websites befinden sich normalerweise in einem Verzeichnis wie sites-available, sites-enabled oder conf.d.

Diese Trennung ist aus einem praktischen Grund nützlich: Globale Einstellungen sollten vorsichtig und selten geändert werden, während Einstellungen auf Website-Ebene regelmäßige Aufmerksamkeit benötigen. Eine neue Domain, eine Staging-Website oder eine Redirect-Regel gehört in den Serverblock dieser Website, nicht in die Hauptdatei.

Bevor Sie etwas ändern, identifizieren Sie die aktive Konfiguration und testen Sie sie:

bash nginx -t

Wenn der Test erfolgreich ist, laden Sie Nginx neu, ohne aktive Verbindungen zu unterbrechen:

bash systemctl reload nginx

Verwenden Sie reload für normale Konfigurationsänderungen. Ein vollständiger Neustart ist manchmal notwendig, aber nicht der erste Schritt, wenn Sie einen virtuellen Host aktualisieren. Kleine Gewohnheiten wie diese verhindern, dass aus einer Fünf-Minuten-Aufgabe ein nächtlicher Wiederherstellungseinsatz wird.

Einen Serverblock pro Website erstellen

Ein Serverblock teilt Nginx mit, welche Domain er bedient, wo Website-Dateien gespeichert sind und wie Anfragen verarbeitet werden sollen. Betrachten Sie ihn als Empfang für eine einzelne Website. Wenn mehrere Domains einen Server gemeinsam nutzen, sorgt ein sauberer Serverblock dafür, dass der Traffic am richtigen Ort ankommt.

Eine einfache HTTP-Website könnte so aussehen:

server {
    listen 80;
    server_name example.com www.example.com;

    root /var/www/example.com/public;
    index index.php index.html;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }
}

Der Wert server_name sollte jeden Hostnamen auflisten, den Sie bedienen möchten. Wenn Besucher sowohl die Root-Domain als auch www erreichen können, schließen Sie beide ein und entscheiden Sie dann per Redirect, welche davon kanonisch werden soll.

Der Pfad root muss auf das Verzeichnis verweisen, das die öffentlichen Webdateien enthält, nicht unbedingt auf den obersten Ordner des Projekts. Bei WordPress ist dies oft der Ordner, in dem wp-admin, wp-content und wp-includes vorhanden sind. Bei Laravel und ähnlichen Frameworks ist dies typischerweise das Verzeichnis public. Wenn Nginx auf den falschen Ordner zeigt, können Dateien offengelegt werden, die niemals öffentlich verfügbar sein sollten.

Die Regel try_files verdient Aufmerksamkeit. Sie prüft, ob eine angeforderte Datei oder ein angefordertes Verzeichnis existiert, bevor nicht zugeordnete Anfragen an die Anwendung weitergeleitet werden. Das ist entscheidend für WordPress-Permalinks und viele moderne PHP-Anwendungen. Ohne sie funktionieren Seiten möglicherweise nur, wenn Besucher die vollständige URL mit angehängtem index.php verwenden. Nicht ideal und kein Problem, das Kunden zuerst melden sollen.

Die Falle des Default-Servers vermeiden

Nginx benötigt einen Default-Server für Anfragen, die keinem konfigurierten Hostnamen entsprechen. Wenn die falsche Website als Standard festgelegt ist, kann eine unbekannte Domain oder eine direkte IP-Anfrage die Website einer anderen Person anzeigen. Das ist im besten Fall verwirrend und im schlimmsten Fall riskant.

Verwenden Sie auf Servern mit mehreren Websites einen einfachen Default-Server, der keinen nützlichen Inhalt zurückgibt, etwa eine 404-Antwort. Behalten Sie echte Websites in expliziten Serverblöcken mit ihren eigenen Werten für server\_name. Das ist eine kleine Grenze, die die Verwaltung eines gemeinsam genutzten Servers erleichtert.

PHP ohne Rätselraten konfigurieren

Nginx verarbeitet PHP nicht eigenständig. Es leitet PHP-Anfragen an PHP-FPM weiter, das den Code ausführt. Die Verbindung erfolgt normalerweise über einen Unix-Socket oder einen lokalen TCP-Port.

Ein üblicher PHP-Location-Block sieht so aus:

location ~ \.php$ {
    try_files $uri =404;

    include fastcgi_params;
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;

    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}

Die PHP-Version und der Socket-Pfad variieren je nach Server. Wenn Nginx nach einem PHP-Update einen 502 Bad Gateway-Fehler zurückgibt, ist der Socket-Pfad einer der ersten Punkte, die Sie prüfen sollten. PHP-FPM ist möglicherweise gestoppt, führt eine andere Version aus oder lauscht an einem anderen Ort als dem in Nginx definierten Pfad.

Die Zeile try_files $uri =404; lohnt es sich ebenfalls beizubehalten. Sie verhindert, dass Nginx Anfragen für nicht vorhandene PHP-Dateien an den PHP-Prozessor sendet. Das verbessert sowohl die Sicherheit als auch die Fehlerbehandlung.

Fügen Sie bei WordPress keine weit gefassten Regeln hinzu, die aus zufälligen Forenbeiträgen kopiert wurden, es sei denn, Sie wissen, warum sie benötigt werden. WordPress funktioniert bereits gut mit einer sauberen try_files-Einrichtung, korrekter PHP-Verarbeitung und nur dort beschreibbaren Berechtigungen, wo WordPress sie benötigt. Mehr Regeln bedeuten nicht automatisch eine bessere Konfiguration.

HTTPS zum Standardpfad machen

Jede öffentliche Website sollte HTTPS bereitstellen und HTTP-Traffic auf die sichere Version umleiten. Das übliche Muster ist ein HTTP-Serverblock, der nur die Umleitung ausführt, plus ein separater HTTPS-Block, der die Website bereitstellt.

server {
    listen 80;
    server_name example.com www.example.com;

    return 301 https://example.com$request_uri;
}

Der HTTPS-Serverblock lauscht dann auf Port 443 und enthält die Pfade zum Zertifikat und zum privaten Schlüssel. Zertifikatsdateien hängen davon ab, wie SSL bereitgestellt wird, aber das Prinzip bleibt gleich: Behalten Sie die Zertifikatskonfiguration innerhalb der Website, die sie verwendet.

Ein permanenter 301-Redirect ist angemessen, sobald Sie sich beim Ziel sicher sind. Während einer aktiven Migration oder eines kurzfristigen Tests kann ein 302-Redirect sicherer sein, weil Browser ihn nicht so aggressiv cachen. Dies ist einer der Fälle, in denen die technisch am stärksten wirkende Option operativ nicht immer die richtige Wahl ist.

Wählen Sie außerdem einen bevorzugten Hostnamen. Leiten Sie entweder www auf die Root-Domain oder die Root-Domain auf www um. Beides ohne konsistenten Redirect bereitzustellen, kann Analytics aufteilen, doppelte Seiten für Suchmaschinen erzeugen und das Verhalten von Cookies schwerer diagnostizierbar machen.

Statische Dateien effizient und sicher bereitstellen

Bilder, CSS, JavaScript, Schriftarten und herunterladbare Dateien sollten keine PHP-Ressourcen verbrauchen, wenn Nginx sie direkt ausliefern kann. Legen Sie ein sinnvolles Browser-Caching für Dateien fest, die sich selten ändern:

location ~* \.(css|js|jpg|jpeg|png|gif|svg|webp|ico|woff2)$ {
    expires 30d;
    add_header Cache-Control "public";
}

Dreißig Tage sind ein sinnvoller Ausgangspunkt, kein Gesetz. Wenn Ihre Dateinamen Versionsnummern oder gehashte Dateinamen enthalten, kann längeres Caching sehr gut funktionieren. Wenn derselbe Dateiname häufig ersetzt wird, kann ein langer Cache dazu führen, dass Besucher ein älteres Design oder Skript sehen. Caching ist immer ein Ausgleich zwischen Geschwindigkeit und der Frage, wie schnell Änderungen sichtbar werden müssen.

Legen Sie versteckte Dateien nicht versehentlich offen. Eine einfache Regel kann Anfragen nach Dotfiles blockieren und dabei das für die Zertifikatsvalidierung verwendete Verzeichnis .well-known zulassen:

location ~ /\.(?!well-known(?:/|$)) {
    deny all;
}

Abhängig von Ihrer Zertifikatseinrichtung benötigen Sie möglicherweise eine spezifische Ausnahme für .well-known. Testen Sie das Erneuerungsverhalten, nachdem Sie Zugriffsregeln strenger gemacht haben. Sicherheitsregeln sollten die Angriffsfläche verringern, nicht stillschweigend Dienste beeinträchtigen, auf die Sie angewiesen sind.

Security-Header im Kontext verwenden

Response-Header können den browserseitigen Schutz verbessern, müssen aber getestet werden. Häufige Beispiele sind X-Content-Type-Options nosniff, Referrer-Policy und Content-Security-Policy. Der letzte davon ist leistungsfähig und leicht falsch zu konfigurieren. Eine strenge Richtlinie kann Skripte, Schriftarten, Zahlungs-Widgets, Analytics oder eingebettete Inhalte blockieren, wenn sie ohne Verständnis der Abhängigkeiten der Website eingeführt wird.

Beginnen Sie mit Headern, die einen klaren Zweck und ein geringes Risiko haben, und fügen Sie dann eine Content-Security-Policy im Report-Only-Modus hinzu, wenn Ihre Anwendung dies unterstützt. Das Ziel ist nicht, einen beeindruckenden Stapel von Direktiven zu sammeln. Das Ziel ist, reale Risiken zu verringern, ohne die Seiten zu beeinträchtigen, die Menschen verwenden müssen.

Rate Limiting kann auch bei missbräuchlichem Traffic und Login-Angriffen helfen, insbesondere bei WordPress-Login-Endpunkten. Aber aggressive Limits können legitime Nutzer hinter gemeinsam genutzten Büronetzwerken oder Mobilfunkanbietern blockieren. Prüfen Sie Protokolle und passen Sie die Einstellungen anhand tatsächlicher Traffic-Muster an, anstatt Zahlen zu wählen, die nur streng klingen.

Änderungen testen, als wären sie wichtig

Jede Nginx-Änderung sollte derselben kurzen Routine folgen: die aktuelle Datei sichern oder kopieren, eine gezielte Änderung vornehmen, nginx -t ausführen, Nginx neu laden und die Website im Browser und über die Befehlszeile testen. Prüfen Sie die vorgesehene Domain, die nicht-kanonische Domain, HTTP, HTTPS und eine von PHP verarbeitete Seite.

Wenn etwas fehlschlägt, lesen Sie die Fehlerprotokolle, bevor Sie die Konfiguration neu schreiben. Nginx-Zugriffs- und Fehlerprotokolle zeigen oft, ob das Problem eine fehlende Datei, eine falsche Berechtigung, eine fehlgeschlagene Upstream-Verbindung oder ein fehlerhafter Redirect ist. Rätselraten kann drei neue Probleme schaffen, ohne auch nur eines zu beheben.

Ein Control Panel kann einen Großteil dieser manuellen Arbeit abnehmen, indem es Einstellungen auf Website-Ebene, Zertifikate, PHP-Versionen und Protokolle an einem Ort erstellt und organisiert. FASTPANEL ist für diesen praktischen Mittelweg konzipiert: Sie behalten die Kontrolle über Ihre Hosting-Umgebung, ohne jede Domain-Änderung in ein archäologisches Konfigurationsprojekt zu verwandeln.

Eine gute Nginx-Konfiguration bedeutet nicht, die längste Datei zu erstellen oder jede verfügbare Direktive zu verwenden. Es geht darum, jede Website vorhersehbar zu machen: Die richtige Domain erreicht die richtigen Dateien, PHP hat einen gesunden Upstream, HTTPS wird erzwungen, statische Inhalte sind effizient, und Änderungen werden getestet, bevor Besucher auf sie treffen. Sobald dieses Fundament steht, wird die Verwaltung eines wachsenden Servers deutlich weniger dramatisch – genau so, wie es sein sollte.