Self-hosting

Nginx : reverse proxy, HTTPS et configuration de A à Z

16 دقائق للقراءة

Une application qui tourne sur votre machine n’est encore visible que de vous. Entre ce serveur Node qui répond sur localhost:3000 et un visiteur à Cotonou qui tape votre adresse dans son navigateur, il manque une pièce : un serveur web public, capable d’écouter sur le port 443, de présenter un certificat HTTPS valide, de servir vos fichiers statiques, et de relayer le reste vers vos applications internes. Cette pièce, dans la grande majorité des déploiements aujourd’hui, c’est Nginx.

Ce guide est le point d’entrée d’un parcours complet sur Nginx : de la première installation jusqu’à un serveur durci qui répartit la charge entre plusieurs applications. Il explique le quoi et le pourquoi — l’architecture, les concepts, les choix — et renvoie vers des tutoriels pas-à-pas qui construisent, brique après brique, un déploiement réel. Le fil rouge de tout le parcours est une petite plateforme de livraison de quartier, « Colis Express » : une API Node.js, un front statique, et progressivement tout ce qu’il faut autour pour la mettre en ligne sérieusement.

Sommaire

À quoi sert vraiment Nginx

Nginx (prononcé « engine-x ») est à la fois un serveur web et un serveur mandataire. Ces deux casquettes recouvrent en réalité quatre métiers distincts qu’on lui confie, souvent en même temps, sur une seule et même machine.

D’abord, il sert des fichiers statiques : du HTML, du CSS, des images, le résultat d’un build React ou Vue. Pour ça, il est redoutablement efficace — il lit le fichier sur le disque et l’envoie, sans rien calculer. Ensuite, il fait office de reverse proxy : il reçoit une requête publique et la transmet à une application qui tourne en local (une API Node, un service Python, PHP-FPM), puis renvoie la réponse au client. Le visiteur ne voit jamais le port interne ni l’adresse réelle de l’application ; il ne parle qu’à Nginx. Troisièmement, il termine le TLS : c’est lui qui détient le certificat, déchiffre le HTTPS entrant et parle en clair à vos applications sur la boucle locale. Enfin, il répartit la charge (load balancing) lorsqu’une seule instance de l’application ne suffit plus : il distribue les requêtes entre plusieurs backends identiques.

La raison pour laquelle on place systématiquement Nginx devant ses applications tient en une phrase : une application métier (Node, Django, Laravel) est faite pour exécuter de la logique, pas pour affronter Internet. Elle gère mal les connexions lentes, ne sait pas servir efficacement un gros fichier, n’a pas de cache HTTP digne de ce nom, et l’exposer directement sur le port 443 multiplie sa surface d’attaque. Nginx s’interpose : il encaisse le trafic brut, filtre, met en cache, chiffre, et ne transmet à l’application que des requêtes propres. C’est le portier et le standard téléphonique du serveur.

Cette popularité n’est pas anecdotique. Nginx est, depuis des années, l’un des serveurs web les plus utilisés du Web et, selon les relevés récents de parts de marché, désormais en tête devant son aîné Apache. Pour un développeur ou un administrateur en Afrique de l’Ouest qui déploie sur un VPS, c’est un savoir-faire directement monnayable : il est partout.

🎯 Ce que ce parcours vous permettra de faire

  • Installer Nginx sur un serveur Ubuntu ou Debian et comprendre l’organisation de ses fichiers de configuration.
  • Servir un site statique et héberger plusieurs domaines sur une seule machine grâce aux blocs server (vhosts).
  • Placer une API applicative derrière un reverse proxy avec les bons en-têtes transmis.
  • Obtenir et renouveler automatiquement un certificat HTTPS gratuit avec Let’s Encrypt.
  • Accélérer un site avec la compression, les en-têtes de cache navigateur et un cache mandataire.
  • Répartir le trafic entre plusieurs instances d’une application et survivre à la panne de l’une d’elles.
  • Durcir la configuration TLS, poser les en-têtes de sécurité et limiter le débit pour absorber les abus.

🗺️ Le parcours d’apprentissage

Les six tutoriels ci-dessous se suivent dans un ordre qui construit le déploiement de « Colis Express » de façon cumulative. On peut piocher au besoin, mais l’ordre est pensé pour qu’aucune étape ne suppose une notion non encore vue.

  1. Installation et vhosts — on installe Nginx et on sert le front statique de Colis Express, puis on apprend à héberger plusieurs domaines côte à côte.
  2. Reverse proxy — on branche l’API Node.js derrière Nginx, sans jamais exposer le port 3000.
  3. HTTPS avec Let’s Encrypt — on passe tout le site en HTTPS avec un certificat gratuit qui se renouvelle seul.
  4. Cache et compression — on réduit le poids transféré et le temps de réponse, ce qui compte double sur une connexion mobile.
  5. Load balancing — on fait tourner deux instances de l’API et on répartit la charge entre elles.
  6. Durcissement — on verrouille la configuration : TLS moderne, en-têtes de sécurité, limitation de débit.

Les concepts fondamentaux

Le bloc server et le routage par nom d’hôte

Toute la configuration de Nginx s’articule autour de blocs imbriqués, écrits dans un langage déclaratif à base d’accolades. Le plus important est le bloc server : il décrit un site virtuel. Chaque bloc server écoute sur un ou plusieurs ports (listen 80;, listen 443 ssl;) et répond à un ou plusieurs noms de domaine (server_name colis-express.net;). Quand une requête arrive, Nginx lit l’en-tête Host envoyé par le navigateur et choisit le bloc server dont le server_name correspond. C’est ce mécanisme qui permet d’héberger des dizaines de domaines sur une seule adresse IP — le fameux virtual hosting.

Le bloc location

À l’intérieur d’un server, les blocs location décident quoi faire selon le chemin de l’URL. Un location / attrape la racine, un location /api/ attrape tout ce qui commence par /api/, un location ~ \.php$ attrape les fichiers PHP via une expression régulière. C’est dans un location qu’on dit « ce chemin-ci, sers-le depuis le disque » ou « celui-là, transmets-le à l’application ». Comprendre l’ordre de priorité des location est l’une des compétences qui sépare le débutant qui « tâtonne jusqu’à ce que ça marche » de celui qui sait pourquoi ça marche.

Reverse proxy et termination TLS

Un reverse proxy est un intermédiaire qui se présente au client comme s’il était le serveur final, tout en relayant en coulisse vers le vrai service. La directive clé est proxy_pass. Le point délicat n’est pas de relayer la requête, mais de transmettre à l’application les bonnes informations sur le client d’origine — son adresse IP réelle, le nom d’hôte demandé, le fait que la connexion d’origine était en HTTPS. Sans ces en-têtes (Host, X-Forwarded-For, X-Forwarded-Proto), l’application croit que toutes les requêtes viennent de 127.0.0.1 en HTTP, ce qui casse les redirections, les logs et la génération de liens absolus.

Le modèle de processus : pourquoi Nginx encaisse

Là où un serveur traditionnel crée un processus ou un fil d’exécution par connexion, Nginx repose sur un modèle événementiel et asynchrone : un petit nombre de processus de travail (worker_processes, idéalement un par cœur) gèrent chacun des milliers de connexions simultanées sans bloquer. C’est ce qui lui permet de tenir des charges élevées avec une empreinte mémoire modeste — un atout réel quand on tourne sur un VPS à 5 dollars par mois avec 1 Go de RAM.

Stable ou mainline ? Choisir sa version

Nginx publie deux branches en parallèle, et le choix déroute souvent au début. La branche stable (numéro mineur pair, par exemple la 1.30 au moment d’écrire, dont la dernière version est la 1.30.2) ne reçoit que des corrections de bugs et de sécurité : c’est le choix par défaut pour la production, car rien n’y bouge en dehors des correctifs. La branche mainline (numéro mineur impair, la 1.31 actuellement, dernière version 1.31.1) intègre les nouveautés et les correctifs en continu ; contrairement à ce que son nom « de développement » laisse croire, elle est réputée fiable et c’est même celle que le projet recommande pour la plupart des usages, HTTP/3 compris. En pratique : la version fournie par votre distribution (souvent une stable un peu plus ancienne) convient parfaitement pour apprendre et pour la majorité des sites ; on se tourne vers le dépôt officiel de nginx.org quand on veut une version précise ou une fonctionnalité récente.

L’anatomie d’une requête à travers Nginx

Pour vraiment comprendre Nginx, rien ne vaut de suivre une requête de bout en bout. Un visiteur tape https://colis-express.net/api/colis/12345. Sa requête arrive sur le port 443 du serveur. Nginx, qui écoute ce port, accepte la connexion TLS : c’est lui qui détient le certificat, déchiffre le trafic et lit la requête en clair.

Il regarde alors l’en-tête Host — colis-express.net — et sélectionne le bloc server correspondant. À l’intérieur, il compare le chemin /api/colis/12345 à ses blocs location et retient le plus spécifique : ici /api/. Ce bloc dit « relaie vers l’application interne » : Nginx ouvre (ou réutilise) une connexion vers 127.0.0.1:3000, transmet la requête en y ajoutant les en-têtes qui renseignent l’application sur le vrai client, et attend la réponse.

L’application Node calcule sa réponse JSON et la renvoie à Nginx, qui peut alors la compresser, éventuellement la mettre en cache pour les prochains visiteurs, la chiffrer à nouveau, et l’envoyer au navigateur. Du point de vue du visiteur, tout cela s’est passé en une fraction de seconde et il n’a jamais su qu’une application tournait sur un port interne. Chaque tutoriel du parcours approfondit une étape de ce trajet : la sélection du site et du chemin, le relais, le chiffrement, la compression et le cache, la répartition, la protection.

Vue d’ensemble pratique

Voici comment les briques s’assemblent dans la vraie vie, et où chaque tutoriel intervient.

L’installation et les vhosts posent les fondations. Sur Debian et Ubuntu, la configuration vit dans /etc/nginx/, avec une convention de répertoires sites-available/ (les configurations disponibles) et sites-enabled/ (celles activées, par lien symbolique). On y écrit un premier bloc server qui sert le front statique. C’est l’objet du tutoriel Installer Nginx et configurer ses premiers vhosts.

Le reverse proxy branche la logique applicative. L’API de Colis Express tourne sur 127.0.0.1:3000 ; un location /api/ avec proxy_pass la rend accessible publiquement sous /api/, sans jamais ouvrir le port 3000 au monde. Tout est détaillé dans Mettre une API Node.js derrière un reverse proxy Nginx.

Le HTTPS est non négociable aujourd’hui : un site en HTTP simple est marqué « non sécurisé » par les navigateurs et pénalisé en référencement. Avec Let’s Encrypt et l’outil Certbot, le certificat est gratuit, automatique et renouvelé sans intervention. Voir HTTPS avec Nginx et Let’s Encrypt grâce à Certbot.

Le cache et la compression font la différence sur l’expérience perçue. Compresser le texte avec gzip, dire au navigateur de garder les fichiers statiques en cache, et mémoriser les réponses de l’API quand c’est possible : autant de gains directs sur la bande passante et la latence. C’est le sujet de Cache et compression Nginx pour accélérer un site.

Le load balancing entre en jeu quand une instance ne suffit plus ou qu’on veut éviter le point unique de défaillance. Un bloc upstream regroupe plusieurs backends et Nginx répartit le trafic. Détaillé dans Load balancing avec Nginx : répartir la charge.

Le durcissement est ce qui sépare un déploiement de démo d’un déploiement de production : protocoles TLS modernes uniquement, en-têtes de sécurité, masquage de la version, limitation du débit pour décourager le forçage et les abus. À lire dans Durcir Nginx : sécurité TLS, en-têtes et rate limiting.

Les tutoriels du parcours

Chaque tutoriel ci-dessous construit une brique concrète du déploiement de « Colis Express ». Suivis dans l’ordre, ils mènent d’un serveur vierge à une mise en ligne complète et durcie.

🌍 Réalités du terrain en Afrique de l’Ouest

Déployer Nginx ici n’est pas tout à fait la même expérience que dans un data center européen, et quelques réflexes changent la donne. Le premier concerne la bande passante du visiteur. Une part importante du trafic arrive par la 3G ou la 4G, avec des forfaits data comptés au mégaoctet. Tout octet économisé est un octet payé en moins par votre utilisateur. C’est pourquoi la compression et le cache, traités dans ce parcours, ne sont pas des optimisations de luxe mais une question de respect du visiteur de Bamako ou de Niamey qui charge votre page sur un téléphone.

Le deuxième concerne le choix de l’hébergement. Un VPS d’entrée de gamme (1 vCPU, 1 à 2 Go de RAM) chez un hébergeur international suffit largement à faire tourner Nginx devant une petite API — et le modèle événementiel de Nginx est précisément ce qui rend cette frugalité possible. Le paiement par carte n’étant pas toujours simple, beaucoup passent par des revendeurs locaux ou des solutions acceptant le mobile money ; vérifiez surtout que vous avez un accès SSH root et la possibilité d’ouvrir les ports 80 et 443.

Le troisième est la latence vers les serveurs de validation. Lors de l’obtention d’un certificat Let’s Encrypt, les serveurs de l’autorité doivent joindre votre domaine : assurez-vous que votre enregistrement DNS pointe bien vers l’IP du VPS et que le port 80 est ouvert, sans quoi la validation échoue. Enfin, gardez en tête les coupures de courant côté serveur de développement local : privilégiez les tests sur le VPS distant, qui lui reste allumé, plutôt que sur une machine de bureau sujette aux délestages.

Erreurs fréquentes à éviter

Erreur Cause Solution
Recharger Nginx sans tester la configuration Une erreur de syntaxe coupe tout le serveur Toujours lancer nginx -t avant systemctl reload nginx
Oublier proxy_set_header Host $host; L’application reçoit un mauvais nom d’hôte Transmettre Host, X-Real-IP, X-Forwarded-For et X-Forwarded-Proto
Utiliser encore listen 443 ssl http2; Le paramètre http2 du listen est déprécié depuis Nginx 1.25.1 Mettre listen 443 ssl; puis la directive http2 on;
Activer ssl_stapling on; pour un certificat Let’s Encrypt Le service OCSP de Let’s Encrypt a fermé en août 2025 Retirer l’agrafage OCSP : il n’a plus d’effet sur ces certificats
Ouvrir le port de l’application (3000, 8000…) sur le pare-feu Le service devient joignable en clair, sans passer par Nginx N’ouvrir que 80 et 443 ; faire écouter l’application sur 127.0.0.1
Éditer /etc/nginx/nginx.conf pour chaque site Fichier principal surchargé et fragile Un fichier par site dans sites-available/, activé par lien symbolique

FAQ

Nginx ou Apache : lequel choisir en 2026 ?
Les deux sont matures et fiables. Nginx brille comme reverse proxy et pour servir du statique sous forte charge avec peu de mémoire ; sa configuration est plus déclarative. Apache reste apprécié pour son .htaccess par répertoire et son intégration historique avec PHP via mod_php. Pour un déploiement moderne d’API derrière un proxy, Nginx est le choix le plus courant. On voit aussi des alternatives comme Caddy (HTTPS automatique intégré) ou Traefik (orienté conteneurs).

Faut-il connaître Linux pour utiliser Nginx ?
Un minimum, oui : savoir se connecter en SSH, éditer un fichier avec nano ou vim, gérer un service avec systemctl et lire des logs. Le parcours suppose ce socle et l’explique au fil de l’eau, mais ne part pas totalement de zéro côté ligne de commande.

Nginx peut-il servir de serveur web et de reverse proxy en même temps ?
Oui, c’est même le cas le plus fréquent : un bloc location / sert le front statique depuis le disque, pendant qu’un location /api/ relaie vers l’application. Une seule installation, plusieurs rôles.

Le certificat Let’s Encrypt est-il vraiment gratuit et fiable ?
Oui. Let’s Encrypt est une autorité de certification à but non lucratif reconnue par tous les navigateurs. Les certificats sont valables 90 jours et se renouvellent automatiquement via Certbot. Le tutoriel dédié couvre l’obtention et le renouvellement.

Comment recharger la configuration sans couper le site ?
Avec systemctl reload nginx (ou nginx -s reload), Nginx recharge sa configuration sans interrompre les connexions en cours, contrairement à un restart. À condition d’avoir validé la syntaxe avec nginx -t au préalable.

Faut-il compiler Nginx soi-même pour avoir Brotli ou HTTP/3 ?
Pour des modules absents des paquets officiels comme la compression Brotli, oui, il faut un module additionnel (souvent compilé en module dynamique). HTTP/3 (QUIC) est pris en charge par Nginx depuis la version 1.25.0, mais nécessite une bibliothèque TLS compatible QUIC. Pour débuter, gzip et HTTP/2 couvrent l’essentiel des besoins.

Nginx peut-il aussi servir une application PHP comme WordPress ?
Oui, mais différemment d’une API Node : PHP ne tourne pas comme un serveur autonome qu’on relaie en HTTP. On passe par PHP-FPM, un gestionnaire de processus PHP, auquel Nginx parle via le protocole FastCGI (fastcgi_pass) plutôt que proxy_pass. Le principe reste le même — Nginx en façade, l’exécution déléguée — mais la directive et le protocole changent. Le déploiement de WordPress sur Nginx, lié en ressources, illustre ce cas.

Combien de sites puis-je héberger sur un seul Nginx ?
Techniquement, des centaines : chaque site est un bloc server de quelques lignes, et Nginx consomme très peu par site inactif. La vraie limite est celle des ressources de votre serveur face au trafic cumulé, pas le nombre de blocs server. C’est tout l’intérêt du virtual hosting, détaillé dans le premier tutoriel du parcours.

Ressources et références

مشاركة
#cluster-nginx #cluster-pillar #https #Nginx #Serveur web