Nginx-Konfigurationsprüfer
Füge eine nginx.conf ein und finde Syntaxfehler, falsch platzierte Direktiven und häufige Sicherheitsfehler — bevor du nginx neu lädst.
Lege hier eine .conf-Datei ab, oder füge den Konfigurationstext oben ein.
Alles läuft in deinem Browser — deine Konfiguration wird niemals an einen Server hochgeladen.
Füge oben eine nginx-Konfiguration ein (oder lade das Beispiel), dann erscheinen hier die Prüfergebnisse.
Verwendet die RegExp-Engine von JavaScript, nicht die echte PCRE-Engine von nginx — sehr ähnlich, aber nicht identisch (keine possessiven Quantoren/atomaren Gruppen).
nginx-Konfigurationsfehler finden, bevor sie in Produktion gehen
Eine fehlerhafte nginx.conf meldet sich meist auf eine von zwei unangenehmen Arten: `nginx -t` weigert sich mit einem kryptischen Zeilenfehler, die Konfiguration neu zu laden, oder – schlimmer – ein `reload` behält stillschweigend die alte (funktionierende) Konfiguration im Speicher, während die neue kaputt auf der Platte liegt. Dann scheint alles in Ordnung, bis zum nächsten vollständigen Neustart. Beides lässt sich vermeiden, wenn dieselbe Art von Fehlern schon beim Bearbeiten auffällt.
Der häufigste echte Fehler in einer nginx.conf ist nicht exotisch, sondern ein vergessenes Semikolon. Weil die Grammatik von nginx nur `;`, `{` und `}` beachtet (nicht aber Zeilenumbrüche), erzeugt ein fehlendes `;` nicht die klare Meldung „Zeile 12: ; erwartet“ wie bei den meisten modernen Parsern. Stattdessen werden Name und Argumente der nächsten Direktive stillschweigend als zusätzliche Argumente der vorherigen geschluckt, manchmal ganz ohne Fehler, bis weiter unten etwas seltsam reagiert. Die Zeilenumbruch-Heuristik dieses Tools achtet gezielt auf dieses Muster – ein bekannter Direktivenname mitten in einer Argumentliste in einer neuen Quellzeile – und meldet es, bevor daraus ein Support-Ticket wird.
Die Platzierung von Direktiven ist die zweite häufige Falle: `proxy_pass` ergibt nur in einem `location`- (oder `if`-)Block Sinn, `listen`/`server_name` nur in `server` und so weiter. Der Parser von nginx lehnt eine Direktive aber nicht ab, nur weil sie an ungewöhnlicher Stelle steht, wenn er den Namen irgendwo anders kennt, und die Fehlermeldungen verweisen auf die interne Direktiven-Registry von nginx statt auf „das hast du falsch verschachtelt“. Dieser Prüfer vergleicht die Direktive direkt mit der Kontexttabelle, sodass ein versehentlich auf `http`-Ebene (außerhalb jedes `server`/`location`) stehendes `proxy_pass` mit der genauen Zeile gemeldet wird, nicht nur mit „die Konfiguration ließ sich nicht laden“.
Neben der Syntax haben ein paar kleine Konfigurationsentscheidungen überproportionale Sicherheitsfolgen: Bleibt `server_tokens` auf dem Standard (`on`), verrät jeder Antwortheader und jede Standard-Fehlerseite deine exakte nginx-Version – kostenlose Aufklärung für jeden, der nach einer versionsspezifischen CVE sucht. Und die URL-dekodierte Variable `$uri` in `return`/`rewrite`/`add_header` (statt des rohen `$request_uri`) kann es Angreifern in manchen Konfigurationen ermöglichen, Zeichen in ein Weiterleitungsziel einzuschleusen. Beides bricht beim normalen Testen nichts sichtbar – genau deshalb lohnt sich ein eigener Durchlauf, statt darauf zu hoffen, es in einer 200-zeiligen Konfiguration mit bloßem Auge zu bemerken.
Häufig gestellte Fragen
Ersetzt das `nginx -t`?
Nein. `nginx -t` ist das einzige Werkzeug, das deine Konfiguration gegen den exakten nginx-Build und die tatsächlich installierten Module deines Servers prüft, und es hat vor einem Reload das letzte Wort. Dieser Prüfer findet dieselbe Art von Fehlern (Syntaxfehler, falsch platzierte Direktiven, einige Sicherheitsauffälligkeiten) schon, bevor du überhaupt einen Server mit nginx erreichst – nützlich beim lokalen Bearbeiten, in einem CI-Schritt oder wenn du noch keinen Shell-Zugriff auf den Zielrechner hast.
Ist die Sicherheits-Checkliste vollständig?
Nein – sie umfasst eine kleine, bewusst gewählte Menge an Prüfungen (fehlendes `server_tokens off;`, `autoindex on;` und `$uri`, wo `$request_uri` sicherer wäre), lose inspiriert von Gixy, dem Open-Source-Auditor für nginx-Konfigurationen. Sie ersetzt weder Gixy noch ein vollständiges Sicherheitsaudit.
Warum verhält sich der Regex-Tester etwas anders als echtes nginx?
Das Matching von `location ~` und `location ~*` in nginx nutzt PCRE (über die im nginx-Binary enthaltene PCRE-Bibliothek). Dieses Tool läuft komplett in deinem Browser und verwendet daher die eingebaute RegExp-Engine von JavaScript – bei gängigen Mustern liegen beide sehr nah beieinander, aber Funktionen, die es nur in PCRE gibt, etwa possessive Quantoren oder atomare Gruppen, verhalten sich hier nicht gleich.
Verlässt meine Konfiguration jemals meinen Browser?
Nein. Parsen, Prüfen und beide Simulatoren laufen mit reinem JavaScript in diesem Tab. Nichts wird hochgeladen, protokolliert oder irgendwohin gesendet – du kannst sogar die Internetverbindung trennen, nachdem die Seite geladen ist, und es funktioniert weiter.