Reverse proxy : définition, fonctionnement et exemples
Reverse proxy : la définition simple, à quoi il sert, comment il fonctionne, ce qui le distingue d'un proxy ou d'un load balancer, et les erreurs à éviter.
Reverse proxy : la définition simple
Reverse proxy, ou proxy inverse : ce nom désigne un serveur installé devant un ou plusieurs serveurs web, qui reçoit les visites à leur place. Tapez l'adresse de votre site. Ce n'est pas votre serveur d'application qui vous répond, c'est le reverse proxy. Il lit la demande, la transmet à la bonne machine, récupère la réponse et la renvoie au visiteur.
L'internaute ne voit rien de ce relais. Il pense dialoguer avec votre site alors qu'il parle à un intermédiaire. Tout l'intérêt est là : l'architecture réelle (un seul serveur ou une dizaine, peu importe) disparaît derrière une adresse unique.
Comme la documentation technique est surtout rédigée en anglais, vous croiserez souvent cette définition : « a reverse proxy is a server that sits in front of the web server and forwards each request from the user to the server and the response back ». En clair, the proxy is not the website itself : it is the door that every visitor uses to reach it.
À quoi sert un reverse proxy sur un site professionnel ?
N'y voyez pas un gadget réservé aux grandes plateformes. Dès qu'un site doit rester rapide, sûr et disponible, cet intermédiaire rend plusieurs services d'un coup. En voici les quatre principaux.
Protéger le serveur qui héberge votre site
Puisque tout le trafic passe d'abord par lui, l'adresse IP de votre serveur d'application n'est pas exposée sur internet. Un attaquant se heurte d'abord à l'intermédiaire, qui peut filtrer les requêtes suspectes, limiter le nombre de demandes par visiteur ou bloquer certaines adresses. Associez-le à un pare-feu applicatif et vous obtenez une vraie ligne de défense.
Accélérer l'affichage des pages
Images, feuilles de style, pages statiques : tout ce qui change peu peut rester en cache. Dix visiteurs réclament la même page ? Il la sert depuis sa mémoire, sans solliciter le serveur à chaque fois. Il peut aussi compresser les fichiers avant de les envoyer, ce qui allège chaque réponse.
Répartir la charge entre plusieurs serveurs
Avec beaucoup de visites, un serveur seul finit par saturer. Le reverse proxy distribue alors les requêtes entre plusieurs machines : c'est le load balancing, ou équilibrage de charge. Si l'une d'elles tombe en panne, il cesse de lui envoyer du monde, et vos clients ne remarquent rien.
Centraliser le HTTPS
Chiffrer les échanges suppose un certificat SSL. Inutile de l'installer sur chaque serveur : confiez-le au reverse proxy, qui gère seul la connexion sécurisée avec le navigateur. Le renouvellement devient plus simple, et le risque d'oubli recule.
Comment fonctionne un reverse proxy, étape par étape
Quelques étapes suffisent à décrire le principe. Elles se répètent à l'identique, en une fraction de seconde.
- Le visiteur saisit l'adresse du site ; le DNS l'oriente vers le reverse proxy, et non vers le serveur final.
- À la réception de la requête HTTP, le proxy regarde ce qui est demandé : nom de domaine, chemin de la page, type de contenu.
- Selon ses règles, il répond depuis son cache ou passe la requête au serveur concerné.
- Côté application, le serveur prépare la page et la renvoie au reverse proxy.
- En dernier lieu, le proxy ajoute ce qu'il faut (compression, en-têtes de sécurité) avant de livrer la réponse au navigateur.
Tout se joue sur l'aiguillage. Le site vitrine vers un serveur, la boutique vers un autre, les appels de votre API vers un troisième : un même reverse proxy sait répartir tout cela derrière une seule porte d'entrée.
Proxy vs reverse proxy, et les autres confusions fréquentes
Proxy désigne n'importe quel intermédiaire entre deux machines. La vraie différence ? Le camp qu'il défend. D'autres outils lui ressemblent aussi, d'où bien des confusions.
Forward proxy et reverse proxy : deux camps opposés
Le proxy classique, dit forward proxy, travaille pour l'utilisateur. Une entreprise le met en place pour que ses salariés passent par lui avant d'aller sur internet : il filtre les sites, masque leur adresse IP, contrôle les usages. À l'inverse, le reverse proxy travaille pour le site, et c'est lui que rencontrent les visiteurs extérieurs. L'un protège ceux qui naviguent, l'autre ceux qui publient.
Load balancer et reverse proxy
Le load balancer se contente de répartir le trafic entre plusieurs serveurs. Un reverse proxy en est capable aussi, mais il sait en plus mettre en cache, chiffrer, réécrire des adresses ou filtrer. Mon conseil : voyez le load balancer comme une fonction, que la plupart des reverse proxies assurent sans difficulté.
Serveur web et reverse proxy
Le serveur web livre des pages et des fichiers. Le reverse proxy, lui, relaie des demandes vers d'autres serveurs. Pourquoi la frontière paraît-elle floue ? Parce que les mêmes logiciels savent faire les deux : Nginx ou Apache peuvent servir un site et, dans la même configuration, jouer l'intermédiaire pour une autre application. Notre comparatif Nginx vs Apache détaille leurs forces respectives.
Cloudflare, CDN et reverse proxy
Cloudflare ne remplace pas un reverse proxy : il en est un, opéré à grande échelle par un prestataire. Avant d'atteindre votre hébergement, votre trafic traverse son réseau. À ce rôle s'ajoutent celui de CDN, qui copie vos contenus sur des serveurs proches des visiteurs, et une protection contre les attaques DDoS. Rien ne vous empêche d'avoir, en plus, votre propre reverse proxy sur votre serveur.
Pare-feu, tunnel et middleware
Le pare-feu décide quelles connexions sont autorisées ; il ne relaie aucune page. Un tunnel (un VPN ou un tunnel Cloudflare, par exemple) crée un passage chiffré entre deux points, souvent pour exposer un serveur sans ouvrir de port sur votre réseau. Quant au middleware, c'est un morceau de code logé dans l'application, qui traite chaque requête avant votre logique métier. Le reverse proxy, lui, reste à l'extérieur de l'application.
Nginx, Caddy, Apache : quel outil retenir ?
Votre contexte compte plus que l'outil lui-même. Qui maintient le serveur ? Combien d'applications faut-il desservir ? Quel niveau de réglage voulez-vous garder ?
- Nginx : le plus répandu, rapide et très documenté. Configuré en reverse proxy, il tient en quelques lignes, à condition de bien connaître sa syntaxe.
- Caddy : le plus simple à prendre en main. Son fichier de réglage, le Caddyfile, est court, et il obtient puis renouvelle seul les certificats HTTPS.
- Apache : historique, présent chez beaucoup d'hébergeurs. Ses modules lui permettent de jouer les reverse proxies, ce qui est utile quand votre site tourne déjà dessus.
- Traefik : conçu pour les applications en conteneurs. Avec Docker, il repère les nouveaux services et crée les routes tout seul.
- Les interfaces intégrées : un NAS Synology, par exemple, propose un reverse proxy dans ses réglages. C'est pratique pour un usage interne, moins adapté à un site commercial.
Votre site vitrine est sur un hébergement mutualisé ? Vous n'avez rien à installer, l'hébergeur gère déjà cette couche. La question se pose surtout quand vous passez sur un serveur dédié ou un VPS, comme nous l'expliquons dans notre guide VPS ou mutualisé.
Les erreurs courantes à éviter
Mal réglé, un reverse proxy crée parfois plus de problèmes qu'il n'en résout. Voici les pièges que je rencontre le plus souvent en audit.
- Perdre l'adresse IP réelle des visiteurs : si l'en-tête prévu à cet effet n'est pas transmis, vos journaux et vos outils de statistiques attribuent à tout le monde l'adresse du proxy.
- Mettre en cache des pages privées : servi depuis le cache, un panier ou un espace client peut afficher les données d'un client à un autre.
- Laisser le serveur d'origine joignable en direct : tant que son adresse répond, un attaquant n'a qu'à contourner le reverse proxy.
- Créer des boucles de redirection : quand le proxy gère le HTTPS sans que l'application le sache, celle-ci redirige sans fin vers la version sécurisée.
- Oublier les délais d'attente : les imports et exports longs sont coupés si le proxy lâche la connexion trop tôt.
Votre activité repose sur plusieurs outils métier ? Pensez l'architecture dès la conception. Nous traitons ce point systématiquement lors de la création de logiciel adapté à vos besoins, pour que l'ensemble reste sûr et simple à maintenir.
Questions fréquentes
Un serveur placé devant votre site, qui accueille les visiteurs à sa place et transmet leurs demandes au serveur qui héberge réellement les pages. Son rôle : protéger ce serveur, accélérer l'affichage et gérer le HTTPS. Pour le visiteur, rien ne change.
Presque tous les sites professionnels en ont un, souvent sans le savoir : hébergeurs mutualisés, plateformes e-commerce et services comme Cloudflare en placent un devant vos pages. Les équipes techniques installent le leur dès qu'elles gèrent leur propre serveur ou plusieurs applications. Pour une TPE, la vraie question est ailleurs : qui le configure, et qui le surveille ?
Hébergement mutualisé ? Vous n'avez rien à choisir. Sur un serveur que vous administrez, je recommande Caddy pour démarrer simplement, Nginx pour un usage plus poussé, et Traefik si tout tourne dans des conteneurs. Au fond, le meilleur outil reste celui que votre prestataire maîtrise et saura maintenir dans la durée.