Ce guide concerne NGINX Open Source. Vérifiez la version, les modules compilés ou chargés et les particularités de votre paquet.
Relier la méthode au comportement recherché
Un upstream décrit les serveurs susceptibles de traiter une requête. Round robin pondéré, least_conn et les méthodes fondées sur un hash répondent à des besoins différents. La répartition ne garantit pas que le nombre de requêtes observé sera égal à chaque instant : poids, connexions et affinité interviennent.
least_conn choisit selon les connexions actives, en tenant compte des poids. ip_hash cherche une affinité liée à l’adresse cliente ; derrière un NAT, plusieurs utilisateurs peuvent partager cette valeur. Un choix de méthode doit être confronté aux sessions et à la variabilité du coût des requêtes.
L’upstream choisit un serveur selon la méthode et son état. Les échecs réellement observés alimentent la décision de retrait et les conditions de nouvelle tentative.
Télécharger le schéma en SVG · version claireSources : NGINX / F5, Module ngx_http_upstream_module ; NGINX / F5, Using nginx as HTTP load balancer.
Comprendre ce qui détecte une panne
Les mécanismes passifs apprennent des échecs observés pendant les requêtes. max_fails et fail_timeout déterminent la prise en compte d’un serveur indisponible dans les conditions documentées. Les contrôles actifs intégrés d’état de santé relèvent des fonctionnalités commerciales ; ne les attribuez pas au seul fragment OSS.
Le groupe ci-dessous est un exemple à placer dans http. Il suppose deux serveurs locaux de laboratoire. Une zone upstream partage l’état entre workers. Les paramètres de panne ont des exceptions, notamment pour un groupe à un seul serveur ; lisez la référence avant d’interpréter un résultat.
upstream revision_app {
zone revision_app 64k;
least_conn;
server 127.0.0.1:9001 max_fails=2 fail_timeout=10s;
server 127.0.0.1:9002 max_fails=2 fail_timeout=10s;
keepalive 16;
}Sources : NGINX / F5, Module ngx_http_upstream_module ; NGINX / F5, Using nginx as HTTP load balancer.
Réutilisation et retrait d’un serveur
Le keepalive upstream conserve des connexions inactives pour les réutiliser. Sa taille ne constitue pas une limite globale du nombre de connexions aux serveurs. Le protocole et les en-têtes de connexion doivent être cohérents ; vérifiez les valeurs par défaut de votre version au lieu de supposer celles d’un ancien exemple.
Pour retirer un serveur, préparez la modification, validez puis rechargez. Les échanges déjà pris en charge et les nouveaux échanges doivent être considérés séparément. Les retries ne sont pas gratuits : une requête dont l’effet métier a commencé ne doit pas être rejouée sans examiner l’idempotence et les conditions de proxy_next_upstream.
Sources : NGINX / F5, Module ngx_http_upstream_module ; NGINX / F5, Module ngx_http_proxy_module ; NGINX / F5, Controlling nginx.
Exercice : répartition inégale et panne
Votre laboratoire montre davantage de requêtes sur un serveur. Comparez la méthode, les poids, l’affinité, l’état passif et les connexions actives. Un simple décompte de réponses n’établit pas à lui seul un défaut de répartition. Relevez aussi les tentatives upstream dans les journaux.
Préparez ensuite un scénario où un serveur devient indisponible. Précisez le type d’échec, la méthode de retrait, le comportement attendu pour une requête sûre et celui pour une opération métier. La recette doit démontrer le comportement observé, sans promettre une absence universelle d’erreurs pendant la panne.
Sources : NGINX / F5, Module ngx_http_upstream_module ; NGINX / F5, Module ngx_http_proxy_module ; NGINX / F5, Module ngx_http_log_module.
Sources et portée
Les dates de consultation et les versions applicables sont précisées pour chaque référence ci-dessous. 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_upstream_module · Référence officielle ; vérifier le périmètre de version · consulté le 3 octobre 2026.
- NGINX / F5 — Using nginx as HTTP load balancer · Référence officielle ; vérifier le périmètre de version · consulté le 3 octobre 2026.
- NGINX / F5 — Module ngx_http_proxy_module · Référence officielle ; vérifier le périmètre de version · consulté le 3 octobre 2026.
- NGINX / F5 — Controlling nginx · 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