Chapitre 7.1 — Pourquoi un reverse proxy
⏱️ TL;DR — Un reverse proxy est une façade qui reçoit tout le trafic web public et le relaie vers une ou plusieurs apps qui tournent en local sur des ports privés. On met Nginx devant Node/Next au lieu de les exposer directement pour cinq raisons majeures : centraliser le TLS/HTTPS, servir le statique bien plus efficacement que Node, faire cohabiter plusieurs apps sur une seule IP, appliquer limites, timeouts et buffering au bord, et ne jamais lancer l’app en root pour écouter sous le port 1024. Ce chapitre installe cette idée dans ta tête ; le reste de la partie la met en œuvre.
🎯 Objectifs
- Définir ce qu’est un reverse proxy (et en quoi il diffère d’un proxy « classique »).
- Lister les raisons concrètes de ne pas exposer Node/Next directement sur 80/443.
- Situer Nginx face à Apache et Caddy, et comprendre pourquoi ce cours choisit Nginx.
- Visualiser le trajet navigateur → Nginx → apps locales.
Un reverse proxy, c’est quoi
Un proxy classique (dit forward proxy) se place devant des clients : il sort sur Internet à leur place (filtrage d’entreprise, cache de sortie). Un reverse proxy, lui, se place devant des serveurs : il reçoit les requêtes des clients à la place de tes apps et décide quoi en faire. Vu de l’extérieur, il n’y a qu’une seule machine qui répond — le reverse proxy — et les apps derrière restent invisibles.
Concrètement : le navigateur ouvre une connexion vers le port 443 de ton VPS. C’est Nginx qui répond, pas ton app. Selon le domaine et le chemin demandés, Nginx sert un fichier lui-même ou transmet la requête à l’app locale (par exemple 127.0.0.1:3000), récupère la réponse, et la renvoie au navigateur. L’app ne parle jamais directement à Internet : elle parle à Nginx, qui parle au monde.
Pourquoi ne pas exposer Node/Next directement
La tentation du débutant : next start écoute sur un port, j’ouvre ce port dans le pare-feu, terminé. Ça « marche » en démo, mais c’est une impasse en production. Voici les cinq raisons de mettre une façade.
1. Centraliser le TLS/HTTPS
Le HTTPS demande de gérer des certificats (obtention, renouvellement, redirection HTTP→HTTPS, protocoles TLS, en-têtes de sécurité). Faire ça dans chaque app est fastidieux et fragile. Avec un reverse proxy, le TLS vit à un seul endroit : Nginx déchiffre en entrée, tes apps ne parlent qu’en HTTP clair en local (127.0.0.1), et tu poses un seul certificat par domaine (voir Partie 8). Un point unique à sécuriser et à renouveler, au lieu d’un par app.
2. Servir le statique efficacement
Node est excellent pour la logique applicative, médiocre pour cracher des milliers d’images, CSS et JS : chaque fichier statique servi par Node occupe l’event loop qui devrait traiter tes requêtes dynamiques. Nginx, lui, est écrit pour ça : il lit un fichier sur le disque et l’envoie au réseau avec un coût quasi nul, gère le cache navigateur et la compression. Résultat : tu déchargues ton app de tout le statique et elle ne s’occupe que du dynamique.
3. Plusieurs apps sur une seule IP
Un VPS a une IP publique et un port 443. Or tu veux souvent y faire tourner plusieurs choses : un front Next, une API Symfony, un sous-domaine d’admin, un autre projet. Un seul processus peut écouter sur le port 443 — impossible de les y mettre tous. Le reverse proxy résout ça : Nginx est le seul à écouter sur 443, et il aiguille selon le server_name et le chemin vers la bonne app locale (chapitre 7.5).
4. Limites, timeouts et buffering au bord
Une app exposée nue est vulnérable : un client lent qui envoie sa requête octet par octet peut bloquer un worker Node pendant des secondes. Nginx absorbe ça : il bufferise les requêtes et réponses lentes, applique des timeouts, plafonne la taille des corps (client_max_body_size), et peut limiter le débit (limit_req). Ton app ne voit que des requêtes propres et complètes, servies à sa vitesse. C’est une couche de robustesse gratuite.
5. Ne pas lancer l’app en root
Sur Linux, seuls les processus root peuvent écouter sur un port inférieur à 1024 (donc 80 et 443). Faire écouter Node directement sur 443 t’obligerait à le lancer en root — exactement ce qu’on s’interdit (Partie 3) : un bug dans ton code deviendrait un bug avec les pleins pouvoirs sur la machine. Avec un reverse proxy, Nginx (dont c’est le métier, et qui laisse tomber ses privilèges après le démarrage) écoute sur 443, et ton app tourne tranquillement en utilisateur non privilégié sur un port >1024 comme 3000.
🔒 Sécurité — Le reverse proxy est aussi une couche de défense. Il cache ton app (sa version, son moteur, ses ports ne fuitent pas), il filtre ce qui remonte, il applique des limites, et il te donne un seul point où poser TLS, en-têtes de sécurité et journalisation. Exposer Node en direct, c’est offrir ta surface d’attaque applicative sans filet au premier scanner venu.
⚠️ Piège — « Mon app Next tourne, j’ai juste à ouvrir le port 3000 dans UFW. » Non. Tu te retrouves avec une URL en
http://IP:3000(pas de HTTPS, pas de nom de domaine propre), une app qui encaisse tout le statique et toutes les requêtes lentes, et aucune possibilité d’ajouter un second service. Le port 3000 doit rester fermé au monde ; seul Nginx (80/443) est ouvert.
Nginx vs Apache vs Caddy
Trois serveurs web reviennent sans cesse. Situons-les.
| Serveur | Forces | Pour qui |
|---|---|---|
| Nginx | Léger, très rapide en reverse proxy et statique, config déclarative, omniprésent en prod | Le défaut de ce cours |
| Apache | Historique, .htaccess par dossier, riche en modules, roi du monde PHP mutualisé | Legacy PHP, hébergements mutualisés |
| Caddy | HTTPS automatique (certificats gérés tout seul), config très simple | Petits projets, config minimale |
Apache (httpd) a longtemps été le standard, surtout pour PHP en mutualisé, avec ses fichiers .htaccess par répertoire. Il fait très bien reverse proxy aussi, mais son modèle est plus lourd. Caddy est le petit nouveau élégant : il obtient et renouvelle les certificats TLS tout seul, avec une config minuscule — séduisant pour un petit projet. Mais Nginx reste le choix par défaut de l’écosystème : c’est celui que tu croiseras partout (tutoriels, entreprises, Docker, Kubernetes ingress), sa config est explicite et bien documentée, et il excelle exactement à ce qu’on lui demande ici. On apprend Nginx : ce que tu comprends de lui se transpose facilement aux autres.
💡 Réflexe — Le choix du serveur web n’est pas une religion. Nginx est un excellent défaut ; Caddy est un choix légitime si tu veux du HTTPS zéro-config sur un petit projet. Ce qui compte, c’est de comprendre le rôle de la façade — il est identique quel que soit l’outil. Une fois le concept acquis, changer d’implémentation est un détail.
🧭 Sur FormaCampus — En rapatriant sa prod sur un VPS Ubuntu LTS, FormaCampus met Nginx en façade unique. Objectif de la partie : Nginx écoute sur 80/443, sert le front Next.js sur l’apex
formacampus.fr, proxifie/api/*vers l’API Symfony locale, et sert les images de cours directement depuis le disque. Le front (port 3000) et l’API (port 8000) restent fermés au monde : seul Nginx est exposé. Une IP, un point d’entrée, plusieurs services derrière — c’est précisément le travail du reverse proxy.
📚 La doc — Le site officiel
nginx.orget son Beginner’s Guide font autorité ; sur Ubuntu/Debian, le paquet installe aussi des pagesman nginx. Méfie-toi des vieux tutoriels de blog qui traînent des directives obsolètes : en cas de doute, la doc officielle tranche.
✏️ Exercices
Exercice 1 — Convaincs le sceptique. Un collègue dit : « Pourquoi s’embêter avec Nginx ? Mon next start écoute déjà sur un port, j’ouvre le port et c’est réglé. » Donne-lui trois raisons concrètes de mettre quand même un reverse proxy.
✅ Solution
Au choix parmi : (1) TLS centralisé — gérer HTTPS et le renouvellement des certificats à un seul endroit au lieu de dans l’app ; (2) le statique — Nginx sert images/CSS/JS bien plus efficacement, sans occuper l’event loop de Node ; (3) plusieurs services sur une IP — un seul processus peut écouter sur 443, donc impossible d’y mettre front + API sans un proxy qui aiguille ; (4) ne pas lancer Node en root pour écouter sous 1024 ; (5) robustesse au bord — timeouts, buffering des clients lents, limites de taille et de débit. Trois de ces cinq suffisent.
Exercice 2 — Forward ou reverse ? Deux situations : (a) une entreprise fait passer tout le trafic sortant de ses employés par un serveur qui filtre les sites interdits ; (b) un VPS reçoit les requêtes du public et les distribue entre un front et une API locale. Lequel est un forward proxy, lequel est un reverse proxy ?
✅ Solution
(a) est un forward proxy : il se place devant les clients (les employés) et sort sur Internet à leur place. (b) est un reverse proxy : il se place devant les serveurs (front + API) et reçoit les requêtes du public à leur place. Moyen mnémotechnique : forward = devant les clients, reverse = devant les serveurs.
🧠 Quiz de révision
1. En une phrase, qu’est-ce qu’un reverse proxy ?
Une façade placée devant une ou plusieurs applications, qui reçoit tout le trafic public à leur place et le relaie vers les apps locales, en restant le seul point exposé à Internet.
2. Pourquoi ne pas faire écouter Node directement sur le port 443 ?
Parce qu’écouter sous le port 1024 exige les privilèges root — on refuse de lancer son app en root. Et parce qu’on veut centraliser le TLS, servir le statique efficacement, faire cohabiter plusieurs apps sur une IP, et appliquer timeouts/limites au bord. Nginx fait tout ça ; l’app reste en utilisateur non privilégié sur un port >1024.
3. Comment Nginx permet-il plusieurs apps sur une seule IP et un seul port 443 ?
Un seul processus peut écouter sur 443 : c’est Nginx. Il aiguille ensuite chaque requête selon le server_name (le domaine demandé) et le chemin vers la bonne app locale sur son port privé. Les apps ne touchent jamais le 443 elles-mêmes.
4. Pourquoi laisser Nginx servir les fichiers statiques plutôt que l’app ?
Parce que Nginx est conçu pour lire un fichier sur disque et l’envoyer au réseau à coût quasi nul, avec cache et compression. Servir le statique depuis Node occupe l’event loop qui devrait traiter le dynamique. On décharge donc l’app de tout le statique.
5. Nginx, Apache, Caddy : lequel ce cours choisit-il et pourquoi ?
Nginx : c’est le défaut de l’écosystème (omniprésent en prod, Docker, tutoriels), léger, très rapide en reverse proxy et statique, à la config explicite et bien documentée. Apache est plutôt legacy/PHP mutualisé ; Caddy séduit par son HTTPS automatique sur les petits projets. Le rôle de la façade, lui, est identique partout.
Chapitre suivant : Installer & structurer Nginx — le service, l’arborescence Debian/Ubuntu, et le réflexe nginx -t.