Validador de Configuração Nginx

Um nginx.conf quebrado costuma se manifestar de duas formas desagradáveis: o `nginx -t` se recusa a recarregar com um erro enigmático de número de linha ou, pior, o `reload` mantém em silêncio a configuração antiga (funcionando) na memória enquanto a nova, quebrada, fica no disco — e nada parece errado até a próxima reinicialização completa. As duas situações podem ser evitadas se você pegar o mesmo tipo de erro mais cedo, ainda durante a edição.

O erro mais comum em um nginx.conf no mundo real não é nada exótico: é um ponto e vírgula esquecido. Como a gramática do nginx só se importa com `;`, `{` e `}` (e não com quebras de linha), a falta de um `;` não gera um claro "linha 12: esperado ;" como na maioria dos analisadores modernos; em vez disso, o nome e os argumentos da diretiva seguinte são absorvidos como argumentos extras da anterior, às vezes sem nenhum erro até que algo adiante se comporte de modo estranho. A heurística de quebra de linha desta ferramenta vigia justamente esse padrão — o nome de uma diretiva conhecida aparecendo no meio da lista de argumentos, em uma nova linha do código — e avisa antes que vire um chamado de suporte.

A posição das diretivas é a segunda armadilha comum: `proxy_pass` só faz sentido dentro de um bloco `location` (ou `if`), `listen`/`server_name` só dentro de `server`, e assim por diante. Só que o próprio analisador do nginx nem sempre rejeita uma diretiva só por estar em um lugar incomum, e as mensagens de erro apontam para o registro interno de diretivas do nginx, não para "você aninhou isto errado". Este validador consulta diretamente a tabela de diretivas por contexto, de modo que um `proxy_pass` esquecido no nível `http` (fora de qualquer `server`/`location`) é apontado com a linha exata, e não apenas com um "a configuração falhou ao carregar".

Além da sintaxe, algumas escolhas pequenas de configuração têm consequências desproporcionais para a segurança: deixar `server_tokens` no valor padrão (`on`) entrega a versão exata do nginx em todo cabeçalho de resposta e página de erro padrão, o que é reconhecimento grátis para quem procura uma CVE específica da versão; e usar a variável `$uri`, já decodificada, dentro de `return`/`rewrite`/`add_header` (em vez da `$request_uri`, bruta) pode permitir que um atacante injete caracteres no destino de um redirecionamento em certas configurações. Nenhuma das duas coisas quebra nada de forma visível nos testes normais, e é justamente por isso que merecem uma verificação dedicada, em vez de depender de notá-las a olho em uma configuração de 200 linhas.