Ce guide concerne NGINX Open Source. Vérifiez la version, les modules compilés ou chargés et les particularités de votre paquet.
Une modification sur disque n’est pas un changement servi
Le master gère les workers et reçoit les signaux de contrôle. Une modification de fichier prépare un état ; elle ne remplace pas automatiquement la configuration des workers. Le test de configuration et le rechargement sont deux opérations distinctes, suivies d’une observation du service.
nginx -t contrôle la syntaxe et l’ouverture des fichiers requis selon les règles documentées. Ce test ne démontre pas le fonctionnement métier de l’application ou la disponibilité de tous les upstreams. Une validation réussie doit être suivie d’une recette représentative.
Les signaux de contrôle distinguent également l’arrêt rapide et l’arrêt gracieux. Dans la commande nginx -s, stop demande un arrêt rapide et quit un arrêt gracieux. Ne remplacez pas un reload par un stop/start sans analyser l’impact sur les échanges en cours et le gestionnaire de services.
Sources : NGINX / F5, Controlling nginx ; NGINX / F5, Command-line parameters.
Comprendre le rechargement gracieux
Lors d’un rechargement, le master vérifie et tente d’appliquer la nouvelle configuration. Si l’opération réussit, de nouveaux workers sont lancés et les anciens terminent leurs échanges selon le cycle documenté. Les connexions longues doivent être examinées dans le plan de maintenance.
Les commandes ci-dessous modifient le service uniquement après un test réussi. Utilisez l’outil de gestion propre à votre installation si elle est pilotée par un gestionnaire de services. Vérifiez que la commande cible le bon binaire, le bon fichier et la bonne instance.
sudo nginx -t && sudo nginx -s reloadSources : NGINX / F5, Controlling nginx ; NGINX / F5, Command-line parameters.
Prévoir observation et retour arrière
Conservez une version connue de la configuration, l’état avant changement et une requête de recette. Après rechargement, vérifiez le journal, les workers et le comportement attendu. La fin de la commande ne remplace pas ces observations, notamment si plusieurs instances ou conteneurs sont présents.
Un retour arrière consiste à rétablir une configuration appropriée, la valider puis l’appliquer par la procédure prévue. Il ne répare pas automatiquement une dépendance externe devenue indisponible. Distinguez erreur de configuration, permissions et panne d’un backend avant de relancer plusieurs fois le service.
Sources : NGINX / F5, Controlling nginx ; NGINX / F5, Module ngx_http_log_module.
Exercice : test réussi, réponse inchangée
Une configuration est valide mais la requête reçoit toujours l’ancienne réponse. Vérifiez instance, inclusion, signal, journal et sélection du server. Imaginez aussi une connexion longue encore prise en charge par un ancien worker ; elle ne signifie pas nécessairement que le reload a échoué.
Le compte rendu doit établir les transitions : fichier préparé, validation, application et recette. Aucun résultat n’est fourni comme s’il provenait d’un serveur testé. Ce raisonnement évite de confondre une commande réussie avec le service effectivement observé.
Sources : NGINX / F5, Controlling nginx ; NGINX / F5, Module ngx_http_core_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 — Controlling nginx · Référence officielle ; vérifier le périmètre de version · consulté le 3 octobre 2026.
- NGINX / F5 — Command-line parameters · 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.
- NGINX / F5 — Module ngx_http_core_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