Ce guide concerne NGINX Open Source. Vérifiez la version, les modules compilés ou chargés et les particularités de votre paquet.
Deux décisions successives
Pour une requête HTTP, NGINX doit identifier un serveur virtuel puis la location appropriée. L’adresse et le port d’écoute déterminent les candidats ; le nom d’hôte permet de sélectionner un server dans ce groupe. Le serveur par défaut est attaché à l’écoute concernée, pas à un nom universel.
Les locations ne sont pas toutes équivalentes. Une correspondance exacte peut terminer la recherche ; les préfixes et expressions régulières obéissent à leur ordre de sélection documenté. Une réécriture ou une redirection interne peut provoquer une nouvelle recherche. Raisonner seulement sur la première location rencontrée dans le fichier mène à des erreurs.
Sources : NGINX / F5, Module ngx_http_core_module ; NGINX / F5, Beginner’s Guide.
Relier URI et chemin du fichier
root construit le chemin en ajoutant l’URI à la racine configurée. alias remplace la partie de chemin correspondant à la location. Vérifiez explicitement les slashs et le résultat attendu avant de choisir l’une des deux directives ; elles ne sont pas synonymes.
Le fragment suivant sert des fichiers depuis une racine de laboratoire. Il appartient au contexte http ; les fichiers et leurs permissions sont à préparer séparément. L’écoute reste locale. La réussite d’un try_files ne garantit ni l’existence d’un index dans un répertoire ni la possibilité de le lire.
server {
listen 127.0.0.1:8080;
server_name revision.example;
root /srv/revision/public;
location / {
try_files $uri $uri/ =404;
}
}Sources : NGINX / F5, Module ngx_http_core_module.
Interpréter la réponse sans raccourci
Un 404 peut venir du chemin calculé, d’un fichier absent ou d’un autre server sélectionné. Un 403 peut correspondre à une restriction explicite, à des permissions ou à un accès à un répertoire sans index publiable. Le code seul ne départage pas ces causes ; le journal et le chemin attendu sont nécessaires.
Servez seulement un répertoire prévu pour le contenu public. Évitez d’y placer des clés, exports et sauvegardes. Pour un contenu dynamique, expliquez quel gestionnaire traite la requête ; l’existence d’un fichier applicatif ne signifie pas qu’il sera exécuté correctement par une configuration statique.
Sources : NGINX / F5, Module ngx_http_core_module ; NGINX / F5, Module ngx_http_log_module.
Exercice : tracer deux URI
Calculez le chemin de /images/logo.svg dans un server dont root vaut /srv/revision/public. Comparez ensuite avec une location /images/ utilisant alias vers un autre répertoire. Dessinez le préfixe remplacé et la partie conservée avant toute requête.
Pour la recette, fixez le nom d’hôte, le port et l’URI. Un test sur l’adresse IP seule peut utiliser le server par défaut et masquer une erreur de sélection. Conservez la réponse et le journal correspondant, puis poursuivez avec le diagnostic HTTP.
Sources : NGINX / F5, Module ngx_http_core_module ; NGINX / F5, Module ngx_http_log_module.
Sources et portée
Références consultées le . Les exemples utilisent des noms et adresses de documentation à remplacer. Les commandes de lecture affichent l’existant ; les captures et requêtes de diagnostic sont à limiter au périmètre autorisé.
- NGINX / F5 — Module ngx_http_core_module · Référence officielle ; vérifier le périmètre de version · consulté le 3 octobre 2026.
- NGINX / F5 — Beginner’s Guide · Référence officielle ; vérifier le périmètre de version · consulté le 3 octobre 2026.
- NGINX / F5 — Module ngx_http_log_module · Référence officielle ; vérifier le périmètre de version · consulté le 3 octobre 2026.
Retrouver le parcours de lecture F5 NGINX