Валидатор конфигурации Nginx
Вставьте nginx.conf и найдите синтаксические ошибки, директивы не в том контексте и типичные проблемы безопасности — ещё до перезагрузки nginx.
Перетащите файл .conf сюда или вставьте текст конфигурации выше.
Всё выполняется прямо в вашем браузере — конфигурация никогда не отправляется ни на один сервер.
Вставьте конфигурацию nginx выше (или загрузите пример), и здесь появятся результаты проверки.
Используется движок регулярных выражений JavaScript, а не настоящий движок PCRE из nginx — очень похоже, но не идентично (нет притяжательных квантификаторов/атомарных групп).
Как поймать ошибки конфигурации nginx до выхода в продакшен
Сломанный nginx.conf обычно проявляется одним из двух неприятных способов: `nginx -t` отказывается перезагружаться с невнятной ошибкой с номером строки либо — что хуже — `reload` молча оставляет в памяти старую (рабочую) конфигурацию, пока новая, сломанная, лежит на диске, и всё выглядит нормально до следующего полного перезапуска. Оба случая можно предотвратить, поймав тот же класс ошибок раньше — пока вы ещё редактируете файл.
Самая частая ошибка в nginx.conf на практике совсем не экзотична — забытая точка с запятой. Грамматика nginx учитывает только `;`, `{` и `}` (но не переводы строк), поэтому пропущенная `;` не даёт чёткой ошибки «строка 12: ожидалась ;», как в большинстве современных парсеров: имя и аргументы следующей директивы молча становятся лишними аргументами предыдущей, иногда вообще без ошибки, пока что-то дальше не начнёт вести себя странно. Эвристика переводов строк в этом инструменте специально отслеживает такой случай — известное имя директивы посреди списка аргументов на новой строке исходника — и сообщает о нём до того, как он превратится в заявку в поддержку.
Расположение директив — вторая частая ловушка: `proxy_pass` имеет смысл только внутри `location` (или `if`), `listen`/`server_name` — только внутри `server`, и так далее. Но парсер nginx не отклоняет директиву только потому, что она стоит в необычном месте, если он в целом знает её имя, а сообщения об ошибках указывают на внутренний реестр директив nginx, а не на «вы неверно вложили это». Этот валидатор напрямую проверяет таблицу «директива — контекст», поэтому `proxy_pass`, случайно оставленный на уровне `http` (вне любого `server`/`location`), будет отмечен с точной строкой, а не общим «конфигурацию не удалось загрузить».
Помимо синтаксиса, несколько мелких решений в конфигурации сильно влияют на безопасность: оставленный по умолчанию `server_tokens` (`on`) выдаёт точную версию nginx в каждом заголовке ответа и на стандартных страницах ошибок — это бесплатная разведка для тех, кто ищет уязвимость (CVE) конкретной версии; использование декодированной переменной `$uri` внутри `return`/`rewrite`/`add_header` (вместо исходной `$request_uri`) при некоторых конфигурациях позволяет злоумышленнику внедрить символы в цель перенаправления. Ни то, ни другое ничего не ломает при обычном тестировании, поэтому такие вещи стоит проверять отдельно, а не надеяться заметить их на глаз в конфигурации на 200 строк.
Часто задаваемые вопросы
Заменяет ли это `nginx -t`?
Нет. `nginx -t` — единственная проверка конфигурации по той самой сборке nginx и модулям, что установлены на вашем сервере, и последнее слово перед перезагрузкой. Этот валидатор ловит тот же класс ошибок (синтаксические ошибки, директивы не на своём месте, несколько проблем безопасности) ещё до того, как вы доберётесь до сервера с nginx, — удобно при локальном редактировании, на шаге CI или когда у вас пока нет доступа к целевой машине.
Исчерпывающий ли это список проверок безопасности?
Нет — он охватывает небольшой, намеренно подобранный набор проверок (отсутствие `server_tokens off;`, `autoindex on;` и `$uri` там, где безопаснее `$request_uri`), вдохновлённый Gixy, открытым аудитором конфигураций nginx. Он не заменяет Gixy или полноценный аудит безопасности.
Почему проверка регулярных выражений немного отличается от настоящего nginx?
Сопоставление `location ~` и `location ~*` в nginx использует PCRE (встроенную в бинарный файл nginx). Этот инструмент работает целиком в браузере, поэтому использует встроенный движок RegExp JavaScript — для типичных шаблонов они очень близки, но возможности только PCRE, такие как притяжательные квантификаторы или атомарные группы, здесь поведут себя иначе.
Покидает ли моя конфигурация браузер?
Нет. Разбор, проверка и оба симулятора работают на обычном JavaScript в этой вкладке. Ничего не загружается, не записывается в журналы и никуда не отправляется — можно даже отключиться от интернета после загрузки страницы, и всё продолжит работать.