1024 connexions, multipliées par le nombre de workers
1024 : c’est la valeur inscrite pour worker_connections dans le nginx.conf de nombreux paquets nginx (la directive vaut 512 si elle est absente, et Debian comme Ubuntu livrent 768), un plafond appliqué individuellement à chaque worker. La capacité réelle du serveur à accepter des connexions simultanées se calcule en multipliant cette valeur par worker_processes, le nombre de processus workers effectivement lancés. Un serveur avec quatre workers et cette valeur peut ainsi gérer, en théorie, jusqu’à 4096 connexions simultanées, tous usages confondus.
Ce « tous usages confondus » mérite d’être souligné : ce plafond ne compte pas uniquement les connexions entrantes depuis les visiteurs, mais aussi les connexions sortantes ouvertes par nginx lui-même, notamment vers PHP-FPM en amont ou vers un serveur d’origine distant dans une configuration de reverse proxy. Une requête qui nécessite une connexion entrante et une connexion sortante simultanée consomme donc deux unités de ce même plafond partagé.
Ce que révèle vraiment un dépassement
Lorsque ce plafond est atteint, nginx ne renvoie généralement aucun message d’erreur explicite au visiteur concerné : la nouvelle connexion est simplement refusée ou mise en attente selon la configuration du système d’exploitation sous-jacent, produisant côté client une impression de lenteur ou de blocage plutôt qu’un message d’erreur clair permettant d’identifier immédiatement la cause. Le journal d’erreur de nginx, en revanche, consigne l’événement explicitement :
2021/06/23 14:40:07 [alert] 1823#1823: *48291 1024 worker_connections are not enough
Ce message précis, « worker_connections are not enough », constitue la confirmation la plus fiable que ce plafond précis est en cause, plutôt qu’un problème de ressources CPU ou mémoire côté serveur.
Ajuster le réglage sans dépasser les limites système
Augmenter worker_connections reste une opération simple dans le fichier de configuration principal :
events {
worker_connections 4096;
}
Un cas limite important accompagne ce réglage : la valeur choisie ne peut jamais dépasser la limite système de descripteurs de fichiers ouverts autorisée par processus, fixée par ulimit -n au niveau du système d’exploitation, elle-même parfois reprise explicitement par la directive nginx worker_rlimit_nofile. Augmenter worker_connections sans relever également cette limite système laisse le nouveau plafond théorique inatteignable en pratique, puisque le système refusera d’ouvrir davantage de descripteurs que ce qu’il autorise lui-même.
worker_rlimit_nofile 8192;
events {
worker_connections 4096;
}
Avec ce doublement de la limite système par rapport au plafond nginx choisi, une marge reste disponible pour les descripteurs de fichiers utilisés par nginx à d’autres fins (fichiers de journal, sockets internes), en plus des connexions réseau elles-mêmes.
Pièges fréquents
- Relever
worker_connectionssans vérifier ni ajuster la limite système de descripteurs de fichiers, rendant le nouveau plafond purement théorique - Confondre ce réglage avec le nombre de
worker_processeslui-même, alors que la capacité réelle dépend du produit des deux valeurs, jamais de l’une seule prise isolément - Oublier que les connexions sortantes vers PHP-FPM ou une origine distante consomment le même plafond que les connexions entrantes, doublant parfois la consommation réelle par requête traitée
Dimensionner selon le trafic réellement observé
Avant d’augmenter arbitrairement cette valeur, mesurer le nombre de connexions simultanées réellement observées lors d’un pic passé, via les journaux d’accès ou un outil de supervision réseau, donne une base bien plus fiable qu’une valeur ronde choisie au hasard. Une marge de sécurité raisonnable au-dessus de ce pic mesuré évite à la fois le sous-dimensionnement et un gaspillage inutile de ressources système réservées sans jamais être utilisées.
En résumé
Un serveur qui refuse une connexion sans le moindre message d’erreur applique presque toujours une limite qu’on a oublié de revoir depuis l’installation par défaut.
Le message « worker_connections are not enough » dans le journal d’erreur nginx désigne sans ambiguïté ce plafond précis, et invite à revoir conjointement cette valeur et la limite système de descripteurs de fichiers qui l’encadre.
Correction du 11 octobre 2026 : la valeur par défaut de la directive worker_connections est 512 ; 1024 est la valeur inscrite dans le fichier de configuration livré par plusieurs paquets, Debian et Ubuntu livrant 768.
