Le 4 août 2026, des dizaines de services de contournement des blocages en Russie ont cessé de fonctionner presque simultanément. Les problèmes ont été confirmés par les équipes de Paper VPN, Amnezia, VPN Generator, VPN Legend, GaMMa VPN, LTVPN, ABS et FoxyBot — au total, plus de 20 services de différentes tailles ont été touchés. Le Roskomnadzor n'a pas commenté la situation officiellement, mais la nature de la panne parle d'elle-même : les services se sont effondrés non pas un par un, mais par paquets, en groupes liés à des plateformes d'hébergement spécifiques.
Ce n'est pas simplement « une autre vague de blocages ». L'objet même a changé : ce ne sont pas des protocoles ou des applications qui sont filtrés, mais l'espace d'adresses — des IP individuelles et des sous-réseaux entiers de fournisseurs d'hébergement, sur les serveurs desquels tourne l'infrastructure de contournement. Analysons ce qui a changé, pourquoi cela rend les VPN consommateurs plus efficaces que n'importe quel DPI et ce que cela implique pour ceux qui ont besoin d'un accès fonctionnel à des services externes.
Que s'est-il passé le 4 août : panne aux frontières des hébergeurs
Extérieurement, cela ressemblait à un accident ordinaire : les utilisateurs se plaignaient de l'impossibilité de se connecter ou d'une connexion extrêmement instable. Mais un accident ne peut pas être synchronisé entre huit équipes indépendantes, qui ne sont liées entre elles que par des capacités louées.
Les publications spécialisées (Anti-Malware.ru, SecurityLab) ont décrit la mécanique de la même manière : des adresses IP et des sous-réseaux entiers de grands fournisseurs d'hébergement ont été soumis à des restrictions. Si une plage d'adresses est filtrée, une multitude de connexions s'effondre également — et les services ayant loué des capacités auprès d'un même fournisseur se déconnectent en une minute, bien qu'il n'y ait techniquement rien de commun entre eux.
Les commentaires des spécialistes sont également révélateurs. L'avocat Sarkis Darbinyan a immédiatement souligné plusieurs canaux de détection : des détecteurs de VPN intégrés dans les applications russes et l'achat banal de comptes premium pour obtenir une liste à jour des serveurs du service de l'intérieur. Mikhail Klimarev a parlé de la détection de plusieurs dizaines de systèmes autonomes à travers lesquels les services de contournement fonctionnaient.
Le deuxième point mérite d'être relu. Un VPN consommateur doit fournir à son client une liste de serveurs — sinon, l'application ne pourra pas se connecter. Cela signifie que quiconque a payé un abonnement obtient une carte complète de l'infrastructure du service. Ce n'est pas du piratage ni une enquête complexe, c'est un simple achat.
Dynamique : de 197 services à 469 en un an et demi
Les blocages par listes existaient déjà auparavant, mais le rythme a considérablement augmenté. Selon le Roskomnadzor lui-même, à la fin février 2026, l'accès était limité à 469 services VPN. Pour comparaison : en octobre 2024, il y en avait 197, en octobre 2025 — 258. Cela signifie qu'en quatre mois d'hiver, la liste a presque doublé.
Parallèlement, depuis décembre 2025, les restrictions sur des protocoles spécifiques — SOCKS5, VLESS et L2TP — se sont intensifiées. Une ligne distincte — Telegram : les restrictions sont en vigueur depuis l'été 2025 et se sont considérablement renforcées en février 2026, et les plaintes concernant le téléchargement de photos et de vidéos continuent d'être enregistrées (selon Downdetector — environ 500 plaintes par jour le 20 août).
Un détail important pour ceux qui essaient de résoudre le problème par des réglages : selon les analyses de la vague d'août, le critère principal de sélection était le port standard. Si seul le port 443 est fermé, le transfert de la connexion vers un port non standard aide effectivement — mais seulement jusqu'à ce que la sélection commence à se faire non pas par le numéro de port, mais par la nature de la réponse du serveur. À ce moment-là, le déménagement ne fera que retarder le blocage.
Deuxième couche : nettoyage des « listes blanches » et nouveau rôle de l'hébergeur
Ce qui est le plus intéressant dans l'histoire d'août, ce n'est pas le blocage lui-même, mais ce qui a été discuté quelques jours avant. Le ministère des Numériques a soumis à discussion avec les fournisseurs d'hébergement un mécanisme de vérification permanente des adresses IP de la « liste blanche » du Centre de surveillance et de gestion des réseaux de communication publique — une liste d'exceptions où figurent les VPN d'entreprise légaux.
La logique du schéma discuté est la suivante :
- si au cours d'une semaine, la surveillance détecte des signes d'infrastructure VPN à l'adresse, une demande est envoyée à l'hébergeur ;
- le fournisseur a 24 heures pour confirmer la légalité de l'attribution des serveurs ;
- si le client a passé une identification minimale — juste un numéro de téléphone ou une carte bancaire — ses services peuvent être coupés dans un délai de 30 minutes ;
- si le client est vérifié via « Gosuslugi », la biométrie ou en tant que personne morale, on lui propose d'abord de retirer l'infrastructure ;
- l'hébergeur qui tolère systématiquement cela avec un faible contrôle des clients risque le statut de malhonnête — et avec cela, la restriction de sous-réseaux entiers de l'entreprise avec accès uniquement aux ressources de la « liste blanche ».
Je souligne : ce sont des propositions discutées, pas des règles en vigueur — les critères, les délais de lancement et l'ordre d'application ne sont pas approuvés. Mais la direction est claire : l'obligation de rechercher des services de contournement est transférée à l'hébergeur lui-même, et le levier est son propre espace d'adresses. Depuis février 2024, seuls les entreprises figurant dans le registre du Roskomnadzor peuvent fournir des services d'hébergement en Russie — en juillet 2026, il y a 584 fournisseurs dans ce registre, et c'est une liste prête de responsables.
Pourquoi cela brise les VPN mieux que le DPI
La lutte classique contre le contournement des blocages est une compétition de dissimulation du trafic : le DPI recherche la signature du protocole, les développeurs la cachent sous un HTTPS ordinaire, le DPI apprend à nouveau. Le jeu est sans fin, et dans celui-ci, la partie défensive gagne régulièrement des rounds : les protocoles qui masquent le trafic sous un HTTPS ordinaire fonctionnent de manière nettement plus stable en 2026 que les standards « nus ».
Le blocage par adresses contourne cette compétition. Peu importe à quel point votre trafic est bien masqué, si l'adresse de destination elle-même est inaccessible. Ce n'est pas la signature qui est attaquée, mais une ressource rare — des IP propres sur une plateforme amicale. Et cette ressource pour les VPN consommateurs est organisée de manière extrêmement vulnérable : plusieurs centaines de serveurs chez quelques hébergeurs, un client public avec une liste complète d'adresses, un point de défaillance unique au niveau du système autonome.
Trois niveaux sur lesquels l'accès est actuellement coupé
Pour ne pas confondre les causes et ne pas traiter un problème avec un autre, il est utile de garder à l'esprit un schéma simple. Les restrictions sont imposées à trois niveaux indépendants, et les mesures de protection à ces niveaux sont différentes.
- Niveau du protocole. Le DPI recherche la signature : la poignée de main, les tailles de paquets caractéristiques, le comportement TLS. Cela se traite par la dissimulation sous un HTTPS ordinaire — et c'est ici que se déroule la course éternelle. Depuis décembre 2025, à ce niveau, on appuie spécifiquement sur SOCKS5, VLESS et L2TP.
- Niveau de l'adresse. Un IP, un sous-réseau ou un système autonome entier est filtré. La dissimulation du trafic ici est inutile : l'adresse de destination est tout simplement inaccessible. C'est ce qui s'est passé le 4 août.
- Niveau du fournisseur. L'obligation de rechercher et de désactiver l'infrastructure de contournement est transférée à l'hébergeur, et la sanction consiste à limiter ses propres sous-réseaux. Bien que ce soit un schéma discuté, il frappe tous les clients de la plateforme en même temps, y compris ceux qui n'ont rien à voir avec les VPN.
L'erreur la plus fréquente est d'essayer de résoudre le problème du deuxième niveau avec des moyens du premier : changer de protocole et de port, alors que l'adresse est déjà sur la liste. Le symptôme est le même — la connexion ne s'établit pas — mais les causes sont différentes.
Ce qui change pour ceux qui ont besoin d'accès à des services externes
Ici commence la partie pratique, et il convient de la discuter honnêtement, sans promesses d'invulnérabilité.
La surface de blocage des proxies résidentiels et mobiles est différente. L'adresse de sortie d'un tel proxy n'appartient pas au fournisseur d'hébergement, mais à un fournisseur d'accès Internet domestique ou à un opérateur mobile — le même ASN d'où sortent les abonnés ordinaires. Bloquer un sous-réseau entier ici signifie déconnecter des personnes réelles, donc un nettoyage massif aux frontières d'un système autonome dans ce segment ne fonctionne pas comme il a fonctionné pour les hébergements le 4 août. Cela explique également pourquoi les proxies mobiles avec une adresse CGNAT partagée par des centaines d'abonnés sont plus chers que ceux des centres de données : rejeter une telle adresse coûte cher pour la plateforme elle-même.
Ce que cela ne donne pas. Les proxies ne suppriment pas le DPI : si la filtration s'accroche à la signature du protocole ou à la nature de la session TLS, le type d'IP de sortie ne sauvera pas. Il ne sauvera pas non plus du blocage du service de destination lui-même, ni des restrictions imposées par la plateforme (captcha, exigence de connexion, politique régionale). Une analyse détaillée de la façon dont cette ligne de défense fonctionne est disponible dans le matériel sur le contournement des blocages en cas de DPI actif.
Que faire dès maintenant, si l'accès est nécessaire pour le travail :
- Ne mettez pas tout dans un seul système autonome. La panne d'août concernait précisément cela : un fournisseur — un point de défaillance. Le canal de secours doit passer par un type d'adresse fondamentalement différent, et non par un deuxième serveur chez le même hébergeur.
- Différenciez les tâches. L'accès à un service externe pour une personne et l'automatisation avec des centaines de requêtes sont des scénarios différents avec des exigences différentes. Pour le second, le type d'adresse et la stabilité de la session sont plus critiques que la vitesse.
- Ne considérez pas un port non standard comme une solution. C'est un report. Si la sélection passe à l'analyse de la réponse du serveur, le transfert vers un autre port cessera d'aider.
- Commencez par le diagnostic, puis par l'achat. Le même symptôme « rien ne fonctionne » peut provenir de quatre pannes différentes, et le proxy n'aide pas dans tous les cas. Comment distinguer en quelques minutes une coupure régionale d'un blocage d'un service spécifique est expliqué dans le guide de diagnostic des coupures.
- Pour Telegram, examinez le protocole séparément. MTProto et SOCKS5 se comportent différemment lors de la filtration, et le choix ici ne se résume pas à « prendre n'importe quel proxy » — les détails sont dans le guide honnête sur les proxies pour Telegram.
Conclusion
La vague d'août a montré un changement de tactique : de la chasse aux protocoles à la gestion de l'espace d'adresses et au transfert de la recherche vers les fournisseurs d'hébergement. Pour les VPN consommateurs de masse, c'est un coup dur — leur infrastructure est compacte, publique et concentrée chez quelques fournisseurs, et la liste des serveurs est achetée avec l'abonnement.
Pour l'accès nécessaire au travail, la conclusion est simple et ennuyeuse : la résilience est désormais déterminée non par la « sophistication du protocole », mais par la diversité de l'espace d'adresses et par le coût pour la plateforme de rejeter votre IP de sortie avec les abonnés ordinaires. Si l'objectif est un accès stable aux services externes et l'automatisation, les proxies résidentiels offrent une surface de blocage fondamentalement différente de celle d'un serveur sur un hébergement loué. Ce n'est pas de la magie, mais une économie différente pour l'autre partie.
```