Quitter Apache pour nginx ou Caddy ? Je les ai mesurés : sous charge, nginx débite 3 fois plus en PHP

Sommaire (8 parties)

J'héberge sur un serveur dédié, sous Debian (un système Linux), les sites de mes clients et mes projets personnels. Un serveur web est le logiciel qui reçoit les demandes des navigateurs, les requêtes, et renvoie les pages. Le mien s'appelle Apache. Le 11 novembre 2026, le projet Apache publie la version 2.4.71 : elle corrige une faille critique dans l'une de ses extensions, le module HTTP/2. Faut-il quitter Apache pour nginx ou Caddy, deux autres serveurs web très utilisés ?

Pour décider, j'ai lu l'avis de sécurité et regardé ce que fait mon serveur quand une faille tombe. Puis j'ai mesuré quatre serveurs web (Apache, nginx, Caddy et OpenLiteSpeed) sur le même PHP, le langage de nombreux sites dont WordPress. Ma réponse : la faille n'est pas une raison de migrer, mais le débit en est peut-être une. Le débit est le nombre de requêtes qu'un serveur web traite par seconde.

La faille en clair : ce qu'elle permet, et qui est touché

La faille porte le numéro CVE-2026-119618. Un CVE est l'identifiant public d'une faille connue. Celle-ci touche mod_http2, le module d'Apache qui parle HTTP/2, la version moderne du protocole web. Deux tâches du serveur web qui travaillent en même temps se partagent une zone de mémoire sans s'attendre : elle se corrompt. Un attaquant pourrait en profiter pour faire tourner ses propres commandes sur la machine : c'est une exécution de code à distance. L'avis d'Apache classe la faille « critical ».

Les versions touchées vont de 2.4.55 à 2.4.70. Le correctif arrive dans la 2.4.71, publiée le 11 novembre 2026. La faille a été signalée une première fois le 26 octobre, puis le 3 novembre. Il a donc fallu 16 jours pour livrer le correctif après le premier signalement. Red Hat la note 9,8 sur 10 en gravité. Selon Wiz, un éditeur de sécurité, aucun code d'exploitation n'était public et aucune attaque n'était signalée à la publication de son billet.

Les découvreurs cités sont l'outil automatique OSS Scanner d'Anthropic et deux chercheurs de Google Cloud. Je précise que j'utilise l'assistant Claude d'Anthropic, donc j'ai un lien avec l'un d'eux.

Savoir si tu es exposé, en trois commandes

Sur Debian, trois commandes suffisent :

apache2 -v
apt policy apache2
apache2ctl -M | grep http2

La première affiche la version. La deuxième compare la version installée à celle du dépôt, le serveur de paquets de Debian. La troisième dit si le module HTTP/2 est chargé. La faille vise ce module : sans lui, elle ne te concerne pas. Sur Debian 13 (trixie), la version corrigée s'écrit 2.4.71-1~deb13u1 : le début est le numéro d'Apache, la fin est la révision du paquet Debian.

Debian a repris ici la version publiée par le projet Apache, la 2.4.71, donc le numéro affiché par apache2 -v suffit. Ce n'est pas vrai partout : une distribution qui corrige sans changer le numéro te trompe si tu compares seulement à l'avis d'Apache. Compare au paquet de ta distribution. Le suivi de sécurité Debian donne la version corrigée de chaque CVE.

En attendant le correctif, Wiz propose de retirer HTTP/2 avec une ligne de configuration, la directive Protocols http/1.1. Je n'ai pas testé ce contournement.

Ce qui décide vraiment : le temps entre l'avis et ton serveur corrigé

Ma première question n'était pas « quel serveur est le plus sûr ? » mais « combien de temps suis-je resté exposé ? ». Trois délais s'enchaînent entre la découverte de la faille et mon serveur corrigé :

1. Apache écrit et publie le correctif : 16 jours après le premier signalement, comme vu plus haut.
2. Debian le reprend dans son dépôt de sécurité. Son avis DSA-6620-1 date du 12 novembre à 09 h 54 UTC, environ un jour après Apache.
3. Mon serveur l'installe.

Les deux premiers délais ne dépendent pas de moi. Le troisième, si : mon serveur dédié installe seul les mises à jour de sécurité de Debian une fois par jour, avec unattended-upgrades. Cette fois, son passage n'avait pas encore eu lieu quand j'ai appris la faille, et j'ai installé le correctif à la main. Depuis, j'ai réglé sur une fois par heure les deux minuteurs de systemd, le gestionnaire de services de Debian : apt-daily cherche, apt-daily-upgrade installe. Deux trous restent : aucun redémarrage automatique après une mise à jour du noyau, aucun mail en cas d'échec.

Changer de serveur ne raccourcit aucun de ces trois délais. nginx et Caddy publient eux aussi des avis de sécurité : liste nginx, liste Caddy. Un Apache corrigé dès que Debian publie vaut mieux qu'un nginx qu'on oublie de mettre à jour pendant un mois. La sécurité ne départage donc pas les serveurs. Reste le débit, et celui-là se mesure.

Le banc de test : quatre serveurs, les mêmes pages

Je voulais des chiffres sur ma configuration, pas ceux d'un autre. J'ai donc monté un banc. Voici ses réglages :

• Quatre serveurs web, en version du 13 novembre 2026 : Apache 2.4.71 (corrigé), nginx 1.31.8 et Caddy 2.11.9. Le quatrième est OpenLiteSpeed 1.9.4, la version libre de LiteSpeed. Chacun tourne dans un conteneur Docker, une boîte isolée qui ne touche pas au reste de ma machine.
• Le même PHP-FPM pour tous : le service qui exécute les pages écrites en PHP (version 8.3.36), avec 32 processus fixes. OpenLiteSpeed est mesuré de deux façons. Avec LSAPI, le protocole de LiteSpeed pour parler à PHP, il utilise le PHP 8.2 livré dans son image : c'est son mode normal. Avec FPM, je le branche sur le même PHP-FPM que les autres. Je note ce second mode « OLS + FPM ».
• Deux pages : un fichier HTML statique de 20 329 octets, et un script PHP qui écrit « ok ». PHP ne fait presque rien, donc je mesure surtout le serveur web.
• L'outil de charge est wrk, lancé sur la même machine, un PC Windows qui fait tourner Linux grâce à WSL2. Elle compte 24 cœurs, les unités de calcul du processeur. Il ouvre un nombre fixe de connexions simultanées, c'est-à-dire de clients qui envoient leurs requêtes en même temps, pendant cinq secondes. Je donne la médiane de trois passes.
• Configuration minimale écrite à la main pour Apache, nginx et Caddy. Il n'y a que du HTTP : pas de HTTPS (la connexion chiffrée), pas de HTTP/2, pas de journal d'accès (la liste des pages demandées). Deux réglages sortent des valeurs par défaut. Apache accepte 1 000 requêtes par connexion au lieu de 100. nginx accepte 1 024 connexions par processus de travail. OpenLiteSpeed garde la configuration d'origine de son image, avec quelques coupes : journal d'accès, QUIC (le HTTP/3), compression et lecture du .htaccess. Seul le test dédié lit ce fichier. Je lui donne 32 processus PHP.

La commande type, ici pour 64 connexions sur la page PHP :

wrk -t4 -c64 -d5s --latency http://web/index.php

J'ai fait varier -c (les connexions simultanées) de 1 à 1 024 sur chaque page : c'est le « balayage ».

Deux mesures reviennent. Les requêtes par seconde donnent le débit. Le p99 est le délai que seules 1 % des requêtes dépassent : c'est le pire cas courant.

Limites : une seule machine, une page PHP triviale, pas de HTTPS, et le générateur de charge partage ses cœurs avec les serveurs. Ces chiffres donnent des ordres de grandeur, pas un verdict.

Deux épisodes de la mesure méritent d'être dits. Une première mesure PHP donnait à nginx deux fois moins que toutes les suivantes : je l'ai écartée. Je l'ai refaite à 64 connexions en alternant les serveurs, quatre fois de suite, pour que l'état de la machine pèse autant sur chacun. C'est la « série alternée ». Par ailleurs, deux réglages essayés en route ont fait baisser le débit. Chez Apache, c'est la réutilisation des connexions vers PHP-FPM. Chez nginx, ce sont les connexions persistantes vers PHP-FPM : 5,0 mille requêtes par seconde à 64 connexions, au lieu de 36,1. Je n'ai pas cherché pourquoi.

Les résultats : OpenLiteSpeed et nginx devant, Apache qui plafonne en PHP

À 64 connexions simultanées (tableaux plus bas), nginx sert la page statique environ 2,8 fois plus vite qu'Apache. Pour la page PHP, c'est environ 3 fois plus vite. Toujours en PHP, l'écart tombe à 1,5 fois à 16 connexions (17,4 contre 11,8 mille requêtes par seconde). La série alternée confirme l'écart en PHP : 35,9 contre 11,0 mille requêtes par seconde pour nginx et Apache, soit 3,3 fois. Les courbes montrent ce qui se passe quand la charge monte.

En PHP, Apache plafonne. Son débit cesse d'augmenter dès 16 connexions, à environ 11,8 mille requêtes par seconde, et reste là jusqu'à 1 024. nginx et Caddy continuent de monter. À 1 024 connexions, le p99 d'Apache grimpe à environ 1,1 seconde, contre 28 ms pour nginx et 45 ms pour Caddy.

Apache y perd aussi des connexions. wrk y compte des connexions coupées ou expirées, à hauteur de 4,8 % du nombre de requêtes servies. nginx et Caddy comptent 7 erreurs en tout sur la même passe. Je n'ai pas cherché la cause.

OpenLiteSpeed passe devant nginx en PHP. Avec son PHP intégré, il tient de 68,3 à 72,8 mille requêtes par seconde entre 64 et 1 024 connexions. Son p99 est d'environ 21 ms à 1 024. La série alternée donne 63,8 mille à 64 connexions, contre 35,9 pour nginx. Avec le même PHP-FPM que les autres, il fait 51,3 mille, mais il est moins régulier. Il compte quelques dizaines d'erreurs sur 550 000 requêtes environ. À 1 024 connexions, une passe sur trois n'a rien servi. Deux réserves : son mode normal utilise PHP 8.2 et non 8.3, et je n'ai pas expliqué l'écart avec nginx.

Sur la page statique, l'histoire change. nginx culmine à 64 connexions (179,0 mille requêtes par seconde) puis baisse à 90,4 mille à 1 024. Caddy monte jusqu'au bout et dépasse alors Apache (80,1 contre 59,5 mille). Pour Apache, wrk compte des connexions coupées à hauteur de 4,3 % du nombre de requêtes servies dès 256 connexions.

OpenLiteSpeed égale nginx à 16 connexions (103,8 contre 100,8 mille) et plafonne à 122,6 mille à 64. Il passe devant nginx à partir de 256 (132,2 contre 119,5). Ses passes à 1 024 connexions vont de 91 à 145 mille : retiens l'ordre de grandeur, pas le chiffre. La page ne touche pas à PHP, j'ai donc regroupé les six passes des deux modes.

Pour reprendre les chiffres exacts, en milliers de requêtes par seconde :

Deux autres mesures complètent le tableau. La première porte sur le .htaccess, un petit fichier de configuration qu'on dépose dans un dossier du site et qu'Apache relit à chaque requête. WordPress en écrit un pour ses adresses. Avec AllowOverride All, le réglage qui autorise ces fichiers, et un .htaccess de ce type, Apache perd environ 6,5 % de débit. C'est mesuré sur la page statique, à 64 connexions. Je l'ai mesuré dans une mesure à part (dix secondes par passe), avec et sans le fichier. OpenLiteSpeed lit ce fichier par défaut. Son coût n'est pas stable : 5,7 % de plus en statique, 6,9 % de moins en PHP. Les écarts sont de sens opposé, donc dans le bruit. La seconde mesure est la mémoire :

nginx lance un processus par cœur visible, soit 24 ici (comptés dans le conteneur), ce qui explique sans doute sa mémoire au repos. Retiens plutôt l'ordre de grandeur : sans compter PHP, les quatre restent sous 51 Mio. En mode LSAPI, OpenLiteSpeed lance aussi ses processus PHP dans son conteneur : 35,8 Mio au repos, 70,0 après la charge. Ce n'est pas comparable, car PHP tourne à part pour les autres.

Mon banc dit ce que valent les serveurs web quand PHP ne fait presque rien. Je n'ai pas mesuré une page PHP qui travaille vraiment. Mon avis est que PHP deviendrait alors le facteur limitant, et que l'écart se resserrerait. Un test de Tideways, publié en septembre 2025, trouve d'ailleurs un écart bien plus faible entre nginx et Caddy que le mien. Sur une page HTML, nginx avec PHP-FPM atteint 7 023 requêtes par seconde. FrankenPHP, un serveur construit sur Caddy, en atteint 6 934. Les bancs divergent, d'où l'intérêt de mesurer chez soi.

Le tableau pour choisir : Apache, nginx, Caddy, LiteSpeed

Cloudflare arrive en tête du classement de W3Techs, un site qui recense les technologies utilisées par les sites web, avec 33,8 % des sites. Ce n'est pourtant pas un serveur à installer chez toi : c'est un réseau de diffusion placé devant le tien. Les vraies alternatives à Apache sont donc nginx, Caddy et LiteSpeed. J'ai mesuré sa version libre, OpenLiteSpeed. Je n'ai pas testé LiteSpeed Enterprise, la version payante.

À mes yeux, le point fort de Caddy n'est pas le débit, où il reste derrière nginx. Il obtient et renouvelle seul les certificats HTTPS, auprès d'organismes gratuits comme Let's Encrypt ou ZeroSSL. Un certificat est le fichier qui prouve l'identité d'un site et chiffre la connexion.

Le coût de migration dépend de tes sites. Chez moi, une partie sont des CMS (des outils de gestion de contenu comme WordPress) qui livrent leur propre .htaccess. Sur nginx, chaque règle de réécriture (qui change l'adresse demandée, par exemple vers index.php) se réécrit à la main. Le blog officiel de nginx le dit : nginx ne gère pas les fichiers par dossier d'Apache. Je n'ai trouvé ni convertisseur officiel, ni test indépendant des convertisseurs tiers.

Apache, de son côté, recommande de mettre toute la configuration dans le fichier principal quand on y a accès. C'est le même conseil que mes mesures sur Apache : le .htaccess coûte.

Mon avis : la faille ne justifie pas de migrer, le débit peut-être

Mon avis : la faille n'est pas une raison de migrer. Le délai de correction pèse plus que le choix du serveur, et nginx comme Caddy publient eux aussi des avis. Le débit, lui, peut en être une, si ta charge est surtout du PHP léger ou du statique à fort trafic. Sinon, Apache reste correct à l'échelle de mes sites : un serveur dédié, des sites de clients, des projets personnels.

Si le débit comptait, j'essaierais OpenLiteSpeed en premier. C'est le seul candidat de mon banc qui garde les .htaccess et passe devant nginx en PHP. Je le ferais sur une machine de test, avec mes vrais sites, avant de toucher à ceux des clients.

Ce qui me manque est ailleurs : un mail de compte rendu des mises à jour, et un redémarrage planifié pour le noyau.

Conclusion

Je suis parti chercher un serveur plus sûr. J'ai trouvé une autre variable : le délai entre l'avis de sécurité et le correctif installé sur ta machine. Elle pèse plus que le choix du serveur web.

Les courbes méritent pourtant d'être regardées : elles montrent où chaque serveur décroche. En PHP, OpenLiteSpeed dépasse nginx à 64 et 256 connexions dans ses deux modes, et jusqu'à 1 024 avec son PHP intégré. nginx reste devant Apache et Caddy à chaque niveau de charge, même quand sa courbe statique redescend après 64 connexions. Face à Apache, l'écart de nginx est de 1,5 fois en PHP à 16 connexions, et de 3,6 fois à 1 024.

Sources

Documentation consultée le 13 novembre 2026 :

• La faille : avis du projet Apache, suivi de sécurité Debian et avis Debian DSA-6620-1.
• La note et le contournement : fiche Red Hat et billet de Wiz.
• La directive de configuration : Protocols et MaxKeepAliveRequests.
• Le serveur testé en plus : site d'OpenLiteSpeed et son image Docker officielle.
• Les parts de marché : W3Techs, serveurs web.
• Les avis des autres serveurs : nginx et Caddy.
• La migration : blog nginx, guide .htaccess d'Apache, règles de réécriture d'OpenLiteSpeed et HTTPS automatique de Caddy.
• Le test de comparaison : Tideways, septembre 2025.
• L'outil de charge : wrk.