Nginx-konfigurationsvaliderare
Klistra in en nginx.conf och hitta syntaxfel, felplacerade direktiv och vanliga säkerhetsmisstag — innan du laddar om nginx på riktigt.
Släpp en .conf-fil här, eller klistra in konfigurationstexten ovan.
Allt körs i din webbläsare — din konfiguration laddas aldrig upp till någon server.
Klistra in en nginx-konfiguration ovan (eller läs in exemplet) så visas kontrollerna här.
Använder JavaScripts regex-motor, inte nginx riktiga PCRE-motor — mycket likt, men inte identiskt (inga possessiva kvantifierare/atomära grupper).
Fånga fel i nginx-konfigurationen innan de når produktion
En trasig nginx.conf tillkännager sig oftast på ett av två obehagliga sätt: `nginx -t` vägrar ladda om med ett kryptiskt radnummerfel, eller — värre — en `reload` behåller tyst den gamla (fungerande) konfigurationen i minnet medan den nya ligger trasig på disk, så ingenting verkar fel förrän nästa fullständiga omstart. Båda går att undvika genom att fånga samma typ av misstag tidigare, medan du fortfarande redigerar.
Det vanligaste verkliga misstaget i nginx.conf är inte exotiskt — det är ett bortglömt semikolon. Eftersom nginx grammatik bara bryr sig om `;`, `{` och `}` (inte radbrytningar) ger ett saknat `;` inget tydligt "rad 12: förväntade ;" som de flesta moderna tolkare gör. I stället sugs nästa direktivs namn och argument tyst upp som extra argument till det föregående, ibland utan något fel alls tills något längre fram beter sig konstigt. Det här verktygets radbrytningsheuristik letar specifikt efter det mönstret — ett känt direktivnamn mitt i en argumentlista på en ny källrad — och flaggar det innan det blir ett supportärende.
Direktivens placering är den andra vanliga fällan: `proxy_pass` är bara meningsfullt inuti ett `location`-block (eller `if`), `listen`/`server_name` bara inuti `server`, och så vidare — men nginx egen tolkare avvisar inte nödvändigtvis ett direktiv bara för att det står på en ovanlig plats, och felmeddelandena pekar på nginx interna direktivregister snarare än på "du nästlade det här fel". Den här validatorn kontrollerar tabellen över direktiv och kontext direkt, så en `proxy_pass` som av misstag hamnat på `http`-nivå (utanför alla `server`/`location`) flaggas med exakt rad, inte bara "konfigurationen kunde inte läsas in".
Utöver syntaxen har ett fåtal små konfigurationsval oproportionerligt stora säkerhetskonsekvenser: att lämna `server_tokens` på standardvärdet (`on`) avslöjar din exakta nginx-version i varje svarshuvud och på standardfelsidor, vilket är gratis spaning för den som letar efter en versionsspecifik CVE. Att använda den URL-avkodade variabeln `$uri` i en `return`/`rewrite`/`add_header` (i stället för den råa `$request_uri`) kan i vissa konfigurationer låta en angripare injicera tecken i ett omdirigeringsmål. Inget av detta går sönder synligt vid normal testning, och just därför är det värt ett eget genomgångssteg i stället för att hoppas upptäcka det med blotta ögat i en konfiguration på 200 rader.
Vanliga frågor
Ersätter det här `nginx -t`?
Nej. `nginx -t` är det enda verktyget som kontrollerar din konfiguration mot den exakta nginx-version och de moduler som faktiskt är installerade på din server, och det är sista ordet före en omladdning. Den här validatorn fångar samma typ av misstag (syntaxfel, direktiv på fel plats, en handfull säkerhetsvarningar) redan innan du kommit till en server med nginx installerat — användbart vid lokal redigering, i ett CI-steg eller när du ännu inte har shell-åtkomst till målmaskinen.
Är säkerhetschecklistan heltäckande?
Nej — den täcker en liten, medvetet vald uppsättning kontroller (saknad `server_tokens off;`, `autoindex on;` och `$uri` där `$request_uri` är säkrare), löst inspirerade av Gixy, den öppna källkodsgranskaren för nginx-konfiguration. Den ersätter inte Gixy eller en fullständig säkerhetsgranskning.
Varför beter sig regextestaren lite annorlunda än riktiga nginx?
nginx `location ~` och `location ~*` använder PCRE (via det medföljande PCRE-biblioteket i nginx-binären). Det här verktyget körs helt i din webbläsare och använder därför JavaScripts inbyggda RegExp-motor i stället — de två ligger mycket nära varandra för vanliga mönster, men funktioner som bara finns i PCRE, som possessiva kvantifierare eller atomära grupper, beter sig inte likadant här.
Lämnar min konfiguration någonsin webbläsaren?
Nej. Tolkning, validering och båda simulatorerna körs med vanlig JavaScript i den här fliken. Ingenting laddas upp, loggas eller skickas någonstans — du kan till och med koppla från internet när sidan har laddats och den fortsätter fungera.