Shadowsocks et Xray : quand le VPN est bloqué
Table des matières
Je travaille souvent avec des VPN. Pas comme sujet théorique, mais dans le quotidien opérationnel : connecter des sites, donner accès à des clients au réseau d’entreprise, garder des serveurs joignables, configurer des firewalls, renouveler des certificats, stabiliser des tunnels IPsec, déboguer des clients SSL VPN et comprendre pourquoi un site ne passe soudainement plus.
En temps normal, c’est du travail réseau solide et assez ennuyeux. C’est exactement ce que l’on veut.
Mais il existe des cas où un VPN techniquement correct ne suffit plus. Avec des clients venant de pays où l’accès à Internet est fortement régulé, par exemple la Chine ou la Russie, on rencontre régulièrement des situations où les protocoles VPN classiques sont bloqués, perturbés ou détectés de manière ciblée. Comme je travaille à Dubaï avec une clientèle très internationale, ce n’est pas abstrait. La question opérationnelle est simple : comment maintenir un accès légitime à sa propre infrastructure lorsque la connexion est filtrée en chemin ?
C’est dans ce contexte qu’apparaissent Shadowsocks, ShadowsocksR, V2Ray, Xray-core, VLESS, Trojan, REALITY ou XHTTP. Au début, cela ressemble à un mélange confus de projets, de forks et d’abréviations. Et, honnêtement, une partie de cette impression est juste.
Quand un VPN ne bloque pas au login, mais déjà sur le chemin dans le réseau, il ne faut pas seulement parler de chiffrement, mais aussi de visibilité.
Pourquoi Shadowsocks est apparu
Shadowsocks ne vient pas du monde classique des VPN d’entreprise. Il n’a pas été créé pour remplacer IPsec ni pour construire une meilleure solution site-to-site. Son origine est plus directe : en 2012, un développeur sous le pseudonyme clowwindy voulait un moyen léger de sortir d’un réseau fortement filtré vers l’Internet ouvert.
Cela explique le design : un outil léger, rapide et pratique. Pas un gros client VPN, pas une appliance d’accès distant, pas une suite avec identité et reporting de conformité. L’idée était un proxy SOCKS5 local qui chiffre le trafic et l’envoie vers un serveur situé hors de la zone de blocage.
Le besoin n’était donc pas “plus de fonctions sécurité pour entreprises”, mais “j’ai besoin d’une sortie qui fonctionne depuis un réseau qui filtre certains protocoles et destinations”. C’est pour cela que Shadowsocks reste intéressant, mais aussi souvent mal compris. C’est un excellent composant de transport, pas automatiquement un VPN d’entreprise complet.
En 2015, l’histoire est devenue plus politique : clowwindy a écrit sur GitHub que la police lui avait rendu visite et qu’il devait arrêter le projet. Le développement a continué via des forks et d’autres implémentations. Ces outils naissent souvent d’une douleur technique très concrète, puis entrent dans une course plus large entre utilisateurs, développeurs et infrastructures de filtrage.
Pourquoi un VPN se remarque
Quand on parle de VPN, beaucoup pensent d’abord au chiffrement. C’est correct, mais ce n’est qu’une partie du sujet.
Un censeur, un fournisseur d’accès ou un grand firewall national n’a pas toujours besoin de lire le contenu d’une connexion chiffrée pour la perturber. Il suffit souvent de reconnaître l’enveloppe. IPsec, SSL VPN, WireGuard ou OpenVPN ont des caractéristiques typiques : ports, tailles de paquets, schémas de handshake, comportement des certificats, timing, usage d’UDP, répétitions, erreurs ou adresses IP de serveurs connues.
Imaginez non pas la lettre, mais l’enveloppe. Le contenu est chiffré, mais l’enveloppe a une taille, une couleur, un timbre et un expéditeur récurrent. Quelqu’un qui trie uniquement des enveloppes n’a pas besoin de lire le texte pour envoyer ce type d’enveloppe vers un contrôle spécial.
Le trafic réseau fonctionne de façon comparable. La Deep Packet Inspection et la classification de trafic ne regardent pas seulement les ports. Elles analysent des motifs. Dans TLS, un Client Hello, SNI, une chaîne de certificats ou ALPN peuvent ressortir. Dans des protocoles entièrement chiffrés, l’apparence trop aléatoire des premiers paquets peut devenir un signal. Des travaux sur la Great Firewall ont montré que les longueurs de paquets, l’entropie et les caractères ASCII imprimables dans les premiers paquets comptent aussi.
Le point inconfortable est là : “tout semble aléatoire” ne veut pas dire “tout est discret”. Parfois, c’est précisément cela qui attire l’attention.
Ce que montre la recherche
Le point important n’est pas seulement que les systèmes de censure “détectent les VPN”. On le savait déjà. Ce qui est intéressant, c’est à quel point le début de la détection peut être peu spectaculaire techniquement.
Un bon point d’entrée est le travail de mesure de GFW Report présenté en 2020 à l’ACM Internet Measurement Conference. GFW Report n’est ni un produit ni un fournisseur, mais un projet de recherche et de mesure autour de la Great Firewall.
L’idée clé : il ne s’agissait pas d’une attaque magique de déchiffrement. La Great Firewall combinait observation passive et probes actifs. Les connexions devenaient d’abord suspectes à cause de propriétés comme la longueur et l’entropie du premier paquet de données. Ensuite, le censeur se connectait lui-même au serveur supposé, rejouait des paquets anciens ou modifiés et observait si l’autre côté réagissait comme un serveur Shadowsocks.
Pour les administrateurs, cela révèle deux niveaux de défense :
- Le trafic ne doit pas être trop visible passivement.
- Le serveur ne doit pas répondre comme un proxy lors de tests actifs.
En 2023, une autre étude GFW a montré que du trafic entièrement chiffré pouvait être bloqué avec des heuristiques simples. Si le premier payload TCP ne ressemble ni à TLS, ni à HTTP, ni à du texte imprimable, mais à un bloc aléatoire, cela peut déjà suffire. Le camouflage ne consiste donc pas toujours à être “le plus aléatoire possible”.
En 2024, les travaux sur les handshakes TLS encapsulés ont ajouté une autre couche : même si le tunnel extérieur est chiffré et bien camouflé, un handshake TLS intérieur peut apparaître comme motif dans une pile de protocoles imbriquée. Le padding aléatoire aide peu dans ce cas ; le multiplexing de streams semble plus prometteur, mais ne résout pas tout si un seul flux applicatif reste visible.
Les recherches sur le timing et les RTT cross-layer vont dans le même sens. Un proxy décale les sessions transport et application. Ces différences temporelles peuvent être mesurables, que le client soit proche ou éloigné du proxy. Ce n’est pas un simple header que l’on change.
Conclusion sobre : ce n’est pas l’étiquette du protocole qui décide, mais le comportement global du montage.
Shadowsocks n’est pas un VPN classique
Shadowsocks est souvent rangé avec les VPN. Dans le langage courant, c’est compréhensible ; techniquement, c’est imprécis.
Shadowsocks est un proxy chiffré, vaguement basé sur SOCKS5. Un client local offre un proxy aux applications, chiffre le trafic et l’envoie vers un serveur Shadowsocks distant. Le serveur déchiffre la requête, se connecte à la vraie destination et renvoie la réponse par le chemin chiffré.
C’est plus léger qu’un VPN complet. Shadowsocks ne met pas automatiquement tout le système d’exploitation dans un tunnel. Il sert à faire passer du trafic choisi par un autre chemin. Selon le client et le système, on peut construire une expérience proche d’un VPN, mais l’idée de base reste un proxy, pas un VPN site-to-site.
Pour les administrateurs, cela évite de mauvaises attentes :
- Shadowsocks ne remplace pas un IPsec site-to-site propre.
- Shadowsocks n’est pas une protection magique contre toute détection.
- Shadowsocks est utile quand il faut un proxy chiffré simple et rapide depuis un réseau restrictif.
Techniquement, Shadowsocks a évolué. Les anciens montages avec stream ciphers ne doivent plus servir de référence. Les déploiements modernes appartiennent au monde AEAD, et Shadowsocks 2022 ajoute une base de clés symétriques prépartagées, une dérivation basée sur BLAKE3, une protection contre le replay et d’autres corrections. Limite importante : la spécification n’offre pas de Forward Secrecy. Si une clé est compromise, la rotation propre est obligatoire.
Avec shadowsocks-rust, on dispose d’une implémentation moderne qui peut aussi tourner avec Docker. Côté serveur, on trouve par exemple ssserver; côté client, sslocal. Il faut des secrets générés proprement, un port joignable, des chiffrements actuels et une décision claire sur TCP, UDP ou les deux.
Pourquoi Xray-core est une autre catégorie
Xray-core n’est pas simplement “Shadowsocks en plus récent”. C’est plutôt un framework pour scénarios de proxy et de tunnel.
Xray combine des protocoles inbound et outbound comme VLESS, VMess, Trojan, Shadowsocks, WireGuard, Hysteria, SOCKS et HTTP. On ajoute des transports comme RAW, WebSocket, gRPC, XHTTP ou Hysteria, puis TLS, REALITY ou XTLS Vision. VMess reste présent dans de nombreux anciens montages, mais il est plutôt legacy pour les nouveaux déploiements ; aujourd’hui, VLESS est souvent central.
Shadowsocks est le tournevis rapide. Xray est la boîte à outils. On peut construire un montage simple, mais aussi une chaîne où un client local SOCKS ou TUN reçoit le trafic, l’envoie via VLESS avec REALITY vers un serveur, puis le serveur sort vers Internet avec un outbound freedom.
VLESS n’est pas le camouflage lui-même. C’est un protocole proxy léger avec authentification par UUID. La confidentialité et l’effet de camouflage viennent de la couche de transport et de sécurité : TLS, REALITY ou XTLS Vision.
REALITY est particulièrement intéressant, car il ne fait pas simplement “encore du TLS”. Le serveur emprunte vers l’extérieur le handshake TLS d’un vrai site HTTPS tiers. Pour un observateur, cela ressemble au certificat réel d’un vrai site, pas à un certificat proxy bricolé. Seul un client autorisé reconnaît, grâce au matériel de clé configuré, qu’il parle à son propre serveur Xray.
Cela vise surtout le fingerprint TLS côté serveur et l’active probing. uTLS aide côté client en imitant des Client Hellos de navigateurs. Mais Xray n’est pas une cape d’invisibilité : timing, tailles de paquets, ALPN, comportement serveur et motifs TLS imbriqués peuvent rester visibles. XTLS Vision et XHTTP sont des blocs intéressants, pas une garantie. Un peu de padding aide peu si le motif de base du trafic imbriqué reste reconnaissable.
Les approches UDP comme Hysteria ou QUIC peuvent être rapides, mais les réseaux restrictifs les brident ou les bloquent souvent plus facilement que TCP/443 sortant. Xray demande donc plus de discipline que Shadowsocks : figer les versions, tester les changements, lire les release notes et ne pas copier aveuglément chaque conseil de forum.
La confusion autour des forks et des noms
En cherchant, on tombe vite sur de vieux articles, des forks GitHub et des clients à moitié maintenus. C’est lié à l’histoire de ces outils.
Shadowsocks est un protocole et un écosystème avec plusieurs implémentations. shadowsocks-rust est aujourd’hui un choix naturel pour un serveur moderne. Des implémentations comme shadowsocks-libev restent connues, mais selon leur état elles sont plutôt legacy ou orientées bugfix.
ShadowsocksR était un fork avec des idées supplémentaires d’obfuscation. SSR apparaît encore dans beaucoup de guides anciens. Je serais prudent aujourd’hui : pas parce que toute ancienne installation est mauvaise, mais parce qu’il faut vérifier client, serveur, crypto, mises à jour et communauté.
Xray-core vient de l’environnement V2Ray, mais s’est développé indépendamment. Copier un vieux tutoriel V2Ray vers Xray est donc risqué. Les concepts se ressemblent parfois, mais les configurations et recommandations ont changé.
V2Fly reste pertinent comme projet communautaire autour de V2Ray, plutôt conservateur. Xray-core pousse plus vite des fonctions comme REALITY, XTLS Vision ou XHTTP. À côté, sing-box réunit aussi beaucoup de ces protocoles dans une plateforme moderne. Ici, je garde Xray au centre, mais dans un lab je regarderais aussi sing-box.
Conseil pragmatique :
- Pour un nouveau montage simple : tester Shadowsocks avec une implémentation actuelle.
- Pour des réseaux plus difficiles : tester Xray-core avec un design propre et récent.
- Pour d’anciens guides SSR ou V2Ray : vérifier d’abord le statut et la sécurité.
- Pour la production client : ne rien copier sans comprendre soi-même le montage.
Ce qu’il faut des deux côtés
Un montage minimal a toujours deux côtés.
Côté distant, il faut un serveur hors du réseau restrictif : VPS, serveur en datacenter ou infrastructure contrôlée dans une région joignable depuis le site client. Ce serveur doit être durci, patché, surveillé et documenté. Une instance bon marché oubliée après déploiement devient un risque.
Côté client, il faut le bon programme : souvent un client SOCKS local ou une app configurant le proxy système pour Shadowsocks ; pour Xray, un client Xray, un mode TUN, un routeur ou une app important des profils.
Il faut aussi :
- un objectif clair
- une authentification propre
- des versions à jour
- une résolution DNS contrôlée
- des logs sans données client inutiles
- un monitoring de la joignabilité
- un plan de rotation des serveurs, ports et secrets
- une vérification légale et contractuelle
Le dernier point compte vraiment. Dans certains pays, l’usage de ces outils peut être problématique. En entreprise, il faut aussi distinguer l’accès à ses propres systèmes, l’exploitation de réseaux clients et l’accès Internet général pour les employés.
DNS est souvent sous-estimé. Si le navigateur ou le système résout encore les domaines via le fournisseur local, le tunnel n’aide qu’à moitié. Le contenu passe peut-être par le proxy, mais la requête DNS révèle la destination. Il faut donc vérifier le chemin DNS, IPv6 et le comportement en cas de rupture du tunnel.
Le logging est délicat lui aussi. Pour dépanner, on veut savoir si le tunnel vit. Pour protéger les clients, on veut stocker le minimum. Un bon montage collecte états techniques, latences, taux d’erreur et volumes, pas des listes complètes de destinations. Les logs debug, TLS keylogs ou access logs non masqués n’ont pas leur place durablement en production.
Le monitoring doit valider un vrai chemin de test, le routage DNS, les régions de destination et la vue depuis le pays concerné, pas seulement le fait qu’un conteneur tourne.
Comment je le classerais en exploitation
Pour moi, Shadowsocks ou Xray ne remplacent pas l’architecture firewall, Zero Trust, MFA ou une segmentation propre. Ce sont des outils de transport pour cas spéciaux.
Une approche d’entreprise raisonnable :
- Vérifier d’abord SSL VPN, IPsec ou WireGuard.
- Si c’est bloqué, mesurer : DNS, port, protocole, IP serveur, fingerprint TLS, bridage UDP.
- Tester ensuite Shadowsocks ou Xray-core comme transport alternatif.
- Limiter le tunnel aux destinations nécessaires.
- Filtrer côté serveur les services internes accessibles.
- Mettre du monitoring pour ne pas dépendre du retour client.
- Prévoir un fallback : autre exit, fournisseur, région ou protocole.
- Séparer secrets et profils par site ou utilisateur.
- Construire logs et métriques sans collecte inutile.
Quand un client ne peut plus accéder à ses systèmes, on veut d’abord rétablir la connexion. Je le comprends. Mais après, il faut nettoyer et documenter, sinon un workaround temporaire devient un chemin de production invisible.
Pourquoi les blocages rattrapent souvent leur retard
Ces outils évoluent dans un environnement où l’autre côté adapte constamment sa détection.
Si beaucoup de gens utilisent le même Docker Compose, le même port, le même fingerprint TLS, la même stratégie de domaine et le même fournisseur VPS, le motif finit par se voir. On ne bloque alors pas “Xray” ou “Shadowsocks” abstraitement, mais un motif concret : handshakes, tailles de paquets, plages IP, clients typiques, fallbacks mal configurés ou réponses d’erreur suspectes.
Le camouflage n’est donc pas seulement une fonction du logiciel. C’est de l’exploitation : mêmes outils, autres domaines, autres fournisseurs, autres profils clients et autres motifs de trafic peuvent avoir une apparence très différente.
C’est aussi pourquoi je reste prudent face aux affirmations de certains projets. Une promesse d’indétectabilité reste une affirmation de projet. Un papier montrant qu’une caractéristique a été détectée dans un vrai réseau a un autre poids. En pratique, il faut les deux : vitesse d’innovation des projets et sobriété de la recherche.
Mon évaluation
Shadowsocks est pertinent quand il faut un proxy chiffré léger, rapide et relativement simple. Il convient aux premiers tests, aux accès temporaires et aux environnements où la détection n’est pas extrêmement agressive.
Xray-core est pertinent quand le réseau est plus difficile, quand plusieurs transports sont nécessaires ou quand on veut travailler avec VLESS, REALITY, WebSocket, gRPC ou XHTTP. Mais il demande plus de compréhension. Sa flexibilité ouvre aussi plus de portes aux erreurs de configuration.
Je ne vendrais jamais ces outils comme “remplaçants de VPN” pour des clients. Je parlerais plutôt d’un chemin de transport alternatif pour des accès légitimes. C’est moins spectaculaire, mais plus honnête.
La vraie différence n’est pas Shadowsocks contre Xray. C’est : est-ce que je comprends le problème que je résous ? Pour un accès distant normal, j’utilise des VPN normaux. Pour une détection protocolaire par État ou fournisseur, je dois parler visibilité, fingerprints et stratégie d’exploitation. Si je ne peux pas l’expliquer proprement, je ne devrais pas l’exploiter pour des clients.
Conclusion
Shadowsocks et Xray-core viennent d’un monde où les connexions réseau ne font pas que “fonctionner” ou “ne pas fonctionner”. Elles peuvent être classées, bridées, testées activement ou bloquées. Toute personne qui accompagne des clients internationaux finit par croiser cette réalité.
Le sujet m’intéresse parce qu’il rend le réseau très concret : chiffrement, motifs, fingerprints, routage, DNS, exploitation, droit, responsabilité, et le fait qu’un tunnel qui fonctionne n’est pas automatiquement un bon design.
La suite est claire pour moi : je veux reproduire Shadowsocks et Xray-core dans un petit lab. Pas pour contourner aveuglément la censure, mais pour comprendre pourquoi les VPN classiques se remarquent parfois et quelles alternatives peuvent être exploitées sérieusement.
À la prochaine,
Joe
