Programmation · Serveurs · Réseau

C’est quoi un reverse proxy ?

Dès que vous faites tourner plus d’une appli sur un serveur — un site, une API, peut-être quelques conteneurs — vous tombez sur un problème concret : les visiteurs arrivent tous sur les ports 80 et 443, mais chaque appli écoute ailleurs. Un reverse proxy est la réponse standard. Ce guide explique ce qu’est un reverse proxy, en quoi il diffère du proxy que vous connaissez peut-être déjà, et pourquoi presque toute mise en production en a un.

La définition courte

Un reverse proxy est un serveur placé devant un ou plusieurs serveurs backend, qui reçoit chaque requête cliente entrante et la transmet au backend approprié — puis renvoie la réponse de ce backend au client. Pour le visiteur, le reverse proxy est le site : il ne parle qu’à lui et ne voit jamais les serveurs derrière. Le mot « reverse » (inverse) a son importance, et la section suivante explique pourquoi.

Reverse proxy vs proxy classique

Un proxy classique (forward proxy) se place devant les clients. Quand votre navigateur est configuré pour en utiliser un, vos requêtes sortent par le proxy en votre nom — il agit pour ceux qui font les requêtes. Un reverse proxy est l’image miroir : il se place devant les serveurs et agit en leur nom. Les clients s’y connectent en pensant que c’est le vrai serveur, et c’est lui qui décide quel backend traite réellement chaque requête. Même idée d’intermédiaire, côté opposé de la conversation.

À quoi sert concrètement un reverse proxy

• Routage par nom d’hôte ou par chemin : envoyer api.example.com vers votre API et example.com vers votre site, même si les deux tournent sur la même machine.
• Terminaison TLS : gérer les certificats HTTPS en un seul endroit, pour que chaque backend parle du HTTP simple en interne et que vous gériez les certificats une seule fois.
• Cache : stocker et servir directement les réponses fréquentes, pour ne pas solliciter le backend à chaque requête.
• Tampon et protection : absorber les clients lents, appliquer des limites et masquer les vraies adresses des backends derrière un point d’entrée public unique.

En pratique, le routage et le TLS suffisent déjà à le justifier : ils vous permettent d’héberger proprement plusieurs applis sur un seul VPS, en HTTPS, derrière une seule adresse.

Reverse proxy vs load balancer

Ces deux notions se recoupent, d’où la confusion. Un load balancer (répartiteur de charge) a un rôle précis : répartir le trafic entrant sur plusieurs backends identiques pour qu’aucun ne soit débordé. Un reverse proxy est le concept plus large — il transmet les requêtes et peut faire bien des choses (routage, TLS, cache), et répartir la charge entre les backends en fait partie. Un load balancer est donc essentiellement un reverse proxy concentré sur la tâche de répartition. La plupart des reverse proxies modernes savent aussi répartir la charge, tandis qu’un load balancer dédié ne fait parfois pas grand-chose d’autre.

Les outils courants

Les reverse proxies les plus utilisés sont Nginx, Caddy, HAProxy et Traefik. Nginx est la référence historique, extrêmement rapide pour servir et faire du proxy. Caddy est apprécié car il obtient et renouvelle les certificats HTTPS automatiquement, presque sans configuration. Traefik est conçu pour les environnements de conteneurs et Kubernetes, où il découvre les services au fil de leurs apparitions et disparitions. HAProxy est privilégié quand la répartition de charge à fort volume est la priorité. Les fournisseurs cloud proposent aussi des reverse proxies et load balancers managés en tant que service.

Un exemple minimal

Une config de reverse proxy est surtout une courte liste de règles. Avec Nginx, envoyer les requêtes d’un hôte vers une appli qui tourne en local sur le port 3000 ressemble à ceci :

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
    }
}

Voilà toute l’idée : les requêtes pour example.com arrivent sur Nginx au port 80, et Nginx les transmet à votre appli sur le port 3000, en transmettant l’hôte d’origine. Ajoutez un bloc TLS et un second server pour votre API, et une seule machine sert proprement plusieurs applis en HTTPS.

Les compromis honnêtes

Un reverse proxy ajoute une pièce mobile de plus. Il devient le point unique par lequel passe chaque requête : s’il tombe, tout ce qui est derrière devient inaccessible — d’où une mise en production fiable, parfois en double. Il ajoute aussi un peu de latence et un fichier de config de plus à comprendre. Pour une seule petite appli qui écoute déjà sur le port 443, vous n’en avez peut-être pas besoin. Mais dès que vous hébergez plus d’un service, voulez gérer le HTTPS au même endroit ou comptez monter en charge, un reverse proxy est vite rentabilisé.

Questions fréquentes

Parcourez d’autres explications claires dans notre index des guides.