VPN et proxy ont un point commun : les deux font transiter votre trafic par un serveur intermédiaire avant qu'il n'atteigne sa destination. C'est à peu près là que s'arrête la ressemblance. La différence réelle se joue sur trois plans que la plupart des articles survolent : ce qui est réellement chiffré, ce qui échappe encore au réseau local même quand l'un des deux est actif, et la portée de la protection sur votre appareil.
Un proxy HTTP relaie uniquement le trafic web (HTTP/HTTPS) et doit être configuré application par application - typiquement dans les réglages du navigateur. Il ne comprend et ne relaie que ce protocole : impossible de l'utiliser pour du trafic de jeu, de messagerie ou de torrent.
Un proxy SOCKS5 est plus polyvalent : il relaie n'importe quel trafic TCP ou UDP sans en interpréter le contenu, ce qui le rend plus rapide et compatible avec des usages comme le P2P. Mais il ne chiffre rien par lui-même : il change l'adresse IP visible, sans plus.
Il existe aussi trois niveaux d'anonymat de proxy à connaître : transparent (transmet votre IP réelle dans un en-tête, ne cache rien), anonyme (cache votre IP mais signale qu'un proxy est utilisé), et élite/high-anonymity (ne révèle ni votre IP ni l'utilisation d'un proxy). La plupart des proxys gratuits trouvés en ligne sont transparents ou anonymes seulement.
Sources : IETF, RFC 1928 - SOCKS Protocol Version 5 ; RFC 7239 - Forwarded HTTP Extension (standardisation de l'en-tête X-Forwarded-For utilisé par les proxys transparents).
Un VPN encapsule et chiffre l'intégralité du trafic réseau de l'appareil avant de l'envoyer au serveur VPN, quel que soit le protocole ou l'application d'origine. Cette différence d'échelle - application unique contre système entier - est la raison pour laquelle un VPN reste actif même quand vous changez d'application, alors qu'un proxy configuré dans un navigateur ne protège que ce navigateur. Le protocole exact utilisé pour ce tunnel (IPSec, WireGuard, SSL...) est détaillé sur notre page protocoles VPN.
Un malentendu fréquent : « le site que je visite est en HTTPS, donc le proxy ne voit rien ». C'est partiellement vrai. Le contenu de la page reste chiffré de bout en bout par HTTPS, même via un proxy. Mais deux choses restent visibles à l'opérateur du proxy (et potentiellement à quiconque surveille son trafic) :
Le nom de domaine visité, transmis en clair lors de la négociation TLS via le champ SNI (Server Name Indication) - une extension à part entière de TLS, pas un défaut de conception. Une contre-mesure existe (le chiffrement du SNI via l'extension « Encrypted Client Hello »), mais elle est encore en cours de standardisation à l'IETF et son support reste inégal côté navigateurs et serveurs.
La totalité du trafic si le site visité n'est pas en HTTPS : dans ce cas, un proxy HTTP peut lire et modifier les données en clair, exactement comme le ferait n'importe quel intermédiaire non chiffré.
Un VPN, en chiffrant tout le tunnel jusqu'à son propre serveur, masque ces métadonnées à votre réseau local et à votre fournisseur d'accès. Le fournisseur VPN, lui, reste en position de les voir - d'où l'importance d'une politique de logs sérieuse, abordée dans notre page sur la protection de la vie privée.
Source : IETF, RFC 6066 - TLS Extensions (définition du SNI) ; draft IETF TLS Encrypted Client Hello (non finalisé à ce jour).
C'est le point que la plupart des comparatifs VPN/proxy oublient. Quand un proxy est configuré uniquement dans le navigateur, les requêtes DNS (qui traduisent un nom de domaine en adresse IP) ne passent souvent pas par ce proxy : elles continuent d'être envoyées en clair au serveur DNS de votre fournisseur d'accès. Résultat, votre FAI peut reconstituer la liste des sites visités même pendant que vous « utilisez un proxy ».
Un VPN correctement configuré route également les requêtes DNS à travers son tunnel chiffré, ce qui évite cette fuite - à condition de vérifier que le client VPN dispose bien d'une protection anti-fuite DNS active. Précision importante : contrairement au SNI ou à SOCKS5, la fuite DNS n'est pas un défaut prévu par une norme, c'est un comportement d'implémentation - certains clients la corrigent, d'autres non. Un test DNS leak en ligne (par exemple dnsleaktest.com) permet de vérifier concrètement ce qui fuite ou non, quelle que soit la solution utilisée.
| Critère | VPN | Proxy HTTP | Proxy SOCKS5 |
|---|---|---|---|
| Chiffrement | Oui, tout le tunnel | Non (repose sur le HTTPS du site visité) | Non |
| Portée | Tout l'appareil, toutes les applications | Trafic web du navigateur configuré | Toute application configurée pour l'utiliser |
| Protection DNS | Oui, si le client inclut une protection anti-fuite DNS | Non, en général | Non, en général |
| Vitesse | Légèrement réduite (chiffrement) | Rapide | Rapide |
| Idéal pour | Protection durable et complète | Contournement ponctuel d'un blocage web | Trafic P2P/torrent où la vitesse prime |
| Situation | Solution recommandée |
|---|---|
| Débloquer une page web ponctuellement | Un proxy web suffit généralement |
| Wi-Fi public ou déplacement fréquent | VPN indispensable (chiffrement complet + protection DNS) |
| Torrent / P2P où la vitesse compte | SOCKS5 pour la vitesse, idéalement combiné à un VPN pour la confidentialité |
| Télétravail / accès aux ressources de l'entreprise | VPN (voir les protocoles adaptés à l'entreprise) |
| Confidentialité renforcée (journalisme, données sensibles) | VPN avec politique no-log vérifiée, jamais un simple proxy |
De plus, en protégeant l'adresse IP, vous pouvez contourner les restrictions régionales.
