Proxy direct vs proxy inverseMême relais, extrémités opposées

"Proxy forward ou proxy inverse" est souvent présenté comme un choix entre deux technologies. Ce n'est pas le cas. Les deux sont la même chose : un relais qui effectue une requête au nom de quelqu'un d'autre et transmet la réponse en retour. Ils s'exécutent sur le même logiciel, car un seul nginx, un seul HAProxy ou un seul Envoy peut être l'un ou l'autre. Ce qui diffère n'est pas la machine. C'est l'extrémité de la connexion que le relais représente, et donc l'identité qu'il masque.

Un proxy forward représente le client. Il se situe du côté des personnes qui font des requêtes, fait face à l'Internet ouvert et masque qui demande. Un proxy inverse représente le serveur. Il se situe devant l'origine, fait face au public et masque qui répond. Même relais, extrémités opposées.

Saisissez cette unique distinction et toutes les lignes du tableau de comparaison habituel en découlent naturellement : qui le configure, quelle IP l'autre partie voit, où il se situe, à quoi il sert. Le reste de cet article détaille les deux rôles, puis les cas où la même machine joue les deux à la fois.

Proxy forward vs proxy inverse : la version courte

Voilà toute la distinction en trois lignes. Toute autre différence, qui le déploie et où il se situe, découle de l'extrémité que le relais représente.

L'unique chose qui change : de quel côté le proxy se situe

Un proxy est une couche d'indirection. Il relaie une requête pour que l'autre partie voie le proxy plutôt que le parti derrière lui. Chaque relais a deux extrémités, une côté client et une côté serveur, et celle qu'il représente face au monde extérieur définit son rôle.

Un proxy forward est déployé par le côté client. Votre trafic sort par lui, donc Internet voit l'adresse du proxy plutôt que la vôtre. Il masque le client. Un proxy inverse est déployé par le côté serveur. Le trafic public arrive à lui en premier, donc les visiteurs voient une adresse publiée unique plutôt que vos vraies backends. Il masque le serveur.

Le logiciel ne se préoccupe pas de savoir lequel il fait. Le même nginx qui relaie le trafic sortant pour un réseau de machines devient un proxy inverse dès lors que vous le pointez vers votre propre backend et publiez son adresse. La direction est une décision de déploiement, pas une catégorie de produit.

Proxy forward : le représentant du client

Un proxy forward agit pour le compte des personnes derrière lui. Vous le configurez sur vos propres appareils ou réseau, pointez votre client vers lui, et à partir de là vos requêtes partent via le proxy. La destination n'a aucune idée de qui les a initialement envoyées ; elle ne voit que le proxy. C'est le type de proxy que la plupart des gens désignent quand ils disent "un proxy", et c'est exactement ce qu'un service de proxy ou de scraping vous fournit.

Comment un proxy forward achemine une requête

1. Votre client envoie la requête au proxy forward plutôt que directement à la destination.
2. Le proxy remplace votre IP par la sienne et transmet la requête à la cible.
3. La cible reçoit la requête depuis l'adresse du proxy et y répond.
4. Le proxy vous transmet la réponse en retour.

À quoi il sert

• Anonymat. La cible voit l'IP du proxy, pas la vôtre, ce qui est tout le point du routage via un proxy.
• Accès géographique. Sortez via une IP dans un autre pays pour accéder à du contenu qui ne s'affiche que pour les visiteurs de cette région.
• Contrôle du trafic sortant. Une organisation peut filtrer, journaliser ou bloquer ce que ses propres utilisateurs atteignent en sortie.
• Web scraping à grande échelle. Répartissez les requêtes sur un pool rotatif pour qu'aucune IP unique ne soit martelée ou signalée.

Ce dernier cas d'usage est celui où vit la plupart de ce public, et c'est là que l'IP derrière le proxy commence à avoir de l'importance. Un proxy forward peut sortir via une adresse de datacenter ou une adresse résidentielle, et ce choix détermine si une cible protégée fait confiance à la requête. Nous couvrons ce compromis dans datacenter vs proxies résidentiels, et le protocole que le proxy utilise (HTTP ou SOCKS) dans qu'est-ce qu'un proxy SOCKS5. Quand le proxy est exposé comme un endpoint programmable plutôt qu'un hôte et un port, il devient un proxy API.

Proxy inverse : la porte d'entrée du serveur

Un proxy inverse agit pour le compte des serveurs derrière lui. Le propriétaire du site le déploie, publie son adresse comme endpoint public et garde les vraies backends privées. Les visiteurs se connectent au proxy inverse en croyant qu'il est le serveur ; il décide quel backend traite réellement chaque requête et retourne la réponse comme s'il l'avait produite lui-même. Les proxies inverses sont quasi universels à grande échelle : la grande majorité des sites à fort trafic se trouvent derrière un, qu'il soit auto-hébergé avec nginx, HAProxy ou Envoy, ou délivré via un CDN comme Cloudflare ou Fastly.

Comment un proxy inverse achemine une requête

1. Le visiteur envoie une requête à l'adresse publiée du proxy inverse.
2. Le proxy choisit un backend en bonne santé, souvent en équilibrant la charge entre plusieurs.
3. Le backend choisi traite la requête, invisible pour le visiteur.
4. Le proxy retourne la réponse, le visiteur n'ayant jamais parlé qu'à la porte d'entrée.

À quoi il sert

• Équilibrage de charge. Répartissez le trafic entrant sur de nombreux backends et routez autour de ceux qui tombent en panne, pour que le site reste disponible sous charge.
• Mise en cache. Servez des copies stockées de contenu populaire sans toucher un backend, ce qui réduit la latence et la charge de l'origine.
• Terminaison TLS. Gérez SSL/TLS en périphérie une seule fois, plutôt que sur chaque backend.
• Protection de l'origine. Cachez les vrais serveurs et ajoutez un endroit pour appliquer des limites de débit, un WAF et des règles d'accès avant que le trafic ne les atteigne jamais.

Proxy forward vs proxy inverse en un coup d'oeil

Quand la même machine joue les deux rôles

Les labels forward et inverse décrivent un rôle sur une connexion, pas un type permanent estampillé sur le matériel. Le même logiciel, parfois le même processus en cours d'exécution, peut être un proxy forward pour une connexion et un proxy inverse pour une autre.

Un CDN en périphérie est l'exemple le plus clair. Pour vos visiteurs, c'est un proxy inverse, se substituant à votre origine et servant du contenu mis en cache. Pour votre origine, quand il récupère une copie fraîche, cette même périphérie ressemble à un client arrivant via un saut forward. Une passerelle d'entreprise filtrant le trafic du personnel en sortie est un proxy forward ; la passerelle API devant vos microservices est un proxy inverse ; un sidecar de service mesh est les deux, inversant les appels entrants vers son service et transmettant les appels sortants de ce service. Rien n'a changé sur les machines. La direction de la connexion, oui.

C'est aussi là qu'une stack de scraping s'inscrit. Quand vous collectez des données publiques, vous voulez un proxy forward qui vous représente face à la cible et absorbe les éléments qui font bloquer les requêtes : rotation de l'IP de sortie, nouvelles tentatives et gestion anti-bot. Le gérer vous-même signifie maintenir des pools d'IP et une logique de routage ; un proxy forward géré le réduit à un seul endpoint.

Comment savoir lequel vous avez besoin

Posez une seule question : protégez-vous le côté qui demande, ou le côté qui répond ?

Si vous servez un site ou une API, vous voulez un proxy inverse devant votre origine, que ce soit nginx ou Caddy que vous gérez vous-même ou un CDN qui en gère un pour vous. Il vous donne équilibrage de charge, mise en cache, TLS et un seul endroit pour appliquer la sécurité avant que le trafic n'atteigne votre code.

# Reverse proxy: one public address,
# real backends kept private behind it.
server {
    listen 443 ssl;
    server_name example.com;
    location / {
        proxy_pass http://10.0.0.5:8080;
    }
}

Si vous accédez au web, pour l'anonymat, des données géo-spécifiques ou du scraping à grande échelle, vous voulez un proxy forward par lequel votre client sort. La cible voit le proxy, et un bon proxy gère les IP de sortie pour vous.

# Forward proxy: your client exits through it,
# so the target sees the proxy IP, not yours.
curl -x "http://_USER_TOKEN_:@smartproxy.crawlbase.com:8012" \
     -k "https://example.com/"

Si vous gérez les deux, c'est normal et correct : votre application se trouve derrière un proxy inverse et elle atteint des données tierces via un proxy forward. Ils ne sont pas concurrents. Ce sont des extrémités opposées de connexions différentes. Pour le côté scraping spécifiquement, voir comment un endpoint en pool se compare dans backconnect proxy vs la Crawling API, et si vous êtes encore en train de comparer des sorties, nous maintenons une présentation actuelle dans meilleurs fournisseurs de proxies.

Foire aux questions

Un proxy inverse est-il plus sécurisé qu'un proxy forward ?

Ils protègent des côtés différents, donc aucun n'est "plus sécurisé" dans l'absolu. Un proxy inverse renforce le serveur : il masque les origines, termine TLS et vous donne un endroit unique pour un WAF et des limitations de débit. Un proxy forward renforce le client : il dissimule qui demande et peut filtrer ce que les utilisateurs atteignent. Choisissez en fonction du côté que vous devez défendre.

Un proxy inverse est-il identique à un VPN ?

Non. Un proxy inverse opère au niveau de la couche applicative et relaie des requêtes spécifiques vers des serveurs backend. Un VPN opère plus bas, construisant un tunnel chiffré qui transporte tout le trafic d'un appareil vers un réseau privé. Un proxy inverse se place devant des serveurs ; un VPN connecte des clients à un réseau.

Un CDN est-il un proxy inverse ?

Oui. Un CDN est un proxy inverse distribué mondialement devant votre origine. Chaque périphérie met en cache et sert votre contenu, termine TLS et protège les vrais serveurs, ce qui est exactement le rôle de proxy inverse opéré à grande échelle.

Le même serveur peut-il être à la fois un proxy forward et un proxy inverse ?

Oui, car le rôle est par connexion. Un CDN en périphérie inverse le trafic vers vos visiteurs tout en ressemblant à un client forward pour votre origine, et un sidecar de service mesh inverse les appels entrants et transmet les appels sortants. Le même processus joue les deux rôles selon la direction.

Ai-je besoin d'un proxy forward ou inverse pour le web scraping ?

Un proxy forward. Le scraping est un problème d'accès : vous êtes le client, et vous voulez que la cible voie l'IP du proxy plutôt que la vôtre. Un proxy inverse se place devant des serveurs que vous possédez, donc il ne sert à rien pour atteindre le site de quelqu'un d'autre.

Un équilibreur de charge est-il un proxy inverse ?

L'équilibrage de charge est l'un des rôles qu'un proxy inverse assume. Un équilibreur de charge dédié peut opérer plus bas dans la pile au niveau de la couche transport, mais un équilibreur de charge au niveau applicatif est fonctionnellement un proxy inverse qui se concentre sur la répartition du trafic sur plusieurs backends.

SR

Syeda Roushan Arshid

Rédactrice de contenu · Crawlbase

Rédactrice de contenu ayant couvert les proxys, le stockage cloud et la sécurité des données sur le blog Crawlbase, rendant les sujets d'infrastructure et de protection des données accessibles à un large public d'ingénieurs.