Proxy et reverse proxy : quelle différence, et quand utiliser chacun

Les deux sont des intermédiaires HTTP, mais ils ne travaillent pas pour le même camp. Le proxy agit pour les clients, le reverse proxy agit pour les serveurs : tout le reste en découle.

Par la rédaction de Pixelabs · 12 octobre 2026

Un proxy (ou proxy direct, forward proxy) se place entre des clients et Internet et va chercher les contenus à leur place. Un reverse proxy, ou proxy inverse, se place devant un ou plusieurs serveurs et reçoit les requêtes à leur place. La différence ne tient pas à la technique, souvent la même, mais au côté qu'il représente et à qui doit le configurer.

Le proxy direct : au service des clients

La documentation d'Apache HTTP Server le définit ainsi : un proxy direct ordinaire est un serveur intermédiaire placé entre le client et le serveur d'origine. Pour obtenir un contenu, le client envoie sa requête au proxy en nommant le serveur visé ; le proxy le récupère et le renvoie au client. Point essentiel : le client doit être configuré spécialement pour passer par ce proxy.

Usages typiques cités par Apache :

• donner un accès Internet à des postes internes qui en sont sinon empêchés par un pare-feu ;
• mettre en cache les contenus pour réduire la consommation réseau.

Dans une entreprise, c'est le proxy que l'on déclare dans le navigateur ou par stratégie de groupe, et qui journalise ou filtre la navigation. Certains pare-feu l'intègrent : OPNsense, par exemple, liste un proxy cache direct parmi ses fonctions de base, comme le rappelle le comparatif OPNsense vs pfSense.

Le reverse proxy : au service des serveurs

À l'inverse, explique Apache, un reverse proxy apparaît au client comme un serveur web ordinaire. Aucune configuration n'est nécessaire côté client : celui-ci envoie des requêtes normales, et le reverse proxy décide vers quel serveur les transmettre, puis renvoie la réponse comme s'il en était l'origine.

Usages typiques :

• donner aux internautes l'accès à un serveur situé derrière un pare-feu ;
• répartir la charge entre plusieurs serveurs (load balancing) ;
• mettre en cache les réponses d'un serveur lent ;
• réunir plusieurs serveurs sous un même espace d'URL (par exemple /app1 et /app2 sur le même nom).

C'est lui que l'on place en DMZ, devant une application interne : le pare-feu n'ouvre le port HTTPS que vers le reverse proxy, jamais vers les serveurs d'application. La page sur les règles firewall pfSense montre comment isoler une telle DMZ du LAN.

Proxy vs reverse proxy : le tableau

Un reverse proxy avec nginx

Le module ngx_http_proxy_module de nginx transmet les requêtes à un autre serveur. Son exemple de base, adapté à un serveur d'application de lab en 192.168.30.10 :

location / {
    proxy_pass http://192.168.30.10:8080;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
}

Pourquoi redéfinir Host ? La documentation précise que, par défaut, nginx remplace l'en-tête Host d'origine par $proxy_host, c'est-à-dire le nom du serveur visé dans proxy_pass. Avec $host, l'application reçoit le nom demandé par le visiteur, ce dont elle a souvent besoin pour générer ses liens.

Pour transmettre la chaîne des adresses clientes, nginx fournit la variable $proxy_add_x_forwarded_for : l'en-tête X-Forwarded-For reçu, complété par $remote_addr.

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

Attention à proxy_pass avec ou sans URI : si la directive contient un chemin, la partie de l'URI qui correspond au bloc location est remplacée par ce chemin ; sans chemin, l'URI est transmise telle quelle.

Les deux modes avec Apache httpd

Apache sait jouer les deux rôles avec mod_proxy. La documentation donne ces exemples minimaux. En reverse proxy :

ProxyPass "/foo" "http://foo.example.com/bar"
ProxyPassReverse "/foo" "http://foo.example.com/bar"

En proxy direct, réservé à un hôte interne :

ProxyRequests On
ProxyVia On
<Proxy "*">
    Require host internal.example.com
</Proxy>

N'activez jamais ProxyRequests sans avoir restreint qui peut utiliser le proxy. Apache avertit qu'un proxy ouvert est dangereux pour votre réseau comme pour Internet : n'importe qui pourrait s'en servir pour masquer son origine.

En mode reverse proxy, mod_proxy_http ajoute de lui-même les en-têtes X-Forwarded-For (adresse du client), X-Forwarded-Host (hôte demandé) et X-Forwarded-Server (nom du proxy). Apache prévient que ces en-têtes peuvent contenir plusieurs valeurs séparées par des virgules si la requête a traversé plusieurs proxys : l'application ne doit pas supposer qu'il n'y en a qu'une.

Et sous Windows ?

La question revient souvent sous la forme « reverse proxy Windows ». nginx publie une version Windows, mais sa documentation la considère comme une version bêta : elle n'utilise que les méthodes select() et poll(), et nginx prévient qu'il ne faut pas en attendre de hautes performances. Cette mise en garde plaide pour héberger un reverse proxy nginx de production sur un système Unix ou Linux, et pour réserver la version Windows aux tests.

Comment choisir

• Vous voulez contrôler ou mettre en cache la navigation de vos utilisateurs : c'est un proxy direct, déclaré sur les postes.
• Vous voulez publier une ou plusieurs applications internes derrière un seul point d'entrée HTTPS : c'est un reverse proxy, invisible pour les visiteurs.
• Vous voulez répartir la charge entre plusieurs serveurs identiques : reverse proxy également.

Pour monter le pare-feu qui protégera ce reverse proxy dans un lab, partez de la configuration de pfSense, puis parcourez la rubrique réseau et pare-feu ou revenez à l'accueil de Pixelabs.

Questions fréquentes