Skip to content

Testeur nginx location — pourquoi ce bloc l'emporte

Quel bloc location nginx l'emporte — et pourquoi les autres ont perdu. Testeur gratuit pour =, ^~, ~ et ~*, tout dans votre navigateur.

Sans pistage Fonctionne dans le navigateur Gratuit
Votre configuration est analysée localement dans votre navigateur et n'est jamais envoyée. Les configurations de serveur portent des noms d'hôtes en amont et des blocs d'authentification : ouvrez le panneau Réseau et regardez-le rester silencieux — ou passez carrément hors ligne.
Essayez une vraie erreur de configuration
Location retenu
~* \.(gif|jpg|jpeg)$

Première regex, dans l'ordre de la configuration, à avoir correspondu. La longueur est sans importance.

Ce que nginx compare réellement
Cible de la requête
/documents/1.jpg
$uri normalisée
/documents/1.jpg
Query string $args
—

La correspondance ne s'exécute que sur le chemin normalisé. La query string est détachée d'abord et ne participe jamais.

Pourquoi ce bloc a gagné
Pourquoi ce bloc a gagné
Ligne location Étape Résultat Raison
2 = / Exact Aucune correspondance Un location = exige que l'URI entière soit égale, pas qu'elle commence par lui.
3 / Préfixe Correspond mais plus court Il correspond, mais un autre préfixe a couvert plus de caractères.
4 /documents/ Préfixe Correspond mais plus court Il correspond, mais un autre préfixe a couvert plus de caractères.
5 ^~ /images/ Préfixe Aucune correspondance L'URI ne commence pas par ce préfixe.
6 ~* \.(gif|jpg|jpeg)$ Regex Retenu Première regex, dans l'ordre de la configuration, à avoir correspondu. La longueur est sans importance.

Modificateurs de location nginx : =, ^~, ~ et ~* comparés

Modificateurs de location nginx : =, ^~, ~ et ~* comparés
Modificateur Syntaxe Correspond par Ordre Stoppe les regex Usage typique
= location = /path Égalité 1 Oui Chemins très sollicités comme / — la correspondance la plus rapide possible.
^~ location ^~ /path Commence par 2 Oui Répertoires qui ne doivent jamais être confiés à une regex, comme les uploads.
~ location ~ regex Regex PCRE 3 Non Routage par extension quand la casse compte.
~* location ~* regex Regex PCRE 3 Non Routage par extension quand la casse ne compte pas.
(aucun) location /path Commence par 4 Non Routage général par chemin.
@ location @name Interne seulement — Non Replis de error_page et try_files.

La colonne d'ordre n'est pas un simple classement. Un location de préfixe n'arrête l'évaluation des regex que lorsqu'il porte ^~ et qu'il est lui-même la plus longue correspondance — c'est exactement pourquoi un bloc ^~ semble parfois ne rien faire.

Priorité des location nginx : l'ordre de résolution

Priorité des location nginx : l'ordre de résolution
# Étape Met fin à la recherche Ce qui se passe
1 Normalisation Non Décodage des pourcentages, résolution de . et .., slashs répétés fusionnés. La query string est détachée ici et ne participe jamais à la correspondance.
2 Exact Oui location = /path, comparé par égalité. Un succès met fin à la recherche immédiatement.
3 Redirection auto Oui Un location de proxy dont le nom est l'URI plus un slash. nginx répond 301 et n'atteint jamais les regex.
4 Préfixe Non Chaque préfixe correspondant est comparé et le plus long est mémorisé. L'ordre dans la configuration est ignoré.
5 Imbriqué Non On descend dans le préfixe gagnant. Une regex imbriquée est essayée avant le niveau parent.
6 Regex Oui Les regex sont essayées dans l'ordre de la configuration et la première correspondance l'emporte. Une regex plus longue ou plus spécifique écrite après ne s'exécute jamais.
7 Repli Oui Aucune regex n'a correspondu, le préfixe mémorisé plus tôt est donc utilisé.
L'ordre de correspondance, le court-circuit du ^~, la descente dans les location imbriqués, le comportement de redirection automatique et la normalisation de l'URI ont été confrontés au code source de nginx et confirmés en exécutant les configurations sur nginx 1.27.5. — Équipe d'ingénierie Go Tools · 22 juil. 2026

Les règles de sélection de cette page ont été vérifiées sur un nginx 1.27.5 en fonctionnement plutôt que reprises d'articles de seconde main, et le moteur est couvert par des tests unitaires dérivés de ces exécutions.

Correspondance des location nginx : réponses rapides

nginx traite-t-il les location regex avant les correspondances de préfixe ?

Non — les préfixes sont vérifiés en premier, mais une regex qui correspond l'emporte quand même. nginx vérifie d'abord tous les location de préfixe et mémorise la plus longue correspondance, puis évalue les location regex dans l'ordre où ils apparaissent dans le fichier. La première regex qui correspond l'emporte. Si aucune regex ne correspond, le location de préfixe mémorisé est utilisé. La seule exception est ^~ : quand le plus long préfixe correspondant le porte, la phase des regex est entièrement ignorée.

L'ordre des blocs location compte-t-il dans nginx ?

Seulement pour les location regex. Les location de préfixe — y compris = et ^~ — sont sélectionnés sur la plus longue correspondance, leur ordre dans le fichier est donc sans importance. Les location regex sont testés de haut en bas et la première correspondance l'emporte, donc déplacer un bloc regex change celui qui s'exécute. Une regex plus spécifique placée sous une regex plus large ne s'exécute jamais.

Que fait réellement le modificateur ^~ ?

Il arrête nginx après la correspondance de préfixe au lieu d'augmenter la priorité. Si le plus long location de préfixe correspondant porte ^~, nginx saute la phase des regex et utilise ce bloc. Il ne rend pas le préfixe plus long et ne le classe pas au-dessus des autres préfixes — il supprime seulement l'évaluation des regex. C'est pourquoi un bloc ^~ semble ne rien faire quand un préfixe simple plus long correspond aussi : c'est le plus long qui est mémorisé, et lui ne supprime rien.

location /static est-il identique à location /static/ ?

Non — /static correspond aussi à /staticfoo. La correspondance par préfixe est une simple comparaison de chaînes, pas une frontière de segment de chemin, donc location /static sert aussi /staticfiles et /static-backup. Par ailleurs, quand /static/ est utilisé avec proxy_pass, une requête vers /static sans slash final reçoit une redirection 301 vers /static/ avant qu'une seule regex ne soit envisagée.

nginx décode-t-il %2F et fusionne-t-il les doubles slashs avant la correspondance ?

Oui — la correspondance s'exécute sur l'URI normalisée, pas sur la requête brute. nginx décode %XX, résout . et .. et compresse les slashs répétés avant de sélectionner un location. Un %2F décodé devient un vrai séparateur et participe à cette résolution, donc /a/b%2F..%2Fzz est comparé comme /a/zz. La query string est détachée en premier et ne participe jamais à la correspondance.

Qu'est-ce qu'un bloc location nginx ?

Un bloc location dit à nginx quoi faire d'une requête dont l'URI correspond à un motif. Un bloc server en contient généralement plusieurs, et l'intéressant n'est pas ce que fait chacun mais lequel nginx retient — parce que les règles de sélection ne sont pas celles que la plupart des gens supposent.

Il existe cinq formes. location = /path correspond uniquement quand l'URI entière est égale. location /path correspond à toute URI commençant par ces caractères. location ^~ /path est la même comparaison de préfixe avec un effet supplémentaire. location ~ regex et location ~* regex appliquent un motif PCRE, avec et sans sensibilité à la casse. location @name ne participe pas du tout à la correspondance d'URI et n'existe que comme cible de try_files et error_page.

La sélection se déroule par étapes. D'abord l'URI est normalisée : pourcentages décodés, . et .. résolus, slashs répétés fusionnés, query string détachée. Ensuite un location = égal à l'URI met fin à la recherche immédiatement. Puis tous les préfixes correspondants sont comparés et le plus long est mémorisé — l'ordre dans la configuration ne joue aucun rôle ici. Si ce préfixe mémorisé porte ^~, nginx s'arrête et l'utilise. Sinon les location regex sont essayés dans l'ordre où ils apparaissent dans le fichier, et la première correspondance l'emporte, aussi spécifique qu'une suivante puisse être. Si aucune ne correspond, le préfixe mémorisé est utilisé.

Deux de ces règles tirent en sens inverse, et c'est là que loge la confusion : les préfixes sont choisis par longueur sans égard à l'ordre, les regex par ordre sans égard à la longueur. Une configuration qui se lit correctement de haut en bas peut quand même router une requête là où vous ne le vouliez pas, et aucune relecture ne le révèle. Cette page rejoue toute la séquence sur votre propre configuration et montre où chaque bloc est sorti.

# From the nginx documentation. Which block serves each request?
server {
    location = /                   { }   # A
    location /                     { }   # B
    location /documents/           { }   # C
    location ^~ /images/           { }   # D
    location ~* \.(gif|jpg|jpeg)$  { }   # E
}

#   /                        -> A   exact match, search ends here
#   /index.html              -> B   no regex matched, longest prefix used
#   /documents/document.html -> C   longer prefix than B
#   /images/1.gif            -> D   ^~ won the prefix stage, regex skipped
#   /documents/1.jpg         -> E   regex beats the longer prefix C

# The last two lines are the whole lesson: identical-looking prefixes
# behave differently because only one of them carries ^~.

Fonctionnalités clés

Chaque bloc perdant, avec l'étape où il a été éliminé

Chaque location que vous avez écrit obtient une ligne : a correspondu mais plus court, ignoré parce qu'un préfixe ^~ a gagné, inaccessible parce qu'une regex antérieure a correspondu, ou simplement aucune correspondance. Savoir pourquoi les autres ont perdu est généralement ce qui règle vraiment la question.

La chaîne de décision en quatre étapes, rejouée

Normalisation, correspondance exacte, mémorisation du plus long préfixe, court-circuit du ^~, regex dans l'ordre du fichier et repli apparaissent comme des étapes distinctes sur votre propre configuration, au lieu d'être décrites dans l'abstrait.

Le court-circuit du ^~ rendu visible

Quand un préfixe ^~ supprime la phase des regex, chaque regex ignorée est étiquetée comme ignorée au lieu de disparaître sans bruit — et quand le ^~ ne s'applique pas parce qu'un préfixe simple plus long a gagné, cela aussi est montré.

Location imbriqués résolus, pas aplatis

nginx descend dans le préfixe gagnant et parcourt ses enfants, donc une regex imbriquée s'exécute avant celles du niveau parent. Les blocs imbriqués gardent leur indentation dans le tableau pour que la structure reste lisible.

Syntaxe propre à PCRE détectée d'emblée

Les navigateurs exécutent des regex ECMAScript, pas PCRE. Groupes atomiques, quantificateurs possessifs, classes POSIX et échappements comme \A et \K sont signalés au lieu d'être évalués de travers en silence, pour qu'une réponse fausse et assurée ne soit jamais présentée comme un fait.

Rien n'est envoyé — tout tourne dans votre navigateur

Les configurations de serveur portent des noms d'hôtes en amont, des ports internes et des règles d'authentification. L'analyse est un simple travail sur les chaînes, sans dépendances et sans appels réseau, vérifié par un test de contrat automatisé à chaque build.

Autres façons de répondre à cette question

nginx -T

Ligne de commande

Vide la configuration entièrement résolue, ce qui est précieux pour savoir ce qui est réellement chargé. Elle ne dira pas quel location une URI donnée sélectionne — c'est le manque que cette page comble.

error_log ... debug

Serveur en fonctionnement

La réponse la plus autorisée qui soit : la ligne « using configuration » nomme le bloc que nginx a réellement choisi. Elle demande root, un reload et un serveur accessible — elle répond donc après le déploiement, pas avant.

Vérificateurs de syntaxe de configuration

Service hébergé

Solides pour le lint du fichier entier et les règles de sécurité. Ils tournent généralement côté serveur, ce qui suppose d'envoyer une configuration contenant des noms d'hôtes internes et des chemins de certificats.

Lire la documentation

Référence

La documentation nginx énonce l'algorithme avec précision et vaut d'être lue une fois. L'appliquer à la main à huit blocs et une URI est là où les erreurs se glissent, parce que deux des règles pointent en sens inverse.

Exemples de correspondance des location nginx

Une regex bat un préfixe plus long

location /documents/  ·  location ~* \.(gif|jpg|jpeg)$  ·  GET /documents/1.jpg
~* \.(gif|jpg|jpeg)$ wins

Le préfixe /documents/ correspond et c'est le plus long préfixe du fichier, donc nginx le mémorise — puis évalue quand même les regex et confie la requête à la première qui correspond. La longueur perd face à la phase des regex. Si ce préfixe avait été écrit ^~ /documents/, aucune regex n'aurait été exécutée. C'est l'exemple de la documentation nginx, et c'est le plus utile à intégrer une fois pour toutes.

Le répertoire d'upload qui exécute du PHP

location /uploads/  ·  location ~ \.php$ { fastcgi_pass ... }  ·  GET /uploads/evil.php
~ \.php$ wins — the upload lands in the interpreter

Le préfixe /uploads/ correspond, mais un préfixe simple n'arrête pas la phase des regex : un fichier déposé par n'importe qui part directement vers PHP-FPM. Écrire location ^~ /uploads/ court-circuite la phase des regex et ferme la porte. Ce n'est pas théorique : c'est la forme derrière une longue série de rapports upload-vers-RCE, et deux caractères séparent le vulnérable du sûr.

Un ^~ qui ne fait discrètement rien

location ^~ /a/  ·  location /a/b/  ·  location ~ \.php$  ·  GET /a/b/x.php
~ \.php$ wins — the ^~ never applied

^~ ne supprime la phase des regex que lorsqu'il est lui-même le plus long préfixe correspondant. Ici /a/b/ est plus long, c'est donc lui que nginx mémorise, et son modificateur simple laisse la phase des regex s'exécuter. Le bloc ^~ est toujours dans le fichier, il a toujours l'air protecteur, et il n'a aucun effet sur cette requête. Lire une configuration de haut en bas ne le révèle pas ; comparer les longueurs de préfixe, si.

/static capture aussi /staticfoo

location /static  ·  location /static/  ·  GET /staticfoo
/static wins

La correspondance par préfixe compare des caractères, pas des segments de chemin. /staticfoo commence par /static, donc il correspond, et /static/ ne correspond pas du tout parce que l'URI n'a pas de slash à cette position. Tout ce qui est accessible sous un chemin qui commence simplement par les mêmes lettres est servi par ce bloc — c'est ainsi qu'une règle /static finit par servir /static-backup.

C'est la première regex qui gagne, pas la meilleure

location ~ ^/a  ·  location ~ ^/a/b/c$  ·  GET /a/b/c
~ ^/a wins; ~ ^/a/b/c$ is unreachable

Les regex sont évaluées dans l'ordre où elles apparaissent dans le fichier et la première correspondance met fin à la recherche. Le second bloc est plus spécifique et correspond exactement à cette URI, et il ne s'exécutera jamais — pour aucune requête. Les location de préfixe sont choisis par longueur sans égard à l'ordre ; les location de regex sont choisis par ordre sans égard à la spécificité. Confondre ces deux règles est la raison habituelle pour laquelle une règle « cesse de fonctionner » après que quelqu'un a rangé le fichier.

La traversée encodée est résolue avant la correspondance

location /a/  ·  location /b/  ·  GET /a/b%2F..%2Fzz
$uri becomes /a/zz, so /a/ wins

nginx décode les pourcentages, résout . et .. et fusionne les slashs répétés avant de consulter le moindre location. %2F se décode en un vrai séparateur puis participe à cette résolution, si bien que cette cible ne reste pas dans /a/b/ — elle atterrit sur /a/zz. Comparer la cible que vous avez tapée plutôt que le $uri normalisé donne ici la mauvaise réponse.

Comment utiliser le testeur de location nginx

  1. 1

    Collez le bloc server

    Déposez un bloc server entier, ou seulement les blocs location sur lesquels vous raisonnez. Les location imbriqués sont compris, et les numéros de ligne d'origine sont conservés pour que le tableau colle à votre fichier.

  2. 2

    Saisissez l'URI de la requête

    Tapez le chemin tel qu'il arrive sur le réseau, y compris l'encodage par pourcentage et la query string. Les trois lignes au-dessus du tableau montrent comment il est normalisé avant la correspondance.

  3. 3

    Lisez le gagnant, puis les perdants

    La carte de verdict nomme le bloc retenu et la raison en une ligne. Le tableau de décision en dessous explique chacun des autres blocs : à quelle étape il a été éliminé et pourquoi.

  4. 4

    Consultez les diagnostics

    Regex non ancrées, préfixes sans slash final, un ^~ portant un motif de regex, doublons inaccessibles et répertoires d'upload atteignables par une regex PHP sont tous signalés.

  5. 5

    Partagez l'état exact

    Copier le lien encode la configuration et l'URI dans le fragment de l'URL, pour qu'un collègue ouvre exactement ce que vous regardez. Les fragments ne sont jamais transmis à un serveur.

Erreurs courantes avec les location nginx

Attendre de ^~ qu'il devance un préfixe plus long

^~ n'est consulté que sur le préfixe qui a déjà gagné sur la longueur. Un préfixe simple plus long gagne d'abord, et la phase des regex s'exécute ensuite comme si le ^~ n'était pas là.

✗ Incorrect 
location ^~ /a/ { }
location /a/b/ { }
location ~ \.php$ { }
# /a/b/x.php -> ~ \.php$
✓ Correct 
location ^~ /a/ { }
location ^~ /a/b/ { }
location ~ \.php$ { }
# /a/b/x.php -> ^~ /a/b/

Un préfixe sans slash final qui attrape les voisins

La correspondance par préfixe compare des caractères plutôt que des segments de chemin, donc le bloc sert aussi tout chemin voisin commençant par les mêmes lettres.

✗ Incorrect 
location /static { root /var/www; }
# also serves /staticfoo and /static-backup
✓ Correct 
location /static/ { root /var/www; }
location = /static { return 301 /static/; }

Placer la regex spécifique sous la regex large

Les regex sont essayées dans l'ordre du fichier et la première correspondance met fin à la recherche, donc le bloc le plus précis ne s'exécute jamais, pour aucune requête.

✗ Incorrect 
location ~ ^/api { }
location ~ ^/api/v2/users$ { }
# the second is unreachable
✓ Correct 
location ~ ^/api/v2/users$ { }
location ~ ^/api { }

Écrire une regex après ^~

^~ prend un préfixe littéral. nginx charge le fichier sans broncher et le bloc ne correspond simplement jamais à rien, ce qui le rend difficile à repérer en revue.

✗ Incorrect 
location ^~ "\.php$" { deny all; }
✓ Correct 
location ~ \.php$ { deny all; }

Supposer que la query string participe à la correspondance

La query string est détachée pendant la normalisation, un location ne peut donc jamais correspondre dessus. Lisez plutôt $arg_name dans le bloc.

✗ Incorrect 
location /search?q= { }
# never matches anything
✓ Correct 
location /search {
    if ($arg_q = "") { return 400; }
}

Ce que vous pouvez faire avec le testeur de location nginx

Vérifier une configuration avant qu'elle n'atteigne la production
Raisonnez sur le routage d'un bloc server que vous avez modifié mais pas déployé. La défaillance ainsi attrapée est celle qui n'apparaît que sous une forme d'URI particulière, exactement le genre qu'un smoke test après reload a tendance à manquer.
Découvrir pourquoi une règle a cessé de fonctionner
Une regex qui s'exécutait et ne s'exécute plus est presque toujours victime de l'ordre : quelque chose a correspondu plus tôt, ou un ^~ est apparu au-dessus. Le tableau marque le bloc inaccessible et nomme le bloc qui a pris la requête.
Auditer un répertoire d'upload ou de médias
Chargez le préréglage qui reproduit la forme upload-exécution, puis collez vos propres chemins. Si une regex PHP prend les requêtes dans un répertoire ouvert en écriture, le diagnostic le dit et nomme les deux blocs.
Clore un commentaire de revue avec une preuve
Copier le lien capture la configuration et l'URI exactes dans le fragment de l'URL. Le déposer dans une pull request remplace une discussion sur la priorité par un tableau de décision que n'importe qui peut rejouer.
Enseigner l'algorithme de sélection
Les deux tableaux de référence sont du matériel statique et indexable vers lequel pointer, et les puces de préréglage démontrent chaque piège sans avoir besoin de casser un serveur. L'exemple du ^~ en particulier clôt vite le débat.

Comment fonctionne la sélection des location nginx

La normalisation a lieu avant de consulter le moindre location
L'URI est décodée des pourcentages, les segments . et .. sont résolus et les slashs répétés fusionnés, et seulement ensuite un location est choisi. Un %2F décodé devient un vrai séparateur et participe à cette résolution, donc /a/b%2F..%2Fzz est comparé comme /a/zz. Trois caractères décodés font exception et restent littéraux : %25, %23 et %3F — c'est pourquoi /a%3Fx=1 a un point d'interrogation dans son chemin et une query string vide. Ici un + n'est pas un espace ; seul %20 l'est. Une traversée au-dessus de la racine et un échappement invalide sont tous deux rejetés avec 400 avant même que la correspondance ne commence.
La longueur du préfixe décide, l'ordre dans la configuration non
Chaque location de préfixe qui correspond est comparé et le plus long gagne, qu'il apparaisse en premier ou en dernier dans le fichier. La comparaison porte sur les caractères, pas sur les segments de chemin, donc /static correspond à /staticfoo. Le gagnant est mémorisé au lieu d'être utilisé tout de suite, parce que la phase des regex peut encore le supplanter.
^~ supprime les regex ; il n'augmente pas la priorité
Le modificateur n'est consulté que sur le préfixe qui a déjà gagné sur la longueur. Si un préfixe simple plus long correspond aussi, c'est lui qui est mémorisé et la phase des regex s'exécute comme d'habitude — le bloc ^~ n'a alors aucun effet sur la requête. Placer ^~ sur un location imbriqué ne protège pas d'une regex déclarée au niveau externe, et il ne supprime jamais les regex imbriquées dans son propre bloc.
Les regex s'exécutent dans l'ordre du fichier et la première correspondance met fin à la recherche
nginx garde les location regex dans l'ordre où ils ont été écrits et ne les trie pas. Spécificité, longueur et ancrage n'ont aucune incidence sur celui qui est essayé en premier : un motif précis placé sous un motif large est de la configuration morte. Un location regex qui a correspondu est quand même parcouru en profondeur, ses location imbriqués sont donc examinés ensuite.
PCRE et ECMAScript ne sont pas le même langage
nginx compile les regex de location avec PCRE, sans mode UTF ni multiligne : les motifs opèrent donc sur des octets et ^ n'ancre qu'au début de l'URI. Une différence a un poids de sécurité : le $ de PCRE correspond aussi juste avant un saut de ligne final, donc une URI se terminant par %0A satisfait quand même \.php$ alors qu'un moteur JavaScript refuserait. Ce comportement est émulé ici et signalé, parce que c'est une manière connue de passer sous des règles fondées sur l'extension du fichier.

Bonnes pratiques pour les location nginx

Protégez les répertoires accessibles en écriture avec ^~, pas avec un préfixe simple
Tout répertoire qui accepte des uploads a besoin de location ^~ /uploads/ pour que la phase des regex ne puisse pas confier un fichier stocké à un interpréteur. Un préfixe simple a l'air équivalent et ne l'est pas.
Donnez un slash final aux préfixes de répertoire
Écrivez location /static/ plutôt que location /static, sauf si vous voulez délibérément que /staticfoo et /static-backup soient servis par le même bloc. Ajoutez un location = /static séparé quand le chemin nu doit aussi être traité.
Ordonnez les regex de la plus spécifique à la moins spécifique
La première correspondance l'emporte, donc un motif large au-dessus d'un motif précis rend le précis inaccessible. Garder peu de regex et les ordonner délibérément se maintient plus facilement que raisonner après coup sur les recouvrements.
Ancrez les regex censées correspondre à un préfixe de chemin
location ~ /admin cherche n'importe où dans l'URI et correspond à /public/admin/x. Écrivez ~ ^/admin quand vous voulez dire le début. N'ancrer qu'à la fin est normal et correct pour le routage par extension.
Revérifiez le routage après tout réordonnancement
Déplacer des blocs est sans risque pour les préfixes et change le comportement des regex. Comme un diff qui ne fait que réordonner des lignes paraît inoffensif en revue, rejouer les URI concernées est le moyen le moins cher de s'en apercevoir.

Questions fréquentes sur le testeur de location nginx

Comment savoir quel location nginx a sélectionné ?
Collez la configuration et l'URI de la requête dans ce testeur pour voir le bloc gagnant et pourquoi chacun des autres a été éliminé. Sur un serveur en fonctionnement, ajoutez error_log /var/log/nginx/debug.log debug; et cherchez la ligne « using configuration », qui nomme le location retenu. Les deux approches répondent à des questions différentes : le journal dit ce qu'un serveur en production a fait, cette page dit ce que ferait une configuration que vous n'avez pas encore déployée.
Pourquoi ma regex de location nginx ne fonctionne-t-elle pas ?
Généralement pour l'une de trois raisons, et le tableau de décision indique laquelle. Une regex antérieure a déjà correspondu, la vôtre n'a donc jamais été exécutée — les regex sont testées dans l'ordre du fichier et la première correspondance l'emporte. Ou bien le plus long préfixe correspondant porte ^~, ce qui saute complètement la phase des regex. Ou bien la regex est correcte mais l'URI n'est pas celle que vous croyez : la correspondance s'exécute sur le chemin normalisé, après décodage des pourcentages et résolution des .., query string retirée.
Pourquoi ma correspondance exacte ne se déclenche-t-elle pas ?
Un location = exige que l'URI entière soit égale, pas qu'elle commence par le motif. location = /a/ ne correspond pas à /a, et location = /a ne correspond pas à /a/b. Les slashs finaux sont ici des caractères ordinaires, les deux formes sont donc des chaînes différentes. Quand un location exact correspond, la recherche s'arrête immédiatement et rien d'autre n'est même comparé.
nginx compare-t-il la query string dans un bloc location ?
Non. La query string est détachée pendant la normalisation et la sélection du location s'exécute sur le chemin seul. C'est pourquoi location = /a correspond à une requête vers /a?x=/b. Si vous devez brancher sur un paramètre, vous devez lire $arg_name ou $args dans le bloc. Une subtilité qui mérite d'être connue : %3F se décode en un point d'interrogation littéral qui reste dans le chemin, donc /a%3Fx=1 a une query string vide et un chemin contenant ?.
Puis-je utiliser la syntaxe des regex JavaScript dans un location nginx ?
Non — nginx utilise PCRE, et les différences comptent. Cette page s'exécute dans votre navigateur, où seules les expressions régulières ECMAScript existent : les constructions propres à PCRE sont donc détectées et signalées plutôt qu'évaluées de travers en silence — groupes atomiques, quantificateurs possessifs, modificateurs en ligne comme (?i), classes POSIX comme [[:alpha:]], et échappements comme \A et \K que JavaScript lit tranquillement comme des lettres ordinaires. Quand un location est signalé, les candidats restants sont quand même évalués dans l'ordre de nginx, mais le verdict de ce bloc demande vérification sur un vrai serveur. Si vous écrivez le motif lui-même, le testeur de regex couvre en profondeur la syntaxe ECMAScript.
Les correspondances de préfixe des location nginx sont-elles sensibles à la casse ?
Sous Linux, oui — location /Static/ ne correspond pas à /static/x. Sur les systèmes de fichiers insensibles à la casse comme macOS et Cygwin, nginx compare les préfixes sans tenir compte de la casse et force en plus chaque location regex à se comporter comme ~*. Cette page modélise le comportement Linux, celui que les serveurs de production exécutent presque toujours. Si vous développez sur Mac et déployez sous Linux, cette différence peut masquer une règle cassée jusqu'à la mise en production.
try_files change-t-il le bloc location qui a été sélectionné ?
Non. La sélection du location se termine d'abord ; try_files s'exécute ensuite, à l'intérieur du bloc qui a déjà gagné. Si une requête n'atteint jamais le bloc contenant votre try_files, la directive est sans objet — la cause habituelle est une regex ~ \.php$ qui prend la requête avant que le bloc de préfixe portant le repli ait pu agir. Une redirection interne émise plus tard relance la correspondance : une URI réécrite est donc résolue de nouveau contre la liste des location, depuis le début.
Pourquoi nginx renvoie-t-il 301 quand je demande un répertoire sans slash ?
Deux mécanismes différents produisent cela. Si un location dont le nom se termine par / porte proxy_pass ou une autre directive *_pass, une requête vers le même chemin sans le slash reçoit un 301 pendant la sélection du location — avant qu'une seule regex ne soit évaluée. Par ailleurs, le module de fichiers statiques émet un 301 quand le chemin correspond à un vrai répertoire sur le disque. Le premier cas est visible ici ; le second dépend de votre système de fichiers. Ajouter location = /path supprime le premier.
Les blocs location imbriqués changent-ils le résultat ?
Oui, et d'une manière facile à manquer. nginx descend dans le location de préfixe gagnant et parcourt ses enfants : une regex imbriquée est donc essayée avant les regex du niveau parent. Un ^~ sur le bloc externe ne le protège pas de ses propres regex imbriquées, et l'imbrication peut rendre inaccessible un préfixe globalement plus long quand un frère du niveau externe gagne d'abord. Les blocs imbriqués sont modélisés ici avec l'indentation que vous leur avez donnée.
Ma configuration nginx est-elle envoyée quelque part ?
Non. L'analyse et la correspondance se font localement dans votre navigateur avec de simples opérations sur les chaînes — aucun appel serveur, rien n'est conservé. Cela compte plus ici que pour la plupart des outils, parce qu'un vrai bloc server contient des noms d'hôtes en amont, des ports internes, des chemins de certificats et des règles d'authentification. Vous n'avez pas à nous croire sur parole : ouvrez les outils de développement de votre navigateur et regardez le panneau Réseau rester silencieux pendant que vous tapez, ou coupez complètement la connexion et continuez à tester. L'absence de toute requête externe est également imposée par un test de contrat automatisé à chaque build, elle ne peut donc pas régresser en douce.

Outils connexes

Voir tous les outils →

Générateur & Constructeur de commande cURL

Web & API

Construisez des commandes curl dans votre navigateur — méthode, en-têtes, authentification et corps, obtenez instantanément une commande prête à copier. Préréglages Bearer, POST JSON, upload. Gratuit, privé, sans inscription.

Générateur htpasswd — bcrypt, Apache MD5 (apr1), Basic Auth

Web & API

Générez des entrées htpasswd avec bcrypt, Apache MD5 (apr1), SHA-1 et plus. Obtenez des configs Apache, nginx et Docker prêtes à coller. 100 % dans votre navigateur — aucun envoi.

Générateur de balises meta & Open Graph

Web & API

Générez des balises Open Graph, Twitter Card et SEO avec un aperçu en direct pour Google, Facebook et X. 100 % gratuit, dans le navigateur, sans inscription — copiez-collez le code.

Décodeur traceparent — W3C Trace Context

Web & API

Fini de compter les chiffres hex. Décodeur traceparent en ligne, gratuit — tout reste dans le navigateur. Trace ID, span ID, 8 bits trace-flags, tracestate, Datadog/X-Ray/B3.

Outil de déchiffrement AES — compatible OpenSSL et CryptoJS

Outils de sécurité

Déchiffrez de l'AES en ligne — GCM/CBC/CTR, phrase secrète ou clé brute, détection automatique du format OpenSSL et CryptoJS « U2FsdGVkX1 ». 100 % dans le navigateur, les clés ne quittent jamais la page.

Outil de chiffrement AES — GCM, CBC et CTR

Outils de sécurité

Chiffrement AES en ligne gratuit — AES-128/192/256, GCM/CBC/CTR, phrase secrète (PBKDF2) ou clé brute. 100 % dans votre navigateur ; rien n'est envoyé.