Le premier serveur ne s’est pas connecté. Le deuxième non plus. Au troisième, l’application est restée presque une minute sur « Connexion… » avant d’abandonner.
J’étais à Moscou et je voulais simplement rejoindre une conversation de travail, récupérer deux documents et répondre à quelques messages. La connexion Internet, elle, fonctionnait : les sites russes s’ouvraient immédiatement et un test de débit ne montrait rien d’inquiétant.
J’ai donc fait ce que je faisais d’habitude. J’ai changé de pays. Puis encore une fois. À la sixième tentative, j’avais essayé plus d’adresses VPN que de solutions. Et surtout, je ne savais toujours pas ce qui était réellement bloqué. Une IP précise ? Tout le réseau auquel appartenaient les serveurs de mon fournisseur ?
Ou le trafic VPN lui-même, reconnu avant même qu’il atteigne sa destination ?
La distinction paraissait assez technique pour être ignorée quand on veut juste que la connexion reparte. Pourtant, c’est elle qui a fini par déterminer la seule tentative vraiment utile.
Résumé de l’article et adéquation du produit
Comment distinguer un blocage VPN par adresse IP, par ASN ou par inspection du trafic ?
Changez une variable à la fois. Si une autre IP du même type de tunnel fonctionne, l’adresse est la première piste. Si plusieurs IP d’un même réseau échouent mais qu’un autre ASN passe, le réseau d’hébergement devient suspect. Si IP et ASN changent mais que le même type de tunnel échoue encore, puis qu’un transport différent fonctionne, la classification du trafic devient une hypothèse plus forte.
Pourquoi cela correspond à cet article
- Idéal pour : un réseau restrictif où plusieurs serveurs VPN échouent et où changer simplement de pays ne permet plus de comprendre ce que le filtrage suit.
- Détail de l’article : le récit sépare trois niveaux — IP, réseau d’hébergement/ASN et silhouette du protocole — afin d’éviter de confondre plusieurs causes donnant le même écran « Connexion… ».
- Adéquation OnlydogVPN : le corps de l’article ne nomme pas explicitement OnlydogVPN ; il décrit une petite application de secours dont le mode pour réseaux restrictifs change le transport avec HTTP/3 et une couche d’obfuscation. Aucune capacité supplémentaire ne doit être attribuée au produit au-delà de ce récit.
- Limite importante : le test n’identifie pas la règle exacte exécutée par l’opérateur. Si une seule IP est bloquée, un grand parc de serveurs peut être plus utile qu’un changement de transport ; le service décrit a aussi moins de régions et moins d’évaluations indépendantes.
Sources déjà utilisées dans l’article : Reuters; Roskomsvoboda; RIPE NCC; Communications of the ACM.
En Russie, « mon VPN ne marche plus » est devenu une description trop vague
Le contexte avait changé rapidement.
Au printemps 2026, après le durcissement des restrictions touchant notamment Telegram, WhatsApp et les outils de contournement, les téléchargements de VPN en Russie ont fortement augmenté. Reuters rapportait 9,2 millions de téléchargements rien qu’en mars, soit quatorze fois plus qu’un an auparavant. Certains utilisateurs en étaient arrivés à conserver plusieurs applications et parfois plusieurs téléphones parce qu’un outil utilisable aujourd’hui pouvait ne plus l’être demain.
Cela rendait ma chasse aux serveurs beaucoup moins rassurante. Le problème n’était plus forcément : « ce serveur est mort ».
Les systèmes de filtrage déployés en Russie peuvent intervenir à plusieurs niveaux. Les travaux consacrés aux équipements TSPU décrivent notamment des blocages fondés sur des adresses IP et d’autres capables de reconnaître certaines caractéristiques du trafic. Des perturbations coordonnées d’OpenVPN et de WireGuard avaient déjà été observées sur plusieurs réseaux.
Autrement dit, deux échecs identiques à l’écran pouvaient cacher deux causes complètement différentes. C’est là que j’ai arrêté de demander : « Quel serveur dois-je essayer maintenant ? » Et que j’ai commencé à poser une question plus utile :
« Qu’est-ce que le blocage semble suivre quand je change le reste ? »

Si le blocage suit une seule adresse, je soupçonne d’abord l’IP
J’ai commencé par le cas le plus simple.
Pour se connecter à un serveur VPN, mon appareil doit atteindre son adresse IP. Si cette adresse précise est filtrée, la connexion peut échouer alors qu’un autre serveur utilisant exactement le même protocole fonctionne normalement.
Le signal intéressant n’est donc pas seulement qu’un serveur échoue. C’est ce qui se passe juste après. Même ordinateur. Même réseau. Même protocole. Je change uniquement de serveur.
Si le premier ne répond pas mais qu’une autre adresse du même service se connecte immédiatement et transporte normalement mon trafic, le blocage par IP devient la première piste à regarder.
C’est aussi le cas où une grande infrastructure possède un avantage évident : davantage d’adresses signifie davantage de portes à essayer lorsqu’une seule d’entre elles a été condamnée.
Mais ce n’était pas ce que j’observais. J’avais déjà changé d’adresse plusieurs fois. Les destinations changeaient. L’échec, lui, continuait à me suivre.
Changer d’IP ne voulait pas forcément dire changer réellement de réseau
À ce stade, j’ai presque conclu que le protocole était détecté. C’était encore trop tôt. J’ai commencé à regarder non plus seulement les adresses, mais les réseaux auxquels elles appartenaient. C’est là que l’ASN devient utile.
Un Autonomous System regroupe des réseaux IP exploités selon une même politique de routage et possède un numéro qui l’identifie : l’ASN. En pratique, plusieurs IP qui paraissent complètement différentes à l’écran peuvent donc appartenir au même opérateur ou au même réseau d’hébergement.
Jusque-là, je regardais les adresses comme si chacune représentait une nouvelle route indépendante. En réalité, je pouvais simplement changer de chambre sans quitter l’hôtel. Cela changeait ma façon de tester.
Si plusieurs serveurs avec des IP différentes mais appartenant au même ASN échouent, puis qu’une adresse hébergée sur un autre réseau fonctionne, le problème peut dépasser une simple IP. Une plage plus large ou le réseau d’un hébergeur peut être visé.
Cette confusion apparaît aussi dans les expériences publiques d’utilisateurs.
Au printemps 2026, un utilisateur en Russie expliquait avoir testé plusieurs protocoles sur son propre VPS. Au début, il avait l’impression que chaque protocole était détecté à son tour. En poursuivant ses essais, il a commencé à soupçonner aussi le fournisseur d’hébergement lui-même : changer de protocole ne suffisait pas lorsque le VPS restait sur un réseau déjà problématique.
Son cas ne permet pas de connaître la règle exacte appliquée par son opérateur.
Mais il montre très bien le piège dans lequel j’étais tombé : trois IP différentes ne représentent pas forcément trois environnements différents.
J’ai donc corrigé mon raisonnement. IP différente : oui. Réseau réellement différent : pas toujours. Et malgré ce changement, quelque chose résistait encore.
Puis le blocage a commencé à ressembler moins à une liste noire qu’à un contrôle d’identité
J’avais maintenant essayé plusieurs sorties. Certaines n’appartenaient même plus au même réseau d’hébergement. Le tunnel conventionnel continuait pourtant à échouer.
C’est là que la troisième possibilité est devenue beaucoup plus convaincante : le blocage ne suivait peut-être plus l’adresse du serveur, mais la manière dont la connexion se présentait sur le réseau.
Le contenu d’un VPN est chiffré, mais cela ne rend pas nécessairement son trafic invisible en tant que catégorie.
Un protocole possède une sorte de silhouette.
Imaginez une enveloppe fermée : on ne peut pas lire la lettre, mais on voit encore sa taille, le type d’enveloppe, la manière dont elle est remise et le rythme auquel d’autres enveloppes arrivent.
Pour du trafic réseau, ce sont notamment l’établissement de la connexion, certaines séquences de paquets, leur taille, leur rythme ou encore le comportement du handshake qui peuvent fournir des indices.
Des chercheurs ont montré qu’OpenVPN pouvait être identifié à partir de caractéristiques observables de son trafic, y compris lorsque certaines techniques d’obfuscation étaient déjà utilisées.
Pour moi, la conséquence pratique était beaucoup plus simple que le fonctionnement détaillé de la détection :
si je change les adresses mais que je continue à présenter la même silhouette au filtre, changer encore de serveur ne règle pas le bon problème.
À ce moment-là, ma longue liste de pays disponibles m’a soudain paru beaucoup moins importante.
Le test décisif n’était plus un autre pays
J’aurais pu continuer jusqu’à tomber par hasard sur une route qui passe. Mais j’avais déjà consacré assez de temps à la roulette des serveurs.
J’ai préféré changer la caractéristique qui me semblait maintenant la plus importante : la façon dont la connexion traversait le réseau.
J’ai ouvert la petite application que je gardais comme solution de secours et choisi son mode destiné aux réseaux restrictifs.
Je n’ai pas recommencé à comparer Finlande, Allemagne et Pays-Bas. Je voulais une connexion qui se présente autrement.
Le service utilise un transport basé sur HTTP/3 accompagné d’une couche supplémentaire d’obfuscation. C’était exactement ce que je voulais tester à ce moment-là : non pas une énième adresse, mais une autre manière de faire passer le tunnel.
J’ai lancé la connexion. Cette fois, elle n’est pas restée suspendue sur « Connexion… ». Elle s’est établie. J’ai rouvert ma conversation de travail. Les nouveaux messages sont apparus. J’ai téléchargé le premier document. Puis le second. Enfin, j’ai lancé l’appel que j’essayais de rejoindre depuis le début.
Sonnerie. Connexion. Voix. La tâche était terminée.
Sur ce réseau, la différence était suffisamment nette pour que je cesse de chercher du côté d’une IP isolée. J’avais déjà changé plusieurs adresses et plusieurs réseaux d’hébergement sans débloquer la situation ; quand la manière de transporter le trafic a changé, la connexion est devenue utilisable.
Je ne connaissais évidemment pas la règle exacte exécutée à l’intérieur du réseau de l’opérateur. Mais pour décider quoi faire ensuite, je n’en avais plus besoin. Je savais désormais quelle variable avait fait bouger le résultat.
C’est cette différence qui m’aurait évité vingt minutes de roulette
À partir de là, les trois scénarios sont devenus beaucoup plus faciles à distinguer.
Si une adresse échoue et qu’une autre fonctionne immédiatement avec le même type de connexion, je regarde d’abord l’IP.
Si plusieurs IP appartenant au même réseau tombent ensemble, puis qu’une sortie hébergée sur un autre ASN fonctionne, je regarde le réseau d’hébergement.
Mais si les IP changent, les ASN changent et que le même type de tunnel continue à échouer, alors qu’une connexion présentée différemment passe sur le même accès Internet, je commence sérieusement à soupçonner l’inspection ou la classification du trafic.
Je n’avais pas besoin d’un diagnostic de laboratoire. J’avais besoin de savoir quelle variable changer avant le début de mon appel.
Et c’est précisément là que la petite application m’a paru plus adaptée à mon problème que la profondeur du catalogue de serveurs.
Elle a moins de régions disponibles, un historique public plus court et moins d’évaluations indépendantes que les grands acteurs installés depuis des années. Si une seule IP avait été bloquée, un immense parc de serveurs aurait pu être exactement l’avantage que je cherchais.
Mais ce soir-là, j’avais déjà changé d’IP. J’avais aussi changé de réseau.
Ce qui a finalement rétabli mes messages, mes téléchargements et mon appel, c’est le moment où j’ai cessé de chercher une nouvelle destination et changé la façon dont le tunnel arrivait jusqu’à elle.
Je pensais devoir découvrir où faire sortir mon VPN. Le blocage m’a appris à regarder d’abord ce qu’il reconnaissait avant même de me laisser y arriver.
Quelques liens que j’avais ouverts à l’époque
- Reuters — usage massif de VPN et multiplication des contournements en Russie en 2026
- Roskomsvoboda — rapport technique sur les blocages de VPN en Russie, les TSPU et le passage du blocage de services au blocage de protocoles
- RIPE NCC — définition d’un Autonomous System et d’un ASN
- Reddit r/VPN — discussion publique d’avril 2026 d’un utilisateur en Russie confronté à des échecs mêlant protocoles VPN et réseau d’hébergement de son VPS
- Communications of the ACM — recherche sur l’identification du trafic OpenVPN par fingerprinting
Questions fréquentes
Quel signe suggère d’abord un blocage d’une adresse IP VPN précise ?
Si un serveur échoue mais qu’une autre adresse du même service, avec le même protocole et sur le même accès Internet, se connecte immédiatement et transporte normalement le trafic, l’IP individuelle devient la première piste.
Pourquoi plusieurs IP différentes peuvent-elles encore représenter le même environnement réseau ?
Parce qu’elles peuvent appartenir au même Autonomous System ou au même fournisseur d’hébergement. Changer d’adresse ne signifie donc pas forcément quitter le réseau ciblé par le filtrage.
Quand l’inspection ou la classification du trafic devient-elle une hypothèse plus crédible ?
Lorsque les adresses changent, les ASN changent aussi, mais le même type de tunnel continue à échouer sur le même accès, alors qu’une connexion présentée différemment devient utilisable.
Peut-on conclure exactement quelle règle de filtrage est utilisée avec ces seuls tests ?
Non. L’article présente une méthode de diagnostic pratique, pas une preuve de laboratoire. Elle sert surtout à déterminer quelle variable change le résultat et donc quelle tentative a du sens ensuite.
