C’est quoi la différence entre un VPN et un Proxy ?

« Un serveur proxy ne chiffre rien, donc ton FAI voit tout. » Cette phrase traîne partout. Elle date pourtant d’un web qui circulait en clair. Aujourd’hui, presque toutes les pages passent en HTTPS, et la différence avec un VPN se joue ailleurs.

Pour la mesurer, on a monté un petit Internet dans une machine Linux. Un PC, une box, trois proxys, un VPN et un site. Puis Chromium et Firefox ont chargé les mêmes pages, mode par mode, pendant qu’on écoutait à quatre endroits.

Le verdict tient en deux phrases. Aucun intermédiaire n’a lu le contenu d’une page HTTPS. Mais derrière un proxy, le site a quand même appris ta vraie adresse IP, dans cinq essais sur six.

Serveur proxy ou VPN : deux intermédiaires, deux portées

Un serveur proxy est un intermédiaire que ton logiciel choisit d’utiliser. Ton navigateur lui confie ses requêtes, et le proxy les transmet au site à sa place. Le site voit donc l’adresse IP du proxy, pas la tienne. En français, le terme officiel est d’ailleurs « serveur mandataire », publié au Journal officiel en 1999.

Il se règle logiciel par logiciel. Un proxy déclaré dans ton navigateur ne couvre ni ton client mail ni tes jeux. Même réglé dans Windows, il ne sert qu’aux logiciels qui acceptent de passer par lui.

Un VPN, lui, ajoute une carte réseau virtuelle à ton système. Tout ce qui sort de ta machine emprunte alors un tunnel chiffré jusqu’au serveur du VPN. En mode normal, navigateur, jeux et mises à jour passent tous par lui.

Côté proxy, trois protocoles se partagent le terrain. Ils ne laissent pas voir la même chose.

Pour une page HTTPS, un proxy HTTP reçoit d’abord une demande en clair : « CONNECT jurojin.net:443 ». Le proxy ouvre la connexion vers le site, puis relaie les octets chiffrés sans les lire. La norme HTTP le décrit comme un relais aveugle. Pour une page en HTTP simple, en revanche, le proxy reçoit et transmet la page entière.

Le proxy HTTPS suit le même principe. Seule différence : ton navigateur chiffre d’abord tout son dialogue avec le proxy. Le SOCKS5, décrit par la RFC 1928 en 1996, travaille plus bas. Il relaie n’importe quelle connexion, sans rien comprendre au web, et sans rien chiffrer.

Deux autres outils portent le même nom. Le proxy web, ou proxy en ligne, est un site qui va chercher la page à ta place. C’est le principe de la vue anonyme de Startpage. Le reverse proxy, lui, travaille pour le site, pas pour toi. Il se place devant ses serveurs pour répartir la charge et les protéger.

Le test : deux vrais navigateurs et quatre points d’écoute

Pour ce test, on a recréé un Internet miniature dans une seule machine Linux. Chaque acteur y tourne dans son propre espace réseau isolé. Ton PC, ta box et ton FAI, un serveur proxy, un serveur VPN et un site. Les adresses sont celles que les normes réservent aux exemples. Ta vraie IP publique y vaut 203.0.113.10.

Le serveur proxy fait tourner Squid, en proxy HTTP et HTTPS, et Dante, en SOCKS5. Les deux gardent leurs réglages d’usine. Le VPN utilise WireGuard, le protocole intégré au noyau Linux depuis mars 2020.

Dans chaque mode, Chromium 153 puis Firefox 158 chargent trois pages du même site. Une en HTTPS, une en HTTP simple, et une page qui lance WebRTC. Cette technologie fait tourner les appels vidéo dans le navigateur. Chaque page porte un repère unique, pour savoir qui a pu la lire.

Chromium 153 date de septembre 2026. Chrome sort désormais une version toutes les deux semaines. Ces mécanismes, eux, bougent peu : rejouée sur Chromium 141, plus vieux d’un an, la série donne les mêmes résultats.

On écoute à quatre endroits : ta ligne, le proxy, le tunnel côté VPN et le site. Au total, 24 séries de mesures et 75 captures réseau. On les a lues avec tshark, la version en ligne de commande de Wireshark. Le tableau ci-dessous résume ce que chacun a appris.

Ton FAI voit les noms des sites, pas le contenu des pages

Sans protection et par défaut, ton PC demande chaque nom de site au résolveur DNS de ton FAI. Celui du labo a noté « site.test » à chaque visite. Ensuite, le nom repasse en clair au début de la connexion chiffrée. C’est le SNI, l’étiquette qui dit au serveur quel site tu demandes.

L’IETF, qui écrit les normes d’Internet, le reconnaît elle-même. La RFC 9849 juge ce nom en clair peut-être l’information la plus sensible que TLS 1.3 laisse passer. Depuis mars 2026, elle standardise le remède : ECH. Ce mécanisme chiffre le nom quand le site et le navigateur le prennent en charge.

Le contenu des pages HTTPS, lui, n’a jamais été lisible sur ta ligne. Ni sans protection, ni derrière un proxy, ni avec le VPN. Or le web est massivement chiffré. Selon le Web Almanac 2025, plus de 98,8 % des requêtes passent en HTTPS sur mobile.

Le proxy HTTP ne change presque rien pour ton FAI. Il ne voit plus de requête DNS pour le site, puisque le proxy s’en charge. Mais il lit le nom dans la demande CONNECT, puis dans le SNI. Et une page en HTTP simple lui arrive en entier, adresse et texte compris.

Avec le SOCKS5, même constat. Le nom du site voyage en clair dans la requête SOCKS, puis dans le SNI. La page HTTP passe, elle aussi, en clair.

Le proxy HTTPS et le VPN, eux, ferment la porte. Ton FAI ne voit plus qu’une connexion chiffrée vers le proxy, ou un échange WireGuard avec le serveur VPN. Il sait donc que tu utilises un proxy ou un VPN, et lequel. Mais il ne sait plus quels sites tu visites.

Firefox fait exception. Chez lui, un proxy HTTPS se règle par extension ou par fichier de configuration automatique (PAC). Réglé par fichier PAC, il a quand même demandé au résolveur du FAI un enregistrement DNS du site.

L’intermédiaire connaît ta vraie IP et chaque site visité

Passer par un intermédiaire ne supprime pas l’observateur : il change de place. Les journaux de Squid et de Dante ont noté ta vraie IP, 203.0.113.10, à chaque connexion. Squid a aussi noté chaque site demandé, et l’adresse complète des pages HTTP. Sur le fil, le proxy lit les mêmes noms que ton FAI, et la page HTTP en entier.

Le « VPN » intégré à Firefox en donne un bon exemple, car il fonctionne en réalité comme un proxy. Lancé en bêta en mars 2026, notamment en France, il fait transiter ta navigation par les serveurs de Fastly. Mozilla le dit sans détour dans son annonce. « Le fournisseur du proxy peut voir le domaine visé, l’heure et le volume des connexions » (notre traduction).

Le contenu des pages HTTPS, en revanche, est resté hors de portée de Squid comme de Dante. Le serveur proxy relaie un tunnel qu’il ne sait pas ouvrir.

Il existe une exception : le proxy d’entreprise qui déchiffre le HTTPS. Il présente à ton navigateur un faux certificat, signé par une autorité que ton employeur a installée sur ton poste. L’ANSSI note que ces dispositifs détournent TLS du modèle pour lequel il a été conçu. Et la CNIL demande que les salariés en soient informés.

Reste à savoir qui tient le proxy. En 2018, des chercheurs ont collecté 65 871 proxys HTTP ouverts et gratuits. Sur les 19 473 qui fonctionnaient, 38 % modifiaient le contenu des pages HTTP au passage. Et 5 % le faisaient dans un but malveillant : publicité injectée, pistage ou redirection vers un logiciel malveillant.

Derrière un proxy, le site peut encore apprendre ta vraie IP

Le site, lui, voit d’abord l’adresse du serveur proxy. Dans le labo, c’était vrai pour chaque page et dans les trois modes. Mais deux canaux ont quand même livré ta vraie IP.

Le premier est un simple en-tête. Réglé d’usine, notre Squid 6.14 ajoute ta vraie IP à chaque page HTTP qu’il transmet, dans l’en-tête X-Forwarded-For. Sa documentation l’assume : c’est le réglage par défaut. Le site du labo l’a reçue, avec la signature du proxy dans l’en-tête Via. Ce canal reste fermé pour les pages HTTPS, que le proxy ne peut pas modifier. Et Dante, en SOCKS5, n’ajoute rien.

Le second canal est plus sournois : WebRTC. Pour préparer un appel vidéo, le navigateur demande son adresse publique à un serveur STUN. Il le fait en UDP, directement, sans passer par le proxy. La documentation de Chromium le précise : en SOCKS5, Chrome ne relaie que les requêtes TCP, jamais l’UDP.

Notre page WebRTC a interrogé un serveur STUN tiers, puis envoyé le résultat au site. Avec Chromium, derrière les trois proxys, la réponse était la même : 203.0.113.10, ta vraie IP. Firefox l’a livrée lui aussi derrière les proxys HTTP et HTTPS. Derrière le SOCKS5, en revanche, il n’a lancé aucune requête STUN. La page n’a même pas demandé l’accès à la caméra. Seule ton adresse locale est restée masquée, derrière un nom aléatoire en « .local ».

Derrière les proxys, à chaque requête STUN, le nom du serveur est aussi passé par le résolveur de ton FAI. Avec le VPN, la même page n’a trouvé que l’adresse du serveur VPN. L’UDP emprunte le tunnel, comme le reste.

Mozilla a d’ailleurs buté sur le même piège. Jusqu’à Firefox 150, sorti le 21 avril 2026, WebRTC pouvait exposer la vraie IP malgré le VPN intégré. Le correctif oblige WebRTC à passer par le proxy pendant la session.

Tu peux appliquer la même règle à ton propre proxy. Dans Firefox, ouvre about:config et passe media.peerconnection.ice.proxy_only_if_behind_proxy à true. La préférence est à false d’usine. Dans Chrome, c’est la règle WebRtcIPHandling, avec la valeur disable_non_proxied_udp. Sous Windows, c’est une valeur de chaîne à créer dans le registre, sous HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome. Edge a son équivalent, WebRtcLocalhostIpHandling, qui accepte la même valeur.

On a testé les deux réglages dans le labo. La règle apparaît appliquée dans chrome://policy, et la préférence de Firefox fait le même effet. Plus aucune requête STUN ne part, et la page n’envoie plus aucune adresse au site. La contrepartie : sans serveur relais joignable par le proxy, un appel vidéo peut ne plus se connecter.

SOCKS5 : le DNS distant ne cache pas le nom du site

La fuite DNS revient souvent dans les comparatifs. Elle concerne surtout le SOCKS5, où le nom du site peut se résoudre de deux façons. Soit ton PC le demande au résolveur de ton FAI, puis donne une adresse IP au proxy. Soit il transmet le nom tel quel, et le proxy le résout lui-même.

Chromium choisit toujours la seconde option en SOCKS5, et la première en SOCKS4. Firefox fait de même par défaut. La case qui le règle, « Utiliser un DNS distant lorsque SOCKS v5 est actif », est cochée d’usine.

On a mesuré l’écart avec curl, qui propose les deux modes. En DNS local, le résolveur du FAI a noté « site.test ». En DNS distant, il n’a rien noté du tout. Mais sur ta ligne, le nom passe en clair dans les deux cas. En DNS distant, il figure même deux fois : dans la requête SOCKS et dans le SNI.

Le DNS distant sert donc surtout à éviter le résolveur de ton FAI : ses journaux, et ses blocages. Pour contourner un blocage par DNS, changer de DNS suffit souvent.

Le VPN déplace la confiance, il ne la supprime pas

Avec le VPN, tout ce que voyait ton FAI passe chez le fournisseur du VPN. Dans le tunnel, notre serveur a lu les requêtes DNS, les noms de sites et la page HTTP en entier. Il connaît aussi ta vraie IP : c’est l’adresse d’où part le tunnel.

L’EFF, l’association américaine de défense des libertés numériques, résumait l’enjeu dès 2017. Utiliser un VPN, c’est confier toute ton activité à son fournisseur. « Les VPN peuvent voir, modifier et enregistrer ton trafic Internet », prévenait-elle (notre traduction).

Le contenu des pages HTTPS reste pourtant illisible pour le VPN, comme pour le proxy. Le chiffrement du site court de ton navigateur jusqu’au serveur du site, quel que soit le tuyau emprunté.

Choisir un VPN, c’est donc choisir à qui tu confies ta navigation. Une politique « no-log » vérifiée par un audit indépendant vaut mieux qu’une promesse. C’est le premier critère pour comparer les VPN de 2026.

Proxy ou VPN : lequel choisir selon ton usage

Le choix entre serveur proxy et VPN dépend de ce que tu veux cacher, et à qui.

Le proxy HTTP simple ne protège rien face à ton FAI ou à un Wi-Fi public. Le proxy HTTPS fait presque jeu égal avec le VPN pour ta navigation. Mais il laisse dehors tes autres logiciels, et il faut brider WebRTC. Le VPN couvre tout, WebRTC compris, à condition de faire confiance à son fournisseur.

Teste ta configuration en cinq minutes

Ces vérifications valent pour un proxy comme pour un VPN. Fais-les à chaque nouveau réglage.

Un proxy ou un VPN ne règle qu’une partie du problème. Tes comptes, tes cookies et ton navigateur t’identifient aussi, et ta sécurité en ligne se joue sur tous ces fronts.