Nginx-configuratievalidator
Plak een nginx.conf en vind syntaxfouten, verkeerd geplaatste directives en veelvoorkomende beveiligingsfouten — voordat je nginx herlaadt.
Sleep hier een .conf-bestand naartoe, of plak de configuratietekst hierboven.
Alles draait in je browser — je configuratie wordt nooit geüpload naar een server.
Plak hierboven een nginx-config (of laad het voorbeeld) en de controles verschijnen hier.
Gebruikt de RegExp-engine van JavaScript, niet de echte PCRE-engine van nginx — heel vergelijkbaar, maar niet identiek (geen possessive quantifiers/atomic groups).
Nginx-configfouten opsporen voordat ze in productie komen
Een kapotte nginx.conf meldt zich meestal op een van twee vervelende manieren: `nginx -t` weigert te herladen met een cryptische foutmelding met regelnummer, of — erger — een `reload` houdt stilletjes de oude (werkende) config in het geheugen terwijl de nieuwe kapot op schijf staat, zodat niets mis lijkt tot de volgende volledige herstart. Beide zijn te voorkomen door dezelfde soort fouten eerder op te sporen, terwijl je nog aan het bewerken bent.
De meest voorkomende echte fout in nginx.conf is niet exotisch — het is een vergeten puntkomma. Omdat de grammatica van nginx alleen om `;`, `{` en `}` geeft (niet om regeleinden), levert een ontbrekende `;` niet zoals bij de meeste moderne parsers een nette fout "regel 12: ; verwacht" op; in plaats daarvan worden de naam en argumenten van de volgende directive stilletjes opgenomen als extra argumenten van de vorige, soms zonder enige fout totdat iets verderop vreemd gedrag vertoont. De regeleinde-heuristiek van deze tool let specifiek op dat patroon — een bekende directivenaam midden in een argumentenlijst op een nieuwe bronregel — en meldt het voordat het een supportticket wordt.
Plaatsing van directives is de tweede veelvoorkomende valkuil: `proxy_pass` heeft alleen zin binnen een `location`- (of `if`-)blok, `listen`/`server_name` alleen binnen `server`, enzovoort — maar de eigen parser van nginx weigert een directive niet zomaar omdat hij op een ongebruikelijke plek staat als de naam in bredere zin wordt herkend, en foutmeldingen wijzen naar het interne directive-register van nginx in plaats van naar "je hebt dit verkeerd genest". Deze validator controleert de tabel van directive naar context rechtstreeks, zodat een `proxy_pass` die per ongeluk op `http`-niveau is blijven staan (buiten elke `server`/`location`) met de exacte regel wordt gemeld, en niet alleen met "de config kon niet worden geladen".
Naast syntaxis hebben een paar kleine configkeuzes onevenredig grote gevolgen voor de beveiliging: `server_tokens` op de standaardwaarde (`on`) laten geeft je exacte nginx-versie weg in elke responseheader en standaardfoutpagina, wat gratis verkenning is voor iedereen die zoekt naar een versiespecifieke CVE; de URL-gedecodeerde variabele `$uri` gebruiken in een `return`/`rewrite`/`add_header` (in plaats van de ruwe `$request_uri`) kan een aanvaller in sommige configuraties tekens in een redirectdoel laten injecteren. Geen van beide breekt zichtbaar iets bij normaal testen, en juist daarom verdienen ze een aparte controle in plaats van erop te vertrouwen dat je ze met het blote oog opmerkt in een config van 200 regels.
Veelgestelde vragen
Vervangt dit `nginx -t`?
Nee. `nginx -t` is de enige tool die je config controleert tegen de exacte nginx-build en modules die echt op je server staan, en is het laatste woord vóór een reload. Deze validator vangt dezelfde soort fouten (syntaxfouten, directives op de verkeerde plek, een handvol beveiligingsgeuren) nog voordat je bij een server met nginx bent — handig tijdens lokaal bewerken, in een CI-stap, of als je nog geen shelltoegang tot de doelmachine hebt.
Is de beveiligingschecklist uitputtend?
Nee — het dekt een kleine, bewust gekozen set controles (ontbrekende `server_tokens off;`, `autoindex on;` en `$uri` waar `$request_uri` veiliger is), losjes geïnspireerd op Gixy, de open-source auditor voor nginx-configs. Het is geen vervanging voor Gixy of een volledige beveiligingsaudit.
Waarom gedraagt de regextester zich iets anders dan echte nginx?
De matching van `location ~` en `location ~*` in nginx gebruikt PCRE (via de meegeleverde PCRE-bibliotheek in de nginx-binary). Deze tool draait volledig in je browser en gebruikt daarom de ingebouwde RegExp-engine van JavaScript — die twee lijken voor gangbare patronen erg op elkaar, maar functies die alleen in PCRE bestaan, zoals bezitterige kwantoren of atomaire groepen, gedragen zich hier niet hetzelfde.
Verlaat mijn config ooit mijn browser?
Nee. Parsen, valideren en beide simulators draaien met gewone JavaScript in dit tabblad. Er wordt niets geüpload, gelogd of ergens naartoe gestuurd — je kunt zelfs de internetverbinding verbreken nadat de pagina is geladen en het blijft werken.