Un VPN qui fonctionnait hier et échoue aujourd'hui n'a presque jamais été piraté. Il a été fingerprinté. L'inspection approfondie des paquets (DPI) est l'outil de censure par défaut en Chine, en Iran et en Russie en 2026, et elle n'a pas besoin de déchiffrer quoi que ce soit pour vous arrêter — il lui suffit de reconnaître la forme de votre trafic, ou l'adresse à laquelle vous l'envoyez.
Cette distinction détermine la solution. Si le censeur a bloqué votre protocole, un autre serveur ne change rien. S'il a bloqué l'IP, un autre protocole ne change rien. Sur un VPN commercial, vous êtes généralement touché par les deux à la fois, car des milliers de clients partagent une même plage d'adresses et une même signature de handshake. Votre propre point d'accès est le seul montage où vous contrôlez les deux. Ce guide couvre ce que le DPI détecte, lequel des cinq protocoles encore efficaces en 2026 répond à quel type de blocage, et comment en déployer un.
Ce que l'inspection approfondie des paquets voit réellement
L'inspection approfondie des paquets (DPI) est un nom trompeur. Un censeur moderne ne lit pas votre session chiffrée — il ne le peut pas. Il classe la session à partir de ce qui reste visible quand la charge utile ne l'est pas : taille des paquets, intervalles entre les paquets, motif d'octets du handshake d'ouverture, adresse et port de destination, et comportement de la connexion lorsqu'on la sonde.
Quatre techniques font le travail, et chacune échoue face à une contre-mesure différente. Savoir laquelle vous a touché constitue à elle seule le diagnostic :
- Le fingerprinting de protocole. Chaque protocole VPN a un handshake d'ouverture reconnaissable. Le premier paquet d'OpenVPN porte un opcode fixe ; celui de WireGuard est un message de 148-byte avec un champ de type constant à une position prévisible. Un classificateur repère l'un ou l'autre en un seul paquet, sans rien déchiffrer.
- Le sondage actif. La botte secrète du Great Firewall. Après avoir repéré une session suspecte, le censeur se connecte ensuite lui-même à cette adresse et lui parle un protocole de proxy. Si le serveur répond comme un proxy, il est bloqué — ressembler à du TLS ne suffit donc pas, le serveur doit survivre à l'interrogatoire.
- Le blocage d'IP et de plages. La méthode la plus grossière et de loin la plus répandue. Les plages connues pour héberger des VPN commerciaux sont bloquées en bloc, sans aucune inspection. C'est ce qui tue une appli VPN grand public du jour au lendemain.
- La limitation de débit plutôt que le blocage. La méthode privilégiée de l'Iran. La connexion n'est pas coupée mais dégradée jusqu'à devenir inutilisable — perte et latence induites qui cassent le contrôle de congestion TCP. Rien n'a l'air bloqué, si bien que les utilisateurs blâment leur propre matériel.

Pourquoi votre propre point d'accès VPS survit à une vague de blocage
Les VPN commerciaux échouent dans les pays censurés pour une raison structurelle qu'aucune ingénierie ne corrige : ils sont publics. Leurs plages d'adresses sont publiées, scrapées et recensées. N'importe qui peut acheter un abonnement, noter les adresses de sortie et les soumettre — et c'est exactement ce que font les censeurs. Une seule entrée de liste noire prive d'un coup des milliers d'utilisateurs de leur accès.
Un proxy sur votre propre VPS inverse ce rapport de force. Votre point d'accès est une adresse unique et inconnue, sur aucune liste jusqu'à ce que quelqu'un la trouve, et la trouver suppose de fingerprinter votre protocole ou de déjà savoir où chercher. Vous gagnez aussi ce qu'aucun abonnement n'offre : le root. Vous choisissez le protocole, le port, l'obfuscation et le domaine de camouflage, et pouvez en faire tourner plusieurs à la fois.
Le compromis honnête, c'est que vous devenez l'opérateur. Personne ne fait tourner l'adresse à votre place, ne patche la machine, ni ne remarque à 3h du matin que le daemon est mort. Si vous voulez une appli et un support client, ce n'est pas la bonne architecture — les pages hébergement résistant à la censure énoncent le même compromis du point de vue produit. Ce que vous obtenez à la place, c'est un point d'accès dont le sort n'est pas partagé avec des inconnus.
Pourquoi WireGuard et OpenVPN classiques se font repérer par le DPI
Les deux sont d'excellents protocoles, et tous deux sont, par conception, triviaux à identifier. WireGuard a été optimisé pour la simplicité cryptographique et la vitesse, pas pour la dissimulation : l'initiation de son handshake est un message de longueur fixe avec un octet de type constant. OpenVPN, dans sa configuration par défaut, est tout aussi caractéristique. Aucun des deux n'a été conçu pour être méconnaissable — ce n'était tout simplement pas un objectif de conception.
Cela n'en fait pas de mauvais choix, comme le dit clairement notre comparatif WireGuard contre OpenVPN. Pour la confidentialité vis-à-vis de votre FAI, pour relier vos propres machines, pour un VPN dans un pays qui ne pratique pas le DPI, WireGuard reste la bonne réponse et notre guide d'installation de WireGuard tient toujours. Pour le dire crûment : WireGuard résout la confidentialité ; il ne résout pas la censure.
Des couches d'obfuscation existent pour les deux — des wrappers pour OpenVPN, des forks qui rendent aléatoire le handshake de WireGuard. Elles fonctionnent, et face à un censeur qui se contente de fingerprinter, elles peuvent suffire. Elles sont plus faibles là où le sondage actif entre en jeu, car brouiller un handshake n'apprend pas à un serveur à se comporter de façon convaincante quand un censeur se connecte et lui pose des questions. C'est précisément pour cela que les cinq protocoles suivants ont été conçus.
Les cinq protocoles encore efficaces en 2026
Il n'existe pas un protocole meilleur que tous les autres — seulement le meilleur pour la méthode de blocage à laquelle vous faites face et le réseau sur lequel vous êtes. Ces cinq-là méritent d'être déployés dès aujourd'hui, chacun avec sa propre page d'installation.
| Protocole | Comment il se dissimule | Port | RAM | Le plus adapté pour |
|---|---|---|---|---|
| VLESS + REALITY | Emprunte le handshake TLS 1.3 d'un site réel — pas de certificat, pas de domaine propre | 443 TCP | ~50 MB | Chine, Iran, Russie — le choix par défaut en 2026 |
| Shadowsocks-2022 | Chiffrement AEAD-2022 ; résiste au sondage actif et au replay | TCP/UDP élevé, au choix | ~30 MB | Chine ; appareils peu puissants et anciens |
| Hysteria2 | QUIC/UDP avec obfuscation Salamander ; ressemble à du HTTP/3 ordinaire | 443 UDP | ~40 MB | Liens limités en débit et instables — notamment mobile iranien |
| V2Ray / VMess | WebSocket sur TLS, façadable derrière un CDN pour que l'origine n'apparaisse jamais | 443 via WS+TLS | ~60 MB | Masquer l'IP d'origine ; configurations VMess existantes |
| MTProto | Secret fake-TLS ; imite un site HTTPS ordinaire | 443 TCP | ~20 MB | Telegram spécifiquement, en Iran et en Russie |
VLESS+REALITY est celui vers lequel se tourner en premier. Son astuce diffère du camouflage TLS classique : plutôt que de présenter son propre certificat, il relaie le véritable handshake TLS d'un site populaire authentique. Un sondage actif voit une chaîne de certificats authentique pour un domaine réel, parce que c'est précisément ce qu'on lui montre. Aucun certificat auto-signé à signaler, aucun domaine obscur à corréler.
Shadowsocks-2022 est le plus léger et le plus éprouvé ; sa suite de chiffrement a comblé les faiblesses face au replay et au sondage qui rendaient les versions précédentes détectables. Hysteria2 répond à la limitation de débit plutôt qu'au blocage — son contrôle de congestion est conçu pour des liens délibérément instables. V2Ray derrière un CDN masque l'origine : le censeur voit du trafic vers un grand CDN, pas vers vous. Un proxy MTProto résout exactement un seul problème, mais résout l'accès à Telegram si proprement qu'il vaut la peine de le faire tourner en parallèle de tout ce que vous déployez par ailleurs.
Choisir la juridiction et l'IP
Deux propriétés comptent et elles s'opposent l'une à l'autre : la fraîcheur de la plage d'adresses, et la distance du serveur par rapport à vous. La fraîcheur l'emporte généralement. Une adresse neuve sur une plage jamais utilisée pour le contournement passe le blocage en bloc qui arrête la plupart des gens, et aucune sophistication de protocole ne rattrape une adresse déjà listée. C'est pour cela que les adresses « VPN anonyme » recyclées cessent de fonctionner — elles étaient déjà grillées avant que vous ne les louiez.
La latence compte en second lieu. Parmi les sept juridictions où nous opérons, les Pays-Bas, la Roumanie et la Moldavie sont les plus proches des utilisateurs en Iran, en Russie et en Asie centrale, et les Pays-Bas offrent en plus un peering de classe mondiale via AMS-IX. L'Islande, le Panama et la Suisse sont plus éloignés mais juridiquement plus solides — le Panama n'a pas de traité d'entraide judiciaire avec la plupart des pays occidentaux, ni d'obligation de conservation des données, et l'Islande n'a aucune conservation obligatoire.
Pour un point d'accès de contournement, le conseil n'a rien de romantique : privilégiez la latence et la fraîcheur de la plage en premier, la juridiction en second. Vous déplacez votre propre trafic, vous n'hébergez pas de contenu qui attire les retraits, donc le profil juridique compte moins ici que pour de la publication. Comparez les sept sur la page des localisations, ou explorez les compromis avec le sélecteur de juridiction et notre guide des juridictions. Chaque serveur est livré avec une IPv4 dédiée qui n'appartient qu'à vous — une adresse partagée irait à l'encontre du but recherché.
Payer le serveur depuis un pays censuré
C'est là que la plupart des guides cessent discrètement d'être utiles, car c'est l'étape qui échoue réellement. En Iran ou en Russie, les processeurs de carte vous refusent pour motif de sanctions avant même que l'hébergeur ne voie la commande, et les fournisseurs grand public exigent des documents d'identité que vous avez peut-être de bonnes raisons de ne pas transmettre. Un guide technique ne vaut rien si le paiement ne peut pas aboutir.
La crypto est le rail qui survit, et c'est pourquoi l'hébergement no-KYC et le contournement de la censure finissent par être le même produit : aucune banque sur le chemin pour refuser la transaction, aucune vérification d'identité à échouer. Nous acceptons Bitcoin, Monero, Ethereum, Litecoin, TRON, Solana et Tether sur le réseau ERC-20 ou TRC-20. Monero ne laisse aucun graphe de transactions public reliant votre financement à votre serveur, et notre guide de paiement en Monero détaille la marche à suivre ; l'USDT sur TRC-20 est l'alternative pragmatique, avec des frais faibles et une liquidité régionale facile. Un petit VPS démarre à $7.50 par mois.
Déployer un point d'accès VLESS + REALITY sur votre VPS, étape par étape
Le déploiement prend environ quinze minutes sur un serveur Debian ou Ubuntu vierge. Voici sa forme générale ; la page VLESS+REALITY donne les commandes.
- Sécurisez d'abord le serveur. SSH par clé uniquement, authentification par mot de passe désactivée, un pare-feu qui n'autorise que ce que vous comptez exposer. Faites-le avant que le proxy ne soit en ligne — notre checklist de durcissement de la première heure en est la version courte, et elle compte encore plus ici que sur un serveur ordinaire.
- Installez le cœur Xray et un panneau. Le panneau 3x-ui enveloppe Xray dans une interface web et s'installe en une seule commande. Liez-le à localhost et atteignez-le via un tunnel SSH plutôt que de l'exposer — un panneau d'administration sur un port ouvert est une empreinte à lui seul.
- Créez l'inbound. Ajoutez un inbound avec le protocole VLESS et la sécurité REALITY sur le port 443. La décision qui pèse vraiment est le
SNIde camouflage : choisissez un site HTTPS populaire, accessible et non bloqué depuis l'intérieur du réseau censuré. Si votre domaine de camouflage est lui-même bloqué, votre trafic vers lui devient anormal et vous avez aggravé les choses. - Importez le lien client. Le panneau émet un lien de partage
vless://et un QR code portant la configuration complète. Importez-le dans v2rayN sous Windows, v2rayNG sous Android, Streisand ou FoXray sous iOS, ou sing-box n'importe où — aucun certificat client, aucun fichier de configuration ne contient de secret si un appareil est inspecté. - Vérifiez depuis l'extérieur. Depuis un réseau qui n'est pas le serveur, confirmez que le point d'accès répond avec un handshake TLS normal pour le SNI choisi — un
curl -sIvers l'adresse avec le SNI résolu dessus suffit. Si cela vous ressemble à un site HTTPS ordinaire, cela ressemble à la même chose pour un sondage.
Ajoutez un plan de secours avant d'en avoir besoin. Un second protocole sur un second port coûte dix minutes pendant que tout fonctionne encore, et devient pénible voire impossible depuis derrière un blocage actif. Hysteria2 sur 443 UDP est le compagnon naturel de REALITY sur 443 TCP — transport, port et mode de défaillance différents. Gardez les deux liens de partage sur vos appareils pour que la reprise soit un simple changement côté client.
Durcir la machine pour que le proxy ne soit pas la fuite
Un proxy qui fonctionne et un proxy sûr sont deux choses différentes. Le point d'accès connaît désormais chaque destination que vous visitez, et il est exposé sur un port que vous avez communiqué à vos propres appareils.
- N'exposez que ce qui doit l'être. Le port du proxy, et SSH. Panneaux, métriques et bases de données doivent rester sur localhost, accessibles via un tunnel.
- Désactivez les logs dont vous n'avez pas besoin. Xray et la plupart des daemons de proxy enregistrent chaque connexion sur disque par défaut. Sur un point d'accès de contournement, ce fichier est l'objet le plus sensible du serveur.
- Ne cohébergez pas. Résistez à la tentation de faire tourner un site personnel ou un serveur mail sur la même machine. Chaque service supplémentaire est une empreinte de plus, un certificat de plus, un moyen de plus de corréler le point d'accès avec vous.
- Administrez-le avec précaution. Atteindre le serveur en SSH depuis le réseau censuré que vous essayez de fuir relie votre adresse réelle au serveur au niveau réseau. L'OpSec serveur traite correctement cette discipline, et c'est la partie que tout le monde saute.
- Gardez-le patché et ennuyeux. Mises à jour de sécurité automatiques, rien d'exotique installé, aucune configuration de test abandonnée restée à l'écoute.
Quand l'IP est grillée
Partez du principe que ça arrivera. Un point d'accès utilisé par une seule personne prudente peut durer longtemps ; un point d'accès partagé avec quarante personnes dans un groupe de discussion, non. La réponse est mécanique : confirmez que le blocage se situe au niveau de l'adresse en testant le même protocole depuis un serveur neuf, redéployez dans une juridiction différente, réimportez le nouveau lien de partage sur vos appareils.
Comme aucune identité n'a jamais été attachée au premier serveur, rien ne relie la nouvelle adresse à l'ancienne — le bénéfice concret du no-KYC, souvent décrit comme une position idéologique mais en réalité opérationnelle. Ce qui vaut la peine de changer en même temps, c'est la discipline de partage qui a grillé l'adresse. Les adresses se répandent via des captures d'écran et des groupes de discussion, et les censeurs lisent aussi ces canaux. Si vous accompagnez d'autres personnes, donnez à chacune ses propres identifiants pour qu'un utilisateur compromis puisse être retiré sans tout reconstruire.
Huit erreurs qui font bloquer un point d'accès en une semaine
- Utiliser une plage d'adresses recyclée. Les serveurs les moins chers se trouvent souvent sur des plages qui ont porté du trafic de contournement pendant des années. La fraîcheur est la vraie propriété que vous achetez.
- Choisir un SNI de camouflage bloqué localement. REALITY ne fonctionne que si le site qu'il imite est un site vers lequel votre réseau voit passer du trafic ordinaire. Imiter quelque chose déjà censuré est pire que ne pas se camoufler du tout.
- Faire tourner le panneau de gestion sur un port public. Une page de connexion 3x-ui sur un port ouvert identifie le serveur comme un proxy pour quiconque le scanne, et scanner ne coûte rien.
- Partager un seul point d'accès avec un grand groupe. Le volume de trafic devient anormal, et l'adresse fuite par le canal utilisé pour la partager.
- Laisser des logs verbeux activés. Utile pour une soirée de débogage, un risque tous les jours suivants.
- Réutiliser une adresse après son blocage. Une fois listée, une adresse revient rarement. Redéployez plutôt que d'attendre que ça passe.
- Ne faire tourner qu'un seul protocole. Un point de défaillance unique que vous ne pouvez corriger que depuis derrière le blocage que vous essayez de fuir.
- Changer le serveur mais pas les identifiants. Conserver les mêmes clés, ports et identifiants d'un déploiement à l'autre reconstruit la corrélation que vous veniez de détruire.
Faire tourner son propre proxy est-il légal, et que consignons-nous
De notre côté, la réponse est simple. Louer un serveur et y faire tourner un proxy est légal dans les sept juridictions où nous opérons. Les logiciels de contournement sont des logiciels ordinaires, utilisés quotidiennement par des journalistes et des chercheurs. Nous ne consignons ni le trafic, ni les connexions, ni le DNS, nous n'inspectons pas les charges utiles et nous ne limitons le débit d'aucun protocole. Le VPS est une machine Linux nue avec un accès root complet ; ce qui tourne dessus et ce à quoi il se connecte est visible pour vous, pas pour nous.
La partie à laquelle nous ne pouvons pas répondre est celle qui compte le plus pour vous. Plusieurs pays qui déploient l'inspection approfondie des paquets réglementent aussi le contournement du côté de l'utilisateur, et l'exposition de la personne qui se connecte est une question de droit local qu'aucun hébergeur n'est compétent pour trancher. Nous pouvons vous dire ce qui se passe sur le serveur ; nous ne pouvons pas vous dire ce qui se passe là où vous êtes assis.
Il vaut la peine d'être tout aussi clair sur ce que cette architecture ne vous donne pas. Un proxy privé déjoue la censure — il ne vous rend pas anonyme face à un adversaire capable d'observer les deux extrémités de la connexion. Le trafic entrant et sortant de votre point d'accès peut être corrélé par la seule synchronisation temporelle, et l'adresse du serveur est connue de votre réseau. Si votre modèle de menace est un État qui vous enquête spécifiquement plutôt qu'un filtre qui bloque tout le monde sans distinction, c'est Tor et sa conception multi-sauts qu'il vous faut, pas un proxy à un seul saut. Adapter l'outil à la menace réelle, c'est toute la différence entre la confidentialité et son apparence.