Les serveurs proxy expliqués

Par La rédaction de Mon-Adresse-IP.net·Publié le 22 mai 2026·Mis à jour le 21 août 2026·

Le proxy est l'outil réseau le plus ancien et le plus mal expliqué : on le présente comme un « VPN au rabais » alors qu'il répond à un autre besoin. Ce guide détaille ce que chaque type de proxy manipule réellement, pourquoi les niveaux d'anonymat affichés sur les listes publiques ne valent rien, et dans quels cas précis le proxy reste le bon outil.

Un proxy, c'est un mandataire

Le terme anglais proxy vient du vocabulaire juridique : le mandataire, celui qui agit pour le compte d'un autre. La traduction officielle française est d'ailleurs « mandataire » ou « serveur mandataire », et elle décrit mieux le mécanisme que le mot proxy lui-même. Vous ne parlez plus au site : vous demandez à un tiers de lui parler à votre place, puis de vous rapporter la réponse.

Cette délégation a trois conséquences immédiates, qui expliquent la totalité des usages du proxy. D'abord, le serveur de destination voit l'adresse du mandataire et non la vôtre : c'est la fonction de masquage, celle que le grand public retient. Ensuite, le mandataire se trouve sur le chemin : il peut compter, journaliser, filtrer, mettre en cache, refuser ou modifier ce qui le traverse ; c'est la fonction de contrôle, celle qui intéresse les entreprises. Enfin, la délégation crée un point de confiance obligatoire : tout ce que le site ne voit plus, le mandataire le voit à sa place.

Ce troisième point est le seul qui compte vraiment pour votre vie privée. Utiliser un proxy ne supprime pas l'observateur : il le déplace. Vous retirez au site distant la connaissance de votre adresse IP publique et vous l'offrez à l'exploitant du proxy, qui gagne au passage la liste horodatée de tout ce que vous consultez. Le calcul n'est favorable que si vous faites davantage confiance au second qu'au premier.

Ce qui se passe réellement sur le réseau

Un navigateur qui n'utilise pas de proxy ouvre une connexion TCP vers le site et envoie une requête de la forme GET /page.html HTTP/1.1, complétée par un en-tête Host. Avec un proxy HTTP configuré, deux choses changent : la connexion TCP part vers le proxy, et la ligne de requête contient l'URL complète.

GET http://exemple.fr/page.html HTTP/1.1
Host: exemple.fr
# la cible est écrite en entier : le proxy doit savoir où aller

Ce format ne fonctionne qu'en clair. Pour du HTTPS, le proxy ne peut pas lire une URL qu'il ne déchiffrera jamais : le navigateur emploie alors la méthode CONNECT, définie dans les spécifications HTTP de l'IETF, pour demander l'ouverture d'un simple tunnel TCP.

CONNECT exemple.fr:443 HTTP/1.1
# le proxy répond 200 puis se contente de recopier les octets
# dans les deux sens, sans rien comprendre au contenu chiffré

Retenez cette ligne, car elle règle à elle seule la question « mon proxy voit-il ce que je fais ? ». Le nom de domaine est envoyé en clair au proxy, avant tout chiffrement. Il réapparaît d'ailleurs une seconde fois dans le champ SNI du handshake TLS. Le proxy ignore donc le contenu des pages, mais il dispose du domaine, de l'heure, de la durée et du volume de chaque connexion : un journal de navigation à peine moins précis que celui d'un fournisseur d'accès.

Deux en-têtes complètent le dispositif. Proxy-Authorization transporte les identifiants quand le proxy exige une authentification ; s'ils manquent, le proxy répond par un code 407 Proxy Authentication Required, à ne pas confondre avec le 401 renvoyé par un site. Notre référence des codes de réponse HTTP détaille ces distinctions. Côté ports, un proxy HTTP écoute traditionnellement sur 3128 ou 8080, un proxy SOCKS sur 1080 ; le tableau de notre page ports TCP et UDP replace ces valeurs parmi les affectations officielles.

Les types de proxy, comparés

Le mot « proxy » recouvre des objets techniques très différents. Ce tableau les sépare selon ce qu'ils manipulent réellement, car c'est de là que découlent leurs limites.

Un point mérite d'être souligné, car il est presque toujours mal formulé ailleurs : un « proxy HTTPS » ne chiffre pas votre liaison vers le proxy. Il sait seulement ouvrir un tunnel pour du trafic déjà chiffré par le site. Un véritable proxy chiffré, où la liaison entre votre machine et le mandataire est elle-même en TLS, existe mais reste rare et doit être configuré explicitement.

Proxy direct et proxy inverse

La distinction proxy direct / proxy inverse est celle qui est le plus souvent expliquée de travers, alors qu'elle tient en une question : qui a installé la machine, et pour protéger qui ?

Le proxy direct (forward proxy) est déployé du côté client. C'est vous, ou votre employeur, qui le configurez. Il connaît son utilisateur et découvre la destination à chaque requête. Il masque le client vis-à-vis du serveur, applique une politique d'accès, met en cache ce qui est populaire. C'est le proxy dont parle tout le reste de ce guide.

Le proxy inverse (reverse proxy) est déployé du côté serveur, par l'éditeur du site. Il connaît sa destination, un parc de machines qu'il dessert, et découvre le client à chaque requête. Vous en traversez sans le savoir sur l'immense majorité des sites que vous consultez, ce site compris. Des logiciels comme nginx, HAProxy, Varnish ou le module mod_proxy d'Apache remplissent ce rôle, tout comme les réseaux de diffusion de contenu.

Un proxy inverse rend au serveur quatre services principaux : il termine le TLS en un point unique, ce qui évite d'installer les certificats sur chaque machine ; il répartit la charge entre plusieurs serveurs applicatifs ; il sert un cache pour les contenus statiques ; il filtre les requêtes hostiles avant qu'elles n'atteignent l'application. Au passage, il masque l'adresse IP réelle des serveurs d'origine : c'est pourquoi une recherche d'adresse IP sur un nom de domaine renvoie fréquemment un point de présence d'un réseau de diffusion, situé à Paris ou à Francfort, plutôt que la machine qui exécute réellement le code.

C'est aussi le proxy inverse qui produit une famille bien identifiable de codes d'erreur. Un 502 Bad Gateway signifie que le proxy a reçu une réponse invalide du serveur d'origine ; un 504 Gateway Timeout, que le serveur d'origine n'a pas répondu à temps ; un 503 Service Unavailable, que le service est volontairement indisponible ou saturé. Quand vous voyez ces trois codes, vous parlez à un intermédiaire, pas à l'application : notre page sur les codes HTTP décrit leur signification exacte et ce qu'ils impliquent pour le diagnostic.

Les niveaux d'anonymat annoncés

Les listes de proxys publics classent leurs entrées en trois catégories : transparent, anonyme, élite (ou high anonymity). Cette classification repose entièrement sur deux en-têtes HTTP que le proxy ajoute, ou n'ajoute pas, à vos requêtes.

Via est un en-tête standard : un intermédiaire conforme aux spécifications HTTP est censé s'y déclarer, en indiquant la version du protocole et un identifiant. C'est une exigence d'ingénierie, destinée au diagnostic des boucles et des caches, pas une trahison. X-Forwarded-For, lui, n'a jamais été un standard officiel : c'est une convention née chez les éditeurs de proxys, qui y écrivent l'adresse IP du client d'origine afin que le serveur final sache à qui il parle. Une version normalisée, l'en-tête Forwarded, a été publiée plus tard par l'IETF avec des paramètres explicites (for=, proto=, by=), mais l'ancienne convention reste largement majoritaire.

Ces étiquettes sont peu fiables pour quatre raisons concrètes. Premièrement, elles sont mesurées par un script qui interroge une seule page : rien n'empêche le serveur de se comporter autrement le lendemain, ou différemment selon la destination. Deuxièmement, elles ne portent que sur ces deux champs ; d'autres en-têtes moins connus, ou la simple conservation d'un User-Agent caractéristique, suffisent à vous distinguer. Troisièmement, l'adresse IP n'est plus qu'un signal parmi d'autres : l'ordre des en-têtes, la signature du handshake TLS de votre client et votre empreinte de navigateur restent identiques quel que soit le proxy. Quatrièmement et surtout, aucune de ces mentions ne dit un mot de ce qui compte le plus : la journalisation côté proxy.

Proxy contre VPN

La comparaison n'a de sens que si l'on cesse de traiter les deux outils comme des concurrents. Un VPN crée une interface réseau virtuelle et détourne tout le trafic de la machine dans un tunnel chiffré ; un proxy est un réglage d'application qui redirige certaines connexions. Ils n'opèrent pas au même étage.

Le proxy est le bon outil dans quatre situations précises. Quand une seule application doit sortir ailleurs : un navigateur secondaire configuré sur un proxy, pendant que le reste de la machine reste sur la connexion normale, évite d'imposer un tunnel global. Pour des tests géographiques légitimes : vérifier qu'un site s'affiche correctement depuis un autre pays, contrôler l'affichage d'une campagne, valider une redirection linguistique. Pour le filtrage et la journalisation en entreprise : c'est l'usage historique, et le VPN n'y répond pas du tout. Pour la mise en cache : un proxy mutualisant les contenus statiques d'un site reste efficace sur les réseaux à bande passante contrainte.

Il n'est pas le bon outil dès qu'il faut protéger le contenu du trafic, couvrir tous les logiciels d'un appareil, ou se prémunir sur un réseau hostile. Sur un Wi-Fi public, un proxy n'apporte rien face à un voisin de table : seul le chiffrement compte, celui du site ou celui d'un tunnel. Et si l'objectif est de dissocier votre identité de votre navigation, ni l'un ni l'autre ne suffit ; c'est le domaine du réseau Tor, avec ses propres contreparties. Notre comparatif masquer son adresse IP place ces trois approches côte à côte, et notre guide des VPN détaille la seconde, tandis que la page protocoles VPN explique ce que le tunnel chiffre exactement.

Le danger des proxys publics gratuits

Commençons par l'économie, parce qu'elle explique tout le reste. Exploiter un proxy public coûte trois choses : de la bande passante sortante, facturée par tout hébergeur ; des adresses IPv4 publiques, devenues une ressource rare et payante depuis l'épuisement des blocs disponibles au RIPE ; du temps d'administration. Un service qui assume ces coûts et ne facture rien se rémunère nécessairement ailleurs. La question utile n'est donc pas « ce proxy est-il honnête ? » mais « par quel mécanisme est-il payé ? ».

Voici ce qui est techniquement possible pour l'exploitant d'un proxy que vous avez configuré vous-même : non pas ce qu'il fait forcément, mais ce que rien ne l'empêche de faire.

• Lire intégralement le trafic non chiffré. Sur une page en HTTP simple, tout est en clair : URL, contenu, champs de formulaire, cookies de session. Un identifiant saisi sur un site mal configuré est lisible tel quel.
• Modifier les pages au passage. Injection de publicités, remplacement d'identifiants d'affiliation, ajout d'un script de suivi, voire d'un code hostile. La modification est invisible pour vous puisqu'elle a lieu avant l'affichage.
• Journaliser les métadonnées, même en HTTPS. Comme vu plus haut, la requête CONNECT livre le domaine cible en clair. Un historique de navigation horodaté se constitue sans jamais déchiffrer quoi que ce soit.
• Tenter de dégrader la connexion. Empêcher le passage au chiffrement sur les sites qui le proposent encore en option. Cette attaque échoue sur les sites correctement configurés, grâce au mécanisme HSTS qui impose le HTTPS au navigateur, mais elle reste possible ailleurs.
• Détourner la résolution de noms. Si le proxy résout les domaines pour vous, il choisit la réponse. Nos guides sur le DNS et sur le DNS chiffré expliquent pourquoi ce maillon est aussi sensible que le transport lui-même.
• Vous compter comme un actif. Certains services gratuits mutualisent leurs utilisateurs et revendent l'usage de leur connexion à des tiers : c'est le modèle décrit dans la section suivante.

Ce que le proxy ne peut pas faire, en revanche, mérite d'être dit avec la même précision : il ne peut pas lire le contenu d'une session HTTPS sans que votre navigateur ne signale une erreur de certificat, sauf si une autorité de certification a été ajoutée à la réserve de confiance de votre appareil. C'est très exactement le mécanisme employé en entreprise, décrit plus bas, et c'est pourquoi un avertissement de certificat ne doit jamais être ignoré derrière un proxy inconnu.

Les proxys résidentiels

Un proxy résidentiel n'est pas hébergé dans un centre de données : il sort par la connexion Internet d'un particulier, avec une adresse attribuée par un fournisseur d'accès grand public. C'est tout l'intérêt commercial du produit. Les plateformes détectent en quelques millisecondes qu'une adresse appartient à un hébergeur (c'est d'ailleurs le principe de la détection décrite dans notre méthodologie) alors qu'une adresse résidentielle française ressemble à celle d'un abonné ordinaire. Les tarifs de ces services se comptent en volume de données, pas en durée : la ressource vendue est l'adresse elle-même.

D'où viennent ces adresses ? De trois sources, très inégales sur le plan éthique.

1. Un partage rémunéré et assumé. Des applications proposent explicitement de louer une part de bande passante contre une somme modique. L'utilisateur sait ce qu'il vend, même s'il en mesure rarement les conséquences.
2. Un module intégré à un logiciel gratuit. C'est le cas le plus répandu : une extension, un utilitaire ou un service « gratuit » embarque un composant de partage de connexion, mentionné dans des conditions d'utilisation que personne ne lit. L'utilisateur a formellement accepté, mais il ignore qu'un trafic inconnu sort désormais sous son adresse.
3. Un appareil compromis. Objets connectés mal sécurisés, routeurs anciens, téléphones infectés : le relais est installé sans le moindre consentement. Notre page sur la sécurité des objets connectés détaille cette catégorie d'équipements vulnérables.

Les questions juridiques que cela soulève sont réelles et rarement posées. Du côté du RGPD, un consentement doit être libre, spécifique, éclairé et univoque : une clause noyée dans les conditions générales d'un utilitaire, sans explication de ce que « partager sa bande passante » implique concrètement, remplit difficilement ce critère. Notre page adresse IP et RGPD rappelle par ailleurs que l'adresse IP est une donnée à caractère personnel au sens du droit européen, ce qui donne à ce commerce une portée qui dépasse la simple question technique.

Du côté contractuel, les conditions générales des fournisseurs d'accès français encadrent strictement la revente ou le partage de l'accès : héberger un relais commercial sur sa ligne peut constituer un manquement au contrat d'abonnement. Enfin, et c'est le point le plus concret : le trafic acheminé sort sous votre adresse. C'est elle qui apparaîtra dans les journaux du site distant, elle qui sera bloquée en cas d'abus, et elle qui sera identifiée en premier si une réquisition est adressée à votre opérateur : un mécanisme décrit dans notre page sur la conservation des données par les FAI.

Configurer un proxy

Il existe deux niveaux de réglage, et confondre les deux est la source d'erreur la plus fréquente. Le réglage système est une préférence que le système d'exploitation expose ; les applications sont invitées à la suivre, mais rien ne les y oblige. Le réglage applicatif est interne à un logiciel et l'emporte toujours sur le précédent.

1. Windows Paramètres › Réseau et Internet › Proxy, avec deux blocs distincts : configuration automatique (script PAC) et configuration manuelle. Attention : certains composants système utilisent une pile réseau différente, dont le proxy se règle en ligne de commande via netsh winhttp et pas dans cette fenêtre.
2. macOS Réglages Système › Réseau › l'interface active › Détails › Proxys. Le réglage est propre à chaque interface : un proxy défini sur le Wi-Fi ne s'applique pas à une connexion Ethernet.
3. Linux L'environnement de bureau propose un réglage global, mais beaucoup d'outils en ligne de commande lisent plutôt les variables d'environnement http_proxy, https_proxy et no_proxy. Ces variables n'ont aucun effet sur les navigateurs.
4. Firefox Paramètres › Général › Paramètres réseau. C'est le seul navigateur grand public à embarquer une configuration complète et indépendante, avec le choix entre HTTP, HTTPS et SOCKS, et une option décisive : la résolution DNS par le proxy en mode SOCKS.
5. Chrome, Edge et Safari Ils s'appuient sur le réglage système et renvoient vers celui-ci. Les extensions de gestion de proxy contournent cette limite ; elles voient alors l'intégralité de votre navigation, ce qui en fait un choix à peser.
6. Applications individuelles Un client de messagerie, un gestionnaire de téléchargement ou un outil de développement disposent souvent de leur propre champ « proxy ». Vérifiez-les un par un si vous voulez une couverture complète.

Deux mécanismes automatiques méritent d'être connus. Le fichier PAC (Proxy Auto-Config) est un petit script JavaScript hébergé sur le réseau, qui décide destination par destination s'il faut passer par le proxy ou sortir directement : c'est ainsi qu'une entreprise fait sortir l'intranet en direct et le reste par le filtre. Le mécanisme WPAD va plus loin en faisant découvrir ce fichier automatiquement, via une option DHCP ou une convention de nommage DNS. Pratique, mais c'est aussi une surface d'attaque connue : sur un réseau non maîtrisé, un tiers qui répond à la place du serveur légitime impose son propre proxy. Le protocole DHCP et ses options sont détaillés dans notre page DHCP expliqué.

Le proxy en entreprise et l'interception TLS

En entreprise, le proxy n'a jamais eu pour objet de masquer les salariés : il sert à filtrer les destinations, à journaliser les accès, à bloquer les logiciels malveillants et à faire respecter une politique d'usage. Comme la quasi-totalité du web est désormais chiffrée, un filtre qui se contenterait de lire les requêtes en clair ne verrait plus rien. D'où la généralisation de l'interception TLS, aussi appelée déchiffrement ou inspection en profondeur.

Le mécanisme est le suivant. Le poste de travail se voit installer, via la gestion de parc, un certificat racine appartenant à l'entreprise. Lorsque vous demandez un site en HTTPS, le proxy ouvre lui-même la connexion chiffrée vers ce site, déchiffre le contenu, l'analyse, et vous présente une seconde connexion chiffrée, avec un certificat qu'il fabrique à la volée pour le domaine demandé et qu'il signe avec sa propre autorité. Votre navigateur l'accepte sans broncher, puisque cette autorité figure dans sa réserve de confiance. Il y a bien deux connexions, et un point où tout est en clair.

Ce que cela implique pour vous est simple à énoncer : sur un poste ainsi équipé, le cadenas de la barre d'adresse ne garantit plus la confidentialité vis-à-vis de l'employeur. Le contenu des webmails personnels, des messageries en ligne et des formulaires est techniquement lisible par l'équipement d'inspection.

Le cadre juridique français ne laisse pas cette pratique sans limites, même si elle est licite dans son principe. L'employeur peut contrôler l'usage professionnel des outils qu'il fournit, mais ce contrôle doit être proportionné à la finalité poursuivie, porté à la connaissance des salariés (typiquement par une charte informatique annexée au règlement intérieur) et précédé de l'information et de la consultation des instances représentatives du personnel. La CNIL publie des recommandations constantes sur ce point, et la jurisprudence française protège spécifiquement les fichiers et messages que le salarié a clairement identifiés comme personnels. Une surveillance permanente et généralisée du contenu de la navigation reste, elle, difficile à justifier.

Deux effets techniques secondaires sont utiles à connaître. D'abord, certaines applications refusent tout simplement de fonctionner derrière une interception : elles pratiquent l'épinglage de certificat, c'est-à-dire qu'elles n'acceptent qu'une autorité précise et détectent la substitution. Ensuite, la sécurité globale de la connexion devient celle de l'équipement d'inspection : s'il valide mal les certificats des sites distants ou s'il accepte des algorithmes obsolètes, il abaisse le niveau de protection de tous les postes derrière lui.

Vérifier ce que votre proxy fait vraiment

Un proxy se contrôle en quelques minutes, sans outil particulier. Ces cinq vérifications valent mieux que n'importe quelle promesse commerciale.

1. L'adresse vue de l'extérieur Chargez notre page d'accueil avant et après activation. Si l'adresse affichée n'a pas changé, le trafic ne passe pas par le proxy : le réglage n'est pas pris en compte par ce navigateur.
2. Les en-têtes transmis Ouvrez mes en-têtes HTTP et cherchez Via, X-Forwarded-For et Forwarded. Vous saurez si votre adresse d'origine est recopiée par l'intermédiaire.
3. La nature de l'adresse de sortie Passez l'adresse obtenue dans notre outil de recherche d'IP : l'organisation et le nom d'hôte associés vous diront s'il s'agit d'un hébergeur ou d'une ligne résidentielle. C'est déterminant pour comprendre pourquoi certains sites vous opposent des vérifications supplémentaires.
4. Les fuites hors navigateur Lancez le test WebRTC, puis vérifiez quel résolveur DNS est réellement utilisé. Un proxy applicatif laisse volontiers passer ces deux canaux.
5. La cohérence du reste de la machine Ouvrez un autre logiciel connecté et observez son trafic. Si seule une application est configurée, tout le reste sort avec votre adresse réelle : c'est le comportement normal d'un proxy, pas un dysfonctionnement.

Le vocabulaire employé dans ce guide (mandataire, tunnel, SNI, épinglage) est repris et défini dans notre glossaire des termes réseau, utile si vous devez expliquer ces notions autour de vous.

Questions fréquentes