NGINX vs Apache : quel serveur web gagne pour votre site

NGINX et Apache répondent tous deux aux requêtes HTTP, mais ils gèrent la concurrence de manière opposée. Ce comparatif couvre les performances, la sécurité, la configuration et le coût, pour que vous puissiez choisir un serveur web selon votre charge de travail plutôt que selon un concours de popularité.

Performances : vitesse et utilisation des ressources

L'architecture décide de cette section, et la différence de traitement des requêtes est toute l'histoire. Le MPM prefork d'Apache donne à chaque requête son propre processus ; les MPM worker et event utilisent plutôt des threads. Le modèle prefork est le plus ancien des trois. Chacune de ces approches fait payer la concurrence en mémoire.

NGINX exécute un petit nombre fixe de processus worker et gère des milliers de connexions actives dans chacun d'eux. Rien ne bloque, si bien que la consommation mémoire suit le nombre de workers plutôt que le nombre de clients.

Chaque worker utilise ses cœurs efficacement et les recycle efficacement quand les clients se déconnectent. NGINX traite chaque socket dans son event loop au lieu d'y parquer un thread, si bien que les clients inactifs ne coûtent presque rien à NGINX.

Consommation mémoire sous concurrence

Le contenu statique est là où l'écart est le plus large. NGINX sert les fichiers avec moins d'appels système par requête, sa configuration par défaut sert déjà les fichiers statiques efficacement, et il réutilise efficacement les buffers de pages du noyau. NGINX traite le même nombre de fichiers avec une fraction de la mémoire.

Le contenu dynamique ramène l'écart à presque rien. Pour les pages dynamiques, quand les deux serveurs confient PHP à PHP-FPM via un socket, c'est l'interpréteur qui devient la limite. Les benchmarks montrant un grand écart sur les pages dynamiques opposent typiquement mod_php à PHP-FPM, et non Apache à NGINX.

Méfiez-vous des chiffres de requêtes par seconde qui circulent en ligne. La plupart sont irrépétables : pas de version du noyau, pas de MPM nommé, pas de réglage divulgué. Les chiffres de comparaison publiés en ligne sont en général irrépétables : testez donc sur votre propre matériel, avec votre propre contenu.

💡 La consommation mémoire compte plus que le débit de pointe sur une petite machine. Si vous avez 8 Go de RAM, notre guide sur la RAM serveur explique pourquoi c'est le nombre de processus qui la remplit.

Verdict : NGINX. NGINX gagne sur les fichiers statiques et la forte concurrence ; match nul sur le contenu dynamique.

Fonctions de sécurité et support TLS

Les deux sont matures, les deux corrigent vite, et aucun des deux ne détient un avantage de sécurité structurel. Les différences portent sur la surface d'exposition et les défauts.

Surface de modules. Une installation Apache d'origine active plus de modules que ce que la plupart des sites utilisent, et chacun ajoute du code dans le chemin de la requête. NGINX livre un jeu par défaut plus réduit, donc ajouter un module signifie en général recompiler.

Certificats. Les deux gèrent TLS 1.3, l'OCSP stapling et l'émission automatique via Certbot. La syntaxe diffère ; la capacité, non.

sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d example.com

HTTP/3 et QUIC. NGINX prend en charge QUIC depuis la version 1.25.0, et il est livré dans les paquets binaires Linux standard. Apache 2.4.x n'a pas de HTTP/3 natif : l'approche courante consiste donc à le placer derrière un frontal qui parle QUIC.

Filtrage des requêtes. ModSecurity fonctionne sur les deux. Les règles par répertoire d'Apache facilitent les politiques ciblées ; NGINX centralise tout, ce qui est plus difficile à rater. Les deux approches sont en développement actif.

Retirez ce que vous n'utilisez pas, sur les deux plateformes :

sudo a2dismod status autoindex
sudo apachectl -M

Quel que soit votre choix, le serveur web n'est pas votre seule protection. Notre guide de configuration du pare-feu couvre la couche en dessous.

Verdict : match nul. Apache égale NGINX sur les certificats. Apache porte aussi l'écosystème de modules le plus large, et NGINX ne prend l'avantage que lorsque HTTP/3 est requis.

Complexité de configuration : .htaccess vs directives NGINX

C'est la principale ligne de partage, et elle décide de plus de migrations que les performances. Le style de configuration, et non la vitesse brute, est ce dont les équipes débattent généralement.

Apache lit un fichier .htaccess à la racine du document et dans chaque répertoire au-dessus du chemin demandé, à chaque requête.

Cela permet des surcharges par répertoire sans rechargement, c'est pourquoi les offres multi-locataires tournent sur Apache.

Le coût, ce sont plusieurs consultations du système de fichiers par requête. Positionner AllowOverride None supprime le coût et la fonctionnalité ensemble.

NGINX n'a par conception aucun fichier de surcharge par répertoire. Les règles de réécriture, d'accès et d'en-têtes vivent dans la configuration centrale et prennent effet au rechargement.

Server block et virtual host, côte à côte

Un server block NGINX, son équivalent du virtual host :

server {
    listen 443 ssl;
    server_name example.com;
    root /var/www/example;
    location / {
        try_files $uri $uri/ =404;
    }
    location ~ \.php$ {
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
        include fastcgi_params;
    }
}

En comparaison, Apache qui imbrique le même virtual host dans des balises conteneur :

<VirtualHost *:443>
    ServerName example.com
    DocumentRoot /var/www/example
    <Directory /var/www/example>
        AllowOverride All
        Require all granted
    </Directory>
</VirtualHost>

Les deux déclarent une racine de documents, un nom et des règles d'accès. Apache imbrique les directives dans des balises conteneur ; NGINX utilise un bloc plat avec héritage du contexte parent.

Aucune des deux approches n'est objectivement meilleure, et les deux sont assez souples pour plusieurs sites sur un même hôte.

L'activation d'un nouveau virtual host diffère elle aussi :

sudo a2enmod rewrite
sudo a2ensite example.conf
sudo systemctl reload apache2
sudo ln -s /etc/nginx/sites-available/example /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

Le test pratique. Si une application, un panneau de contrôle ou un client écrit des règles dans un fichier .htaccess, Apache est le choix le moins risqué. Si vous contrôlez toute la configuration, NGINX demande moins de raisonnement.

Verdict : Apache gagne ici en flexibilité, NGINX en prévisibilité.

Montée en charge et répartition de charge

NGINX a été écrit pour résoudre le problème C10k : dix mille connexions simultanées sur une seule machine. Son architecture est organisée autour de cette contrainte unique.

Igor Sysoev l'a rendu public en 2004 exactement pour cela, et le design le montre encore. L'objectif de Sysoev n'a jamais été de remplacer Apache, seulement de se placer devant lui.

Comme répartiteur de charge. NGINX propose les options round-robin, least-connections et IP-hash avec health checks gratuitement : c'est un reverse proxy compétent devant plusieurs nœuds upstream.

upstream app {
    least_conn;
    server 10.0.0.11:8080;
    server 10.0.0.12:8080;
}

Apache sait aussi le faire. modproxybalancer fonctionne depuis des années, mais il hérite du modèle à processus, si bien que chaque connexion proxifiée occupe toujours un worker. Répartir des requêtes entre des nœuds est possible sur les deux, avec un surcoût différent.

Monter en puissance. Les deux montent à l'échelle verticalement avec les cœurs et la RAM. NGINX tire plus du même matériel parce que les sockets inactifs sont presque gratuits, ce qui compte pour les connexions longues comme WebSockets.

Quand la concurrence augmente, c'est la courbe mémoire qui les sépare, et elle progresse bien plus lentement sur NGINX.

Là où les connexions simultanées constituent la charge entière, comme un serveur de jeu, cette différence décide de tout.

Verdict : NGINX, clairement, même si Apache sait aussi répartir des requêtes.

Compatibilité avec PHP et le contenu dynamique

L'avantage historique d'Apache, c'était mod_php : l'interpréteur embarqué dans le processus du serveur web. C'était simple, et cela faisait porter un interpréteur PHP à chaque processus Apache, qu'il serve un script ou une image.

La pratique moderne, c'est PHP-FPM sur les deux serveurs, via un socket Unix. Le contenu généré dynamiquement est pris en charge par un pool séparé, que vous pouvez redémarrer de manière indépendante :

sudo apt install php8.3-fpm
sudo systemctl start php8.3-fpm

Les sites qui tournent encore en php7.4 devraient traiter la mise à niveau comme la priorité principale, puisque php7 a cessé de recevoir des correctifs de sécurité en 2022, qu'aucune branche php7 n'est supportée aujourd'hui et que les modules php7 ne se chargeront pas sur une version actuelle.

Ce qu'Apache fait encore nativement. Il exécute Perl, Python et le CGI historique via des modules, dans le processus. NGINX relaie tout ce qui est généré dynamiquement vers un service externe, si bien que tout ce qui est construit dynamiquement sort complètement du serveur web.

Ce que cela coûte à NGINX. Une pièce mobile de plus, et un socket à surveiller.

Ce que cela lui achète. Le serveur web reste léger quel que soit le comportement de l'application, et un crash de PHP n'entraîne plus un worker avec lui. Le traitement dynamique se situe en dehors du chemin des requêtes.

Une pile LAMP avec MySQL derrière Apache reste une architecture parfaitement bonne. Quand c'est la base de données qui constitue la contrainte plutôt que le serveur web, la solution est un serveur de base de données dédié, et non un autre serveur web.

Verdict : match nul sur les capacités, NGINX sur l'isolation.

Service de contenu statique et cache

Les fichiers statiques sont le terrain naturel de NGINX. sendfile et tcp_nopush déplacent les octets du disque vers le socket avec un minimum de copie, et les directives de cache sont courtes :

location ~* \.(jpg|css|js|woff2)$ {
    expires 30d;
    add_header Cache-Control "public, immutable";
}

NGINX fonctionne aussi comme proxy de cache devant une origine plus lente, avec proxycache qui stocke les réponses sur disque. Ce cache se configure centralement, pas par répertoire. Apache propose modcache et mod_expires pour les mêmes travaux, configurés par répertoire ou par virtual host.

La différence n'est pas ce que chacun peut faire mais la configuration qu'il exige, et le comportement du serveur quand le cache est froid et que mille clients arrivent d'un coup.

NGINX survit à cette ruée avec un verrou sur la récupération amont. Apache demande plus de réglages, et sa gestion d'un démarrage à froid pardonne moins.

Verdict : NGINX.

Support des systèmes d'exploitation et installation

Les deux tournent sur toutes les distributions Linux grand public, sur les BSD et sur macOS, et Linux est là où se trouve la grande majorité des installations.

Apache a la portée plateforme la plus large : il livre un build Windows supporté, alors que NGINX sous Windows n'est explicitement pas de qualité production. Sur Windows, IIS est de toute façon le choix le plus courant, et IIS reste le choix par défaut sur cette plateforme pour les applications internes.

Sur Debian et Ubuntu, l'installation de NGINX tient en quatre commandes. Le paquet apt installe un site par défaut fonctionnel, si bien qu'il construit une installation de base en quelques secondes :

sudo apt update
sudo apt install nginx
sudo systemctl enable --now nginx
sudo nginx -t

Le paquet Apache suit la même forme :

sudo apt update
sudo apt install apache2
sudo systemctl enable --now apache2
sudo apachectl configtest

Sur RHEL, Rocky et AlmaLinux, les noms de paquets diffèrent, et chaque éditeur compile le sien. Apache s'y appelle httpd, et non apache2 :

sudo dnf install nginx
sudo dnf install httpd
sudo systemctl enable --now nginx
sudo systemctl enable --now httpd

Ouvrez les ports, UDP compris, pour pouvoir activer QUIC plus tard :

sudo ufw allow 'Nginx Full'
sudo ufw allow 443/udp
sudo ufw status

Lisez la sortie d'erreur et gardez les paquets à jour :

sudo tail -f /var/log/nginx/error.log
sudo tail -f /var/log/apache2/error_log
sudo apt list --upgradable
sudo apt upgrade nginx
sudo apt install nginx-extras

Redémarrez proprement après un changement de configuration, et confirmez que le service est revenu. Ne lancez pas un reload avant que le test de configuration ne passe :

sudo systemctl restart nginx
sudo systemctl status nginx

La configuration vit dans /etc/nginx/ et /etc/apache2/ sur Debian, /etc/httpd/ sur RHEL, et chaque éditeur bâtit sa structure sur ces chemins. La racine des documents est par défaut /var/www/html sur les deux, et chacun écrit ses journaux sous /var/log/. Les deux ont besoin d'un accès en lecture à cette racine et d'un accès en écriture à leur propre répertoire.

Si vous choisissez une plateforme sur laquelle faire tourner l'un des deux, nos serveurs dédiés à petit budget montrent ce que coûte le matériel.

Verdict : Apache, sur l'étendue du support des plateformes.

Cas d'usage : quand choisir NGINX ou Apache

Choisissez NGINX pour un reverse proxy ou une passerelle API, des sites statiques et des applications single-page, des applications dynamiques derrière un socket, une forte concurrence sur du matériel modeste, l'ingress de conteneurs, et tout ce qui exige HTTP/3.

Choisissez Apache pour les offres multi-locataires, les applications qui livrent leurs propres règles de surcharge, les installations WordPress dont les plugins écrivent des règles de réécriture, le CGI historique ou le Perl in-process, et le déploiement Windows.

Faites tourner les deux quand vous voulez QUIC et la terminaison TLS en bordure mais que plusieurs applications s'attendent à trouver Apache derrière. NGINX prend la connexion, Apache sert la requête.

Pour une plateforme revendeur hébergeant les sites d'autrui, les surcharges par répertoire ne sont généralement pas optionnelles. Notre guide sur l'hébergement revendeur couvre l'installation plus en détail.

Verdict : la charge de travail décide, pas le benchmark. Apache se retrouve dans bien des mêmes baies.

Vue d'ensemble des coûts et des licences

Les deux sont libres et open source. Apache utilise la licence Apache 2.0, NGINX la licence BSD en deux clauses. Aucun ne facture par site, par cœur ou par connexion.

Des offres payantes existent au-dessus des deux. F5 vend NGINX Plus avec du clustering, une API de reconfiguration dynamique et le support éditeur, que des développeurs sous contrat de support peuvent apprécier.

Le support commercial d'Apache vient des distributions et de tiers plutôt que d'une seule société : un modèle de développement différent, et non inférieur. Le développement des deux projets reste actif.

Le vrai coût se situe ailleurs. Un serveur qui traite le même trafic avec moins de mémoire fait une facture mensuelle plus petite, et chaque heure passée à traduire des règles par répertoire est une heure facturée.

L'accès à l'ensemble de la configuration vaut quelque chose aussi. Pesez les deux face à un coût matériel fixe.

Verdict : match nul sur la licence, NGINX sur l'efficacité matérielle.

Verdict : quel serveur correspond à vos besoins

Parcourez la liste et arrêtez-vous à la première rangée qui constitue une contrainte non négociable. Il n'existe pas d'option universellement correcte.

Si aucune ne s'applique, NGINX est le meilleur choix par défaut en 2026, et la répartition des parts de marché dit la même chose : Apache détient 22,4 % des sites au global mais 9,9 % des 1 000 premiers, tandis que NGINX reste proche de la stabilité à chaque niveau de trafic.

Ce n'est pas un verdict contre Apache. Apache n'est pas en déclin là où il convient.

Sa base installée est concentrée dans les offres multi-locataires et les déploiements de longue durée, exactement là où sa configuration par répertoire mérite sa place. Le comparatif flatte le serveur qui correspond à la forme de votre trafic.

Conclusion

Choisissez selon la forme de votre charge. NGINX si vous servez des fichiers statiques, faites du proxy ou devez faire tenir une forte concurrence sur du matériel modeste. Apache si la configuration par répertoire, un module livré ou le support Windows est une exigence que vous ne pouvez pas écarter.

Les deux tournent bien sur une machine que vous contrôlez. La gamme Kimsufi démarre à 9,99 €/mois, SYS à 29,99 €/mois et Rise à 64,99 €/mois, avec accès root complet et trafic non facturé à l'octet.

FAQ