Header title

Guide Développeur : Générateur de Configuration Nginx Upstream & Équilibrage de Charge

Générez des blocs upstream Nginx prêts pour la production avec round-robin, least_conn, ip_hash, connexions persistantes keepalive et vérifications d'état passives.

Presets label
Input label
Server nodes label4 nodes
#1
Weight:
Max Fails:
Fail Timeout:
Max Conns (0=inf):
#2
Weight:
Max Fails:
Fail Timeout:
Max Conns (0=inf):
#3
Weight:
Max Fails:
Fail Timeout:
Max Conns (0=inf):
#4
Weight:
Max Fails:
Fail Timeout:
Max Conns (0=inf):
Performance tuning
Synchronizes node states across worker processes in multi-core environments.
Pool Conns:
Idle Timeout:
Reduces TCP handshake latency up to 60% by maintaining persistent HTTP/1.1 sockets.
Proxy settings
Server Port:
Server Name:
Location Path:
1# ========================================================
2# Upstream Pool: microservice_api_cluster
3# Load Balancing Method: LEAST_CONN
4# Generated by ToolsAA (100% Client-Side Private Generator)
5# ========================================================
6upstream microservice_api_cluster {
7 # Shared memory zone across all worker processes
8 zone microservice_api_zone 64k;
9
10 # Directs traffic to the server with fewest active connections
11 least_conn;
12
13 # Backend server cluster nodes
14 server 10.0.1.11:8080 weight=5 max_fails=3 max_conns=500;
15 server 10.0.1.12:8080 weight=5 max_fails=3 max_conns=500;
16 server 10.0.1.13:8080 weight=3 max_fails=3 max_conns=300;
17 server 10.0.1.99:8080 max_fails=3 backup;
18
19 # Upstream HTTP/1.1 persistent connection pool
20 keepalive 32;
21 keepalive_requests 1000;
22 keepalive_timeout 60s;
23}
Stats card1
3 Primaries/1 Backups
Active cluster load capacity: 75%
Stats card2
least conn
Worker sync enabled via 64k memory zone
Stats card3
32 idle sockets pool
Standard HTTP/1.1 connection reuse

Client-Side Processing

High-performance processing executed entirely in browser memory.

Zero Server Upload Privacy

All data payloads remain strictly local with zero external server communication.

Production Ready Export

Clean, optimized output formats ready for immediate deployment.

Référence technique et guide d'architecture

Guide Développeur : Générateur de Configuration Nginx Upstream & Équilibrage de Charge — Guide de référence

Générez des blocs upstream Nginx prêts pour la production avec round-robin, least_conn, ip_hash, connexions persistantes keepalive et vérifications d'état passives.

Paramètres clés et contrôles

serverdirective (string)

Définit l'adresse du serveur backend (IP ou FQDN), le port et les paramètres de contrôle tels que weight, max_fails, fail_timeout, backup et down.

Par défaut : server 127.0.0.1:8080 weight=1 max_fails=1 fail_timeout=10s
algorithmdirective (enum)

Sélectionne l'algorithme d'équilibrage : round-robin pondéré (par défaut), least_conn (serveur ayant le moins de connexions actives), ip_hash (persistance par IP client) ou hash cohérent.

Par défaut : round-robin (implicite)
keepaliveinteger

Fixe le nombre maximal de connexions keepalive inactives vers les serveurs upstream conservées dans le cache de chaque processus worker.

Par défaut : 32
keepalive_requestsinteger

Définit le nombre maximal de requêtes pouvant être traitées via une même connexion keepalive avant sa fermeture.

Par défaut : 1000
keepalive_timeoutdurée (string)

Définit la durée pendant laquelle une connexion keepalive inactive vers un serveur upstream reste ouverte.

Par défaut : 60s
zonestring

Alloue une zone de mémoire partagée pour synchroniser l'état d'exécution et la configuration du groupe upstream entre tous les workers.

Par défaut : upstream_backend 64k

Conseils de pro et bonnes practices

HTTP/1.1 est obligatoire pour le Keepalive Upstream

Spécifier 'keepalive 32;' ne suffit pas pour activer la réutilisation des connexions. Dans votre bloc location, vous devez obligatoirement ajouter 'proxy_http_version 1.1;' et vider l'en-tête via 'proxy_set_header Connection "";'. À défaut, Nginx utilisera HTTP/1.0 avec 'Connection: close', réinstanciant une poignée de main TCP à chaque requête.

Maintenance sans interruption avec les drapeaux backup et down

Désactivez un nœud en maintenance avec 'down;' pour interrompre le routage sans altérer la cohérence des tables de hachage. Utilisez 'backup;' pour désigner des serveurs de secours sollicités uniquement si tous les serveurs primaires sont déclarés défaillants.

Hachage cohérent pour les clusters avec cache

Pour distribuer les requêtes vers des fermes de serveurs de cache ou de rendu d'applications, utilisez 'hash $request_uri consistent;' plutôt que round-robin. Cela évite l'invalidation massive des caches lors de l'ajout ou du retrait dynamique de serveurs.

Sécuriser proxy_next_upstream contre les doubles transactions

Protégez vos bases de données contre les réexécutions intempestives en configurant 'proxy_next_upstream error timeout http_502 http_503;'. N'ajoutez l'argument 'non_idempotent' que si vos points de terminaison d'API POST et PATCH sont strictement idempotents.

Pièges courants et dépannage

Upstream timed out (110: Connection timed out) ou erreur 504 Gateway Timeout

Vérifiez les règles de pare-feu de vos backends et ajustez les valeurs de proxy_connect_timeout, proxy_read_timeout et proxy_send_timeout. Sur les systèmes à fort trafic, augmentez le nombre de descripteurs de fichiers (worker_rlimit_nofile) et worker_connections.

ip_hash achemine l'intégralité du trafic vers un seul et même serveur

Si Nginx est positionné derrière Cloudflare, un AWS ALB ou un CDN, l'IP vue par Nginx sera toujours celle du proxy amont. Remplacez ip_hash par 'hash $http_cf_connecting_ip consistent;' ou activez le module real_ip avec 'set_real_ip_from' et 'real_ip_header X-Forwarded-For;'.

Erreurs 502 Bad Gateway sporadiques lors de fortes hausses de trafic

La file d'attente des sockets du backend (listen backlog) est probablement saturée. Augmentez la directive système net.core.somaxconn et spécifiez le paramètre 'max_conns' sur la directive server pour plafonner la charge concurrente admissible.

Foire aux questions (FAQ)

Quelle est la différence entre Round Robin, least_conn et ip_hash ?▼

Round Robin répartit les requêtes de manière séquentielle en respectant le poids (weight) de chaque serveur. least_conn achemine chaque nouvelle requête vers le serveur ayant le plus faible nombre de connexions actives, idéal pour des traitements aux durées hétérogènes. ip_hash hache les trois premiers octets de l'IP du client pour assurer l'affinité de session avec le même serveur.

Comment fonctionnent les tests d'intégrité passifs sous Nginx Open Source ?▼

Nginx Open Source utilise une surveillance passive basée sur 'max_fails' et 'fail_timeout'. Si un serveur échoue max_fails fois consécutives durant fail_timeout, il est temporairement exclu du routage pour la durée de fail_timeout. Les sondes actives périodiques (health_check) nécessitent Nginx Plus ou des extensions Lua tierces.

Pourquoi la directive 'proxy_set_header Connection "";' est-elle indispensable avec keepalive ?▼

Par défaut, Nginx délègue en HTTP/1.0 et positionne 'Connection: close'. Le passage à HTTP/1.1 associé à l'effacement de l'en-tête Connection informe le serveur backend que le socket TCP doit rester ouvert pour accueillir les requêtes suivantes issues du pool keepalive.

Comment gérer la résolution DNS dynamique pour les serveurs upstream ?▼

Dans la version open source de Nginx, les noms de domaine des blocs upstream ne sont résolus qu'au démarrage du processus. Pour les environnements dynamiques (Kubernetes, AWS ECS), affectez l'URL du backend à une variable (ex. 'set $backend "http://api.internal:8080"; proxy_pass $backend;') et configurez une directive 'resolver' assortie d'un délai de validité (valid=10s).

Outils et utilitaires connexes

Tous les outils →
Convertisseur Cron vers Kubernetes CronJob YAML et Générateur de Spécificationdeveloper

Convertissez des expressions crontab classiques en manifestes Kubernetes CronJob prêts pour la production avec restartPolicy, concurrencyPolicy, quotas de ressources et gestion des fuseaux horaires.

Ouvrir l'outil→
Générateur de Schémas GraphQL SDL depuis JSON (Types, Queries & Inputs) - Guide Développeurdeveloper

Générez des définitions de types d'objets, de types d'entrée (inputs) et de schémas de requêtes en syntaxe GraphQL SDL à partir d'objets JSON.

Ouvrir l'outil→
Générateur de Règles d'Alerte et d'Enregistrement Prometheus (PromQL) - Guide Développeurdeveloper

Créez et validez visuellement des règles d'alerte et d'enregistrement PromQL, des seuils, des étiquettes et des annotations de runbook.

Ouvrir l'outil→
Guide Développeur : Générateur de Types de Résolveurs TypeScript depuis GraphQL SDLdeveloper

Générez des interfaces de résolveurs TypeScript strictement typées, des arguments de requêtes/mutations et des types de contexte depuis vos schémas GraphQL SDL.

Ouvrir l'outil→
Guide de développement : Convertisseur cURL vers C# (.NET HttpClient, RestSharp et Flurl)developer

Convertissez vos requêtes cURL en code C# idiomatique pour .NET HttpClient, RestSharp ou Flurl.Http avec les meilleures pratiques de programmation asynchrone et de pool de connexions.

Ouvrir l'outil→
Guide développeur du convertisseur cURL vers Java (Java 11+ HttpClient, OkHttp & Spring WebClient)developer

Convertissez vos commandes cURL en requêtes HTTP Java prêtes pour la production avec java.net.http.HttpClient natif, OkHttp3 ou Spring WebClient.

Ouvrir l'outil→