Validador de Configuración Nginx

Un nginx.conf roto suele anunciarse de una de dos maneras desagradables: `nginx -t` se niega a recargar con un enigmático error de número de línea o, peor aún, un `reload` conserva en silencio la configuración antigua (la que funcionaba) en memoria mientras la nueva, rota, queda en disco, de modo que nada parece ir mal hasta el siguiente reinicio completo. Ambas situaciones se evitan detectando antes el mismo tipo de errores, mientras aún estás editando.

El error más común en un nginx.conf real no es exótico: es un punto y coma olvidado. Como la gramática de nginx solo atiende a `;`, `{` y `}` (no a los saltos de línea), un `;` ausente no produce un limpio «línea 12: se esperaba ;» como en la mayoría de los analizadores modernos; en su lugar, el nombre y los argumentos de la siguiente directiva se absorben en silencio como argumentos adicionales de la anterior, a veces sin ningún error hasta que algo más adelante se comporta de forma extraña. La heurística de saltos de línea de esta herramienta vigila justo ese patrón (un nombre de directiva conocido que aparece en mitad de una lista de argumentos en una línea nueva) y lo señala antes de que se convierta en una incidencia de soporte.

La ubicación de las directivas es la segunda trampa habitual: `proxy_pass` solo tiene sentido dentro de un bloque `location` (o `if`), `listen`/`server_name` solo dentro de `server`, y así sucesivamente. Pero el propio analizador de nginx no rechaza una directiva solo porque esté en un lugar inusual si reconoce su nombre en un sentido más amplio, y los mensajes de error apuntan al registro interno de directivas de nginx en lugar de decir «has anidado esto mal». Este validador consulta directamente la tabla de directiva a contexto, de modo que un `proxy_pass` olvidado por accidente a nivel de `http` (fuera de cualquier `server`/`location`) se señala con la línea exacta y no con un simple «la configuración no se pudo cargar».

Más allá de la sintaxis, algunas pequeñas decisiones de configuración tienen consecuencias desproporcionadas para la seguridad: dejar `server_tokens` en su valor por defecto (`on`) entrega tu versión exacta de nginx en cada cabecera de respuesta y página de error por defecto, un reconocimiento gratuito para quien busque un CVE específico de una versión; y usar la variable `$uri`, ya decodificada de URL, dentro de un `return`/`rewrite`/`add_header` (en lugar de la `$request_uri` sin procesar) puede permitir que un atacante inyecte caracteres en el destino de una redirección con ciertas configuraciones. Ninguna de las dos cosas rompe nada visiblemente durante las pruebas normales, y precisamente por eso merecen una pasada específica en lugar de confiar en notarlas a simple vista en una configuración de 200 líneas.