Walidator Konfiguracji Nginx
Wklej nginx.conf i wykryj błędy składni, źle umieszczone dyrektywy oraz typowe błędy bezpieczeństwa — zanim przeładujesz nginx.
Przeciągnij tu plik .conf lub wklej tekst konfiguracji powyżej.
Wszystko działa w Twojej przeglądarce — konfiguracja nigdy nie jest wysyłana na żaden serwer.
Wklej powyżej konfigurację nginx (lub wczytaj przykład), a wyniki sprawdzenia pojawią się tutaj.
Używa silnika wyrażeń regularnych JavaScript, a nie prawdziwego silnika PCRE nginx — bardzo zbliżone, ale nie identyczne (brak kwantyfikatorów zaborczych/grup atomowych).
Wyłapywanie błędów konfiguracji nginx, zanim trafią na produkcję
Zepsuty nginx.conf zwykle daje o sobie znać na jeden z dwóch nieprzyjemnych sposobów: `nginx -t` odmawia przeładowania z enigmatycznym błędem z numerem wiersza albo — co gorsza — `reload` po cichu zachowuje w pamięci starą (działającą) konfigurację, podczas gdy nowa, zepsuta, leży na dysku, więc nic nie wydaje się nie tak aż do następnego pełnego restartu. Obu sytuacji można uniknąć, wychwytując te same błędy wcześniej, jeszcze podczas edycji.
Najczęstszy prawdziwy błąd w nginx.conf nie jest egzotyczny — to zapomniany średnik. Ponieważ gramatyka nginx zwraca uwagę tylko na `;`, `{` i `}` (a nie na podziały wierszy), brakujący `;` nie daje czytelnego błędu „wiersz 12: oczekiwano ;” jak w większości nowoczesnych parserów; zamiast tego nazwa i argumenty następnej dyrektywy po cichu zostają wchłonięte jako dodatkowe argumenty poprzedniej, czasem bez żadnego błędu, aż coś dalej zacznie się dziwnie zachowywać. Heurystyka podziału wierszy w tym narzędziu pilnuje właśnie tego wzorca — znanej nazwy dyrektywy pojawiającej się w środku listy argumentów w nowym wierszu źródła — i oznacza go, zanim stanie się zgłoszeniem do pomocy technicznej.
Umiejscowienie dyrektyw to druga częsta pułapka: `proxy_pass` ma sens tylko wewnątrz bloku `location` (lub `if`), `listen`/`server_name` tylko wewnątrz `server`, i tak dalej — ale własny parser nginx nie odrzuca dyrektywy tylko dlatego, że stoi w nietypowym miejscu, jeśli nazwa dyrektywy jest mu w szerszym sensie znana, a komunikaty błędów wskazują na wewnętrzny rejestr dyrektyw nginx, a nie na „zagnieździłeś to źle”. Ten walidator sprawdza tabelę dyrektywa–kontekst bezpośrednio, więc `proxy_pass` omyłkowo pozostawione na poziomie `http` (poza jakimkolwiek `server`/`location`) zostaje oznaczone w dokładnym wierszu, a nie tylko jako „konfiguracja nie załadowała się”.
Poza składnią, kilka drobnych wyborów w konfiguracji ma nieproporcjonalnie duże skutki dla bezpieczeństwa: pozostawienie `server_tokens` na wartości domyślnej (`on`) zdradza dokładną wersję nginx w każdym nagłówku odpowiedzi i domyślnej stronie błędu, co jest darmowym rozpoznaniem dla każdego, kto szuka luki CVE specyficznej dla wersji; użycie zdekodowanej zmiennej `$uri` w `return`/`rewrite`/`add_header` (zamiast surowego `$request_uri`) może w niektórych konfiguracjach pozwolić atakującemu wstrzyknąć znaki do celu przekierowania. Żadne z nich niczego widocznie nie psuje podczas zwykłych testów, i dlatego warto je sprawdzić osobnym przebiegiem, zamiast liczyć, że zauważysz je gołym okiem w 200-wierszowej konfiguracji.
Najczęstsze pytania
Czy to zastępuje `nginx -t`?
Nie. `nginx -t` to jedyne narzędzie sprawdzające konfigurację względem dokładnej wersji nginx i modułów faktycznie zainstalowanych na Twoim serwerze i to ono ma ostatnie słowo przed przeładowaniem. Ten walidator wychwytuje tę samą klasę błędów (błędy składni, złe umiejscowienie dyrektyw, kilka podejrzanych ustawień bezpieczeństwa), zanim w ogóle dotrzesz do serwera z zainstalowanym nginx — przydatne podczas lokalnej edycji, w kroku CI lub gdy nie masz jeszcze dostępu do powłoki na docelowej maszynie.
Czy lista kontrolna bezpieczeństwa jest wyczerpująca?
Nie — obejmuje niewielki, celowo dobrany zestaw testów (brak `server_tokens off;`, `autoindex on;` oraz `$uri` użyte tam, gdzie bezpieczniejsze jest `$request_uri`), luźno inspirowanych Gixy, otwartym audytorem konfiguracji nginx. Nie zastępuje Gixy ani pełnego audytu bezpieczeństwa.
Dlaczego tester wyrażeń regularnych zachowuje się nieco inaczej niż prawdziwy nginx?
Dopasowanie `location ~` i `location ~*` w nginx korzysta z PCRE (przez dołączoną do binarki bibliotekę PCRE). To narzędzie działa w całości w przeglądarce, więc używa wbudowanego silnika RegExp JavaScriptu — oba są bardzo zbliżone dla typowych wzorców, ale funkcje dostępne tylko w PCRE, takie jak kwantyfikatory posesywne czy grupy atomowe, nie zadziałają tu tak samo.
Czy moja konfiguracja kiedykolwiek opuszcza przeglądarkę?
Nie. Parsowanie, walidacja i oba symulatory działają w czystym JavaScripcie w tej karcie. Nic nie jest wysyłane, zapisywane w logach ani przesyłane gdziekolwiek — po załadowaniu strony możesz nawet odłączyć się od internetu, a narzędzie nadal będzie działać.