Passer au contenu
100% Confidentialité — Vos fichiers restent sur votre appareil
>_
Français

Validateur de Configuration Nginx

Collez un nginx.conf pour détecter les erreurs de syntaxe, les directives mal placées et les erreurs de sécurité courantes — avant de recharger nginx.

Déposez un fichier .conf ici, ou collez le texte de configuration ci-dessus.

Tout s'exécute dans votre navigateur — votre configuration n'est jamais envoyée à un serveur.

Problèmes

Collez une configuration nginx ci-dessus (ou chargez l'exemple) et les vérifications s'afficheront ici.

Testeur de Regex pour Location

Utilise le moteur d'expressions régulières de JavaScript, pas le vrai moteur PCRE de nginx — très proche, mais pas identique (pas de quantificateurs possessifs/groupes atomiques).

Simulateur Rewrite / Return

Repérer les erreurs de config nginx avant la production

Un nginx.conf défectueux se manifeste généralement de deux façons désagréables : `nginx -t` refuse le rechargement avec une erreur énigmatique indiquant un numéro de ligne, ou — pire — un `reload` conserve silencieusement l'ancienne config (qui fonctionne) en mémoire alors que la nouvelle, cassée, reste sur le disque ; rien ne paraît anormal jusqu'au prochain redémarrage complet. Dans les deux cas, on les évite en détectant le même type d'erreurs plus tôt, pendant l'édition.

L'erreur la plus courante dans un nginx.conf n'a rien d'exotique : un point-virgule oublié. Comme la grammaire de nginx ne tient compte que de `;`, `{` et `}` (pas des sauts de ligne), un `;` manquant ne produit pas un message net du type « ligne 12 : `;` attendu » comme la plupart des analyseurs modernes ; le nom et les arguments de la directive suivante sont absorbés silencieusement comme arguments supplémentaires de la précédente, parfois sans aucune erreur jusqu'à ce qu'un comportement en aval devienne étrange. L'heuristique de saut de ligne de cet outil guette précisément ce schéma — un nom de directive connu au milieu d'une liste d'arguments, sur une nouvelle ligne — et le signale avant qu'il ne devienne un ticket de support.

Le placement des directives est le deuxième piège courant : `proxy_pass` n'a de sens que dans un bloc `location` (ou `if`), `listen`/`server_name` que dans `server`, etc. Mais l'analyseur de nginx ne rejette pas toujours une directive simplement parce qu'elle est à un endroit inhabituel, et ses messages d'erreur pointent vers son registre interne de directives plutôt que vers « vous l'avez mal imbriquée ». Ce validateur vérifie directement la table directive-contexte : un `proxy_pass` oublié au niveau `http` (hors de tout `server`/`location`) est signalé avec la ligne exacte, et pas seulement par un « la config n'a pas pu se charger ».

Au-delà de la syntaxe, quelques petits choix de configuration ont des conséquences disproportionnées sur la sécurité : laisser `server_tokens` à sa valeur par défaut (`on`) révèle votre version exacte de nginx dans chaque en-tête de réponse et page d'erreur par défaut, ce qui offre une reconnaissance gratuite à quiconque cherche une CVE propre à une version ; utiliser la variable `$uri`, décodée, dans un `return`/`rewrite`/`add_header` (au lieu du `$request_uri` brut) peut, selon la configuration, permettre à un attaquant d'injecter des caractères dans la cible d'une redirection. Aucun de ces points ne casse rien de visible pendant les tests normaux, et c'est précisément pourquoi ils méritent une passe dédiée plutôt que d'être repérés à l'œil dans une config de 200 lignes.

Questions fréquentes

Cet outil remplace-t-il `nginx -t` ?

Non. `nginx -t` est le seul outil qui vérifie votre config avec la build nginx et les modules réellement installés sur votre serveur, et c'est le dernier mot avant un rechargement. Ce validateur détecte le même genre d'erreurs (erreurs de syntaxe, directives mal placées, quelques mauvaises pratiques de sécurité) avant même d'arriver sur un serveur équipé de nginx — utile pendant l'édition en local, dans une étape de CI, ou quand vous n'avez pas encore d'accès shell à la machine cible.

La liste de contrôle de sécurité est-elle exhaustive ?

Non : elle couvre un petit ensemble de contrôles choisis (absence de `server_tokens off;`, `autoindex on;`, et `$uri` utilisé là où `$request_uri` est plus sûr), vaguement inspirés de Gixy, l'auditeur open source de configs nginx. Elle ne remplace ni Gixy ni un véritable audit de sécurité.

Pourquoi le testeur de regex se comporte-t-il légèrement différemment du vrai nginx ?

Les correspondances `location ~` et `location ~*` de nginx utilisent PCRE (via la bibliothèque PCRE intégrée au binaire nginx). Cet outil s'exécutant entièrement dans votre navigateur, il utilise à la place le moteur RegExp natif de JavaScript : les deux sont très proches pour les motifs courants, mais les fonctionnalités propres à PCRE, comme les quantificateurs possessifs ou les groupes atomiques, ne se comporteront pas de la même façon ici.

Ma configuration quitte-t-elle mon navigateur ?

Non. L'analyse, la validation et les deux simulateurs s'exécutent en JavaScript pur dans cet onglet. Rien n'est envoyé, journalisé ni transmis : vous pouvez même vous déconnecter d'internet une fois la page chargée, et l'outil continue de fonctionner.

Outils associés