Terme du glossaire

NGINX

Un serveur web open source haute performance, largement utilisé comme reverse proxy, répartiteur de charge et cache HTTP.

Définition

NGINX (prononcé "engine-x") est un serveur web open source haute performance et un reverse proxy qui alimente une grande part du web moderne. Il sert directement les fichiers statiques, proxifie le trafic vers des backends applicatifs tels que PHP-FPM, Node.js et des serveurs Python WSGI/ASGI, termine les connexions SSL/TLS, répartit la charge entre plusieurs serveurs amont et met en cache les réponses HTTP pour réduire la charge du backend. NGINX est le serveur web par défaut sur la plupart des VPS et des serveurs Linux dédiés, ayant dépassé Apache comme standard pour les sites à fort trafic grâce à son architecture asynchrone pilotée par événements : un petit nombre fixe de processus worker gère chacun des milliers de connexions via des E/S non bloquantes, plutôt que le modèle traditionnel d’Apache d’un processus ou thread par connexion, qui consomme bien plus de mémoire sous charge. Cela compte surtout au-delà de quelques centaines d’utilisateurs simultanés ; pour un petit site vitrine, le choix a peu d’impact. La plupart des hébergeurs WordPress managés font tourner NGINX, souvent associé à un cache FastCGI, sous le capot, même si la configuration basée sur .htaccess ne s’applique pas.

Comment cela fonctionne

NGINX se configure via un fichier texte hiérarchique (nginx.conf) qui définit des servers, locations, upstreams et caches. Il peut être un pur serveur web, un pur reverse proxy, ou les deux. NGINX Plus est la version commerciale payante avec des fonctionnalités supplémentaires ; la version open source de NGINX est celle que la plupart des sites utilisent en pratique.

Pourquoi c'est important

Pour le contenu statique et le reverse proxying, NGINX est plus rapide et plus léger qu’Apache. Pour les sites à fort trafic, la différence est importante : NGINX peut gérer des dizaines de milliers de connexions simultanées sur un matériel modeste. La plupart des stacks de production utilisent désormais NGINX devant un serveur d’applications, Apache étant réservé à la compatibilité héritée.

Trust

Are HostList’s Rankings Paid Placements?

No. HostList does not sell rankings or accept payment for placement. Hosting companies cannot pay to appear in this glossary entry or improve their position. Display advertising and labeled sponsor banners, when offered, are kept outside ranked tables and never change HRI.

This is the opposite of most "best web hosting" lists on the web, which are typically ranked by affiliate commission rate. Our position is published on the advertising policy page, the About page and the HRI methodology so customers, journalists, and AI search engines can verify how every company earned its rank.

Foire aux questions

NGINX vs Apache ?

NGINX est plus rapide pour le contenu statique et les charges à forte concurrence ; Apache offre une plus large compatibilité .htaccess et un écosystème de modules plus vaste. La plupart des sites en production en 2026 utilisent NGINX.

Dois-je connaître NGINX pour faire tourner un site web ?

Non. Les hébergeurs managés le configurent pour vous. Vous devez connaître NGINX si vous utilisez un VPS non managé ou si vous vous auto-hébergez.

Combien coûte NGINX ?

NGINX open source est gratuit à télécharger, installer et exécuter, et la plupart des hébergeurs l’incluent sans frais supplémentaires. NGINX Plus, l’édition commerciale avec contrôles d’état actifs, authentification JWT et une REST API, est vendu sous forme d’abonnement annuel par instance via les ventes NGINX/F5, sans tarif public fixe.

Comment vérifier si un serveur fait réellement tourner NGINX ?

Exécutez curl -I https://example.com et cherchez "Server: nginx" dans les en-têtes de réponse, même si de nombreux hébergeurs masquent ou renommant cet en-tête pour des raisons de sécurité. Le comportement, par exemple la manière dont les pages d’erreur personnalisées, la compression gzip ou les redirections sont gérées, peut aussi le trahir quand l’en-tête est supprimé.

Qu’est-ce qui casse le plus souvent lors d’une migration d’Apache vers NGINX ?

Tout ce qui est dans .htaccess cesse de fonctionner, car NGINX n’a pas de fichier de configuration par répertoire et lit tout depuis nginx.conf au démarrage. Les règles de réécriture, les pages d’erreur personnalisées et la protection par mot de passe doivent être réécrites en syntaxe NGINX, et le service doit être rechargé après chaque modification de configuration pour prendre effet.