Protocole VLESS : Guide V2Ray VPN, serveur Xray et contournement de la censure
Environ cinq ans après son apparition dans un obscur dépôt GitHub dédié à l'incubation, VLESS s'est discrètement imposé comme le protocole par défaut des serveurs proxy utilisés en Russie, en Iran et en Chine. Les raisons de ce succès sont peu romantiques : sa taille réduite, l'absence de chiffrement direct et, à la mi-2026, il s'agissait du seul protocole largement déployé que les principaux systèmes d'inspection approfondie des paquets (DPI) étatiques n'avaient pas encore réussi à supplanter de manière décisive.
Ce guide explique ce qu'est VLESS en tant que protocole léger, son fonctionnement interne, les services qui s'exécutent par-dessus (Xray, XTLS, REALITY), sa comparaison avec VMess, Trojan, Shadowsocks, WireGuard et les protocoles VPN traditionnels comme OpenVPN, et à quoi ressemble une configuration VPN VLESS concrète. Il s'agit d'une explication technique, et non d'un tutoriel de configuration. Si, après avoir lu ce guide, vous souhaitez toujours copier-coller des commandes serveur, consultez la documentation du projet sur xtls.github.io.
Qu'est-ce que VLESS et pourquoi la communauté V2Ray l'a créé ?
VLESS, abréviation de « VMess Less », est un protocole proxy léger sans état introduit en 2020 par le développeur connu sous le nom de RPRX, qui maintenait un dépôt d'incubation à l'adresse RPRX/v2ray-vless depuis 2019. Il a été conçu comme une simplification délibérée de VMess, le protocole V2Ray original, qui était devenu difficile à gérer à la fin des années 2010 en raison de son propre mécanisme de chiffrement, de protection contre la relecture et de synchronisation d'horloge.
Aujourd'hui, VLESS est principalement présent dans deux bases de code. Le dépôt original v2fly/v2ray-core le conserve pour des raisons de compatibilité. La branche XTLS/Xray-core, également maintenue par RPRX, est l'implémentation la plus activement développée : 38 600 étoiles sur GitHub et environ 5 400 branches (forks) en mai 2026, contre 33 900 étoiles pour v2fly/v2ray-core. Xray intègre les fonctionnalités essentielles, à savoir le contrôle de flux XTLS Vision et le transport REALITY, absents de la version originale de v2fly.
Fonctionnement du protocole VLESS : UUID, absence de chiffrement, TLS externe
Le protocole VLESS est suffisamment court pour être décrit en un paragraphe. Un client établit une connexion et envoie un en-tête. Cet en-tête contient un octet de version, un UUID de 16 octets pour l'utilisateur, un indicateur de longueur pour le champ des modules complémentaires optionnels, les modules complémentaires eux-mêmes, une commande d'un octet (TCP ou UDP), le port de destination, un octet de type d'adresse et l'adresse. Cela représente entre 25 et 50 octets par connexion. OpenVPN, quant à lui, utilise plus de 100 octets par paquet.
L'en-tête n'est en aucun cas chiffré par VLESS. Le protocole exige explicitement la configuration JSON `encryption: "none"`, et la documentation v2fly précise que ce champ ne peut être laissé vide : la valeur « none » doit être explicitement indiquée afin de rappeler aux opérateurs que le protocole délègue toute la confidentialité au protocole de transport sous-jacent. En pratique, ce transport est presque toujours TLS 1.3.
Ce choix de conception est à l'origine de toutes les propriétés intéressantes de VLESS. En n'exécutant pas sa propre couche de chiffrement, VLESS évite le problème qui a causé la perte de VMess sur les réseaux censurés. Une seconde couche de chiffrement à l'intérieur d'un tunnel TLS externe produit ce que les analystes du trafic appellent des schémas « TLS dans TLS ». Les systèmes DPI étatiques, entraînés à repérer précisément cette structure à double encapsulation, ont été la principale raison pour laquelle les taux de détection de VMess ont dépassé les 80 % sur le Grand Pare-feu chinois en septembre 2025. VLESS, ne transportant qu'un blob d'authentification et des métadonnées de routage, ressemble beaucoup plus à une simple conversation TLS ordinaire, ce qui déjoue le type d'empreinte de protocole sur lequel s'appuient les systèmes d'inspection approfondie des paquets.
L'autre omission délibérée est l'absence d'état. VLESS repose sur la synchronisation des horloges entre le client et le serveur, avec des horodatages de paquets utilisés pour prévenir les attaques par rejeu. Il en a résulté des années de défaillances de connexion déroutantes, dès qu'un téléphone déréglait son horloge, qu'un ordinateur portable était configuré en double démarrage ou qu'un serveur se trouvait dans un fuseau horaire incorrect. VLESS est sans état. L'UUID constitue l'unique mécanisme d'authentification. Si l'UUID correspond, la connexion est autorisée ; sinon, elle est rejetée dès le premier octet. L'heure n'a aucune incidence sur le processus.
Dans VLESS, les UUID sont des identifiants conformes à la norme RFC-4122. La commande `xray uuid` les génère ; tout générateur d'UUID standard convient également. Les chaînes personnalisées de 30 octets maximum sont acceptées et converties en UUID selon la norme de correspondance UUID de VLESS, décrite dans la documentation. La plupart des configurations utilisent les UUID canoniques, car cette correspondance reste sans incidence en pratique.
Le protocole prend en charge plusieurs options de transport : TCP (avec ou sans TLS), mKCP, WebSocket, gRPC et QUIC. Chacune structure le trafic différemment. WebSocket permet à VLESS de se dissimuler derrière une négociation HTTP/1.1 standard et d'acheminer les données via des CDN comme Cloudflare. gRPC exploite le multiplexage HTTP/2. QUIC transporte l'ensemble du trafic dans une session TLS 1.3 externe basée sur UDP. Le protocole est indépendant du transport utilisé. Cette séparation des méthodes lui confère sa portabilité.
Rayons X, RÉALITÉ et XTLS : La pile sur laquelle VLESS fonctionne réellement
En pratique, personne ne fait tourner VLESS nu. Ce qui est intéressant, c'est ce qui l'entoure.
Xray-core est le moteur d'exécution dominant. Il s'agit d'une version dérivée de V2Ray-core, créée par RPRX et les contributeurs d'XTLS suite à une scission au sein de la communauté. Elle intègre deux technologies essentielles à VLESS pour le contournement de la censure : XTLS Vision et REALITY.
XTLS Vision (spécifié par `flow: "xtls-rprx-vision"` dans la configuration) est un mécanisme de remplissage appliqué au trafic TLS 1.3. Le problème qu'il résout est subtil : les enregistrements TLS 1.3 ont des signatures de longueur prévisibles lorsqu'ils transportent des données applicatives internes de forme fixe ; ces longueurs divulguent des informations sur le contenu tunnelé. Vision ajoute des octets de remplissage lors de la phase initiale d'établissement de la connexion. Une fois la connexion établie, il bascule vers une copie directe des sockets. Sous Linux, il utilise l'appel système `splice()` pour transférer les paquets TCP dans le noyau sans passer par l'espace utilisateur. Le résultat est un débit proche de celui d'une connexion TCP non proxyfiée, la fuite d'informations liée à la longueur étant éliminée.
REALITY, sorti en 2023 et maintenu sur github.com/XTLS/REALITY, est plus radical. Un serveur VLESS+TLS standard présente son propre certificat TLS, ce qui implique qu'il possède un domaine, exécute un Certbot et expose une empreinte de certificat qu'un système DPI peut corréler avec l'utilisation d'un proxy. REALITY rejette complètement ce principe. Au lieu d'exécuter son propre protocole TLS, le serveur imite la négociation TLS d'un véritable site web tiers. L'opérateur choisit la cible : `microsoft.com`, `apple.com`, ou tout autre domaine. Le serveur utilise la falsification SNI et un échange de clés X25519. Les clients qui connaissent la clé publique REALITY correcte effectuent une véritable négociation TLS 1.3 avec la chaîne de certificats usurpée, exactement comme un navigateur le ferait avec un véritable serveur web, puis sont acheminés vers le tunnel VLESS. Les clients qui ne la connaissent pas, y compris les systèmes DPI de sondage, voient ce qui ressemble à une connexion normale avec le site usurpé, y compris le véritable certificat.
La combinaison de VLESS comme protocole interne, d'XTLS Vision pour l'aplatissement de la signature de longueur et de REALITY pour le camouflage de la poignée de main correspond à ce que l'on entend par « VLESS+REALITY » ou « VLESS+Vision+REALITY ». C'est la configuration qui, à la mi-2026, fonctionne encore dans des environnements où presque rien d'autre ne fonctionne.
VELESS contre VMess contre Trojan contre Shadowsocks contre WireGuard
L'espace protocolaire autour de VLESS est restreint et les différences sont importantes. La version courte est présentée ci-dessous ; la version longue est disponible dans le tableau.
VMess est le prédécesseur de VLESS. Il intègre son propre chiffrement AEAD, une protection contre la relecture et des variantes basées sur alterId. Sur un réseau non censuré, ces fonctionnalités entraînent une perte de débit de quelques pourcents seulement, sans aucun avantage. Sur un réseau censuré, le chiffrement intégré à TLS est détectable, et les données de télémétrie du GFW indiquent un taux de détection d'environ 80 % depuis septembre 2025.
Trojan est un projet similaire, conçu par une autre équipe. Il est encore plus simple que VLESS : un mot de passe au lieu d’un UUID, aucun champ pour les modules complémentaires, et le protocole TLS externe. Pendant des années, ce minimalisme a fait sa force ; la mise à jour du Grand Pare-feu GFW en août 2025 a changé la donne, et Trojan est désormais détecté dans environ 90 % des cas.
Shadowsocks appartient à une toute autre famille. Il s'agit d'un chiffrement AEAD symétrique sans interface TLS, conçu pour se faire passer pour une suite d'octets aléatoires plutôt que pour du HTTPS. Cette approche a fonctionné jusqu'à ce que le Grand Pare-feu californien (GFW) commence à considérer par défaut le trafic entièrement chiffré comme suspect ; les déploiements modernes de Shadowsocks s'appuient sur des plugins de transport (v2ray-plugin, cloak) qui encapsulent le chiffrement dans TLS ou HTTP, reconstruisant ainsi l'architecture VLESS dans le sens inverse.
WireGuard mérite une discussion à part entière. Il s'agit d'un VPN au niveau du noyau, et non d'un protocole proxy. Sur un réseau non censuré, il est environ 2 à 3 % plus rapide que VLESS+XTLS en termes de débit brut, avec une charge CPU bien moindre, et reste la solution idéale pour les cas d'utilisation courants visant à protéger sa vie privée contre les FAI. Sur les réseaux censurés, son octet de connexion fixe 0x01 est facilement identifiable, et le débit effectif chute à un niveau quasi nul.
| Protocole | Famille | couche externe | résistance DPI | Idéal pour |
|---|---|---|---|---|
| VLESS+RÉALITÉ | Proxy V2Ray/Xray | Usurpation d'identité TLS 1.3 | Élevée (≤5% de détection dans les rapports de terrain) | Réseaux hostiles |
| VMess | Proxy V2Ray | Auto-chiffrement au sein de TLS | Faible (~80 % GFW) | Compatibilité héritée uniquement |
| troyen | proxy frontal TLS | TLS autogéré | Faible (~90 % GFW après août 2025) | Auto-hébergement simplifié |
| Chaussettes d'ombre (AEAD) | Obfuscation symétrique | Octets aléatoires / plugin TLS | Mixte (dépend du plugin) | Utilisateurs mobiles sur des liens instables |
| WireGuard | VPN du noyau | UDP + poignée de main Noise | Très faible (détectable par DPI) | Confidentialité et vitesse du réseau propre |
VLESS, la censure et le blocus russe du DPI
VLESS ne serait qu'une simple note de bas de page dans l'histoire des logiciels proxy si ce n'est parce qu'il contourne la censure en Russie et dans des régimes similaires avec une fiabilité supérieure à celle de tout autre protocole largement déployé. Depuis 2024, les plus grands systèmes d'inspection approfondie des paquets (DPI) étatiques au monde s'efforcent activement de le neutraliser. Depuis lors, on assiste à une lente escalade des tensions.
En Russie, Roskomnadzor a recensé 439 services VPN bloqués en janvier 2026. Le budget fédéral alloué au blocage des VPN s'élevait à environ 60 milliards de roubles (environ 780 millions de dollars) pour la période 2025-2027, auxquels s'ajoutaient 2,27 milliards de roubles (environ 29 millions de dollars) spécifiquement destinés au filtrage du trafic par intelligence artificielle, selon un article de zona.media paru en avril 2026. Le 17 février 2026, Roskomnadzor a intensifié ses efforts, lançant une vague de blocages massive ciblant spécifiquement le protocole VLESS sur TCP avec TLS, comme l'ont documenté Mezha et digirpt. En quelques heures, les utilisateurs se sont tournés vers REALITY, gRPC et les protocoles utilisant un CDN. Le taux de contournement communautaire du protocole VLESS+REALITY face à l'inspection approfondie des paquets (DPI) russe avoisinait les 99,5 % durant cette vague, un chiffre à considérer comme une simple indication plutôt que comme une mesure absolue.
En Chine, le Grand Pare-feu a connu une évolution similaire en 2025. Le taux de détection des chevaux de Troie a chuté à environ 90 % en août, et celui de VLESS à environ 80 % en septembre. Un autre incident de cybersécurité survenu en septembre 2025, une fuite de 600 Go provenant d'un sous-traitant chinois du Grand Pare-feu et rapportée par Cybernews, a exposé des éléments de l'infrastructure de classification interne, sans toutefois modifier à lui seul le coût de déploiement. Des tests menés par la communauté sur greatfirewallguide.com ont fait état d'un taux de contournement de 98 % pour VLESS+REALITY+Vision début 2026.
En Iran, le pare-feu IRGFW de MCI met sur liste grise les adresses IP REALITY depuis au moins avril 2024, comme indiqué dans la discussion XTLS/Xray-core n° 3269. Les opérateurs signalent qu'une adresse IP transportant environ 100 Go de trafic REALITY a tendance à être bloquée par Irancell dans les 48 heures, ce qui explique pourquoi la rotation des serveurs et l'utilisation de CDN en fronting sont devenues une pratique courante.
Configuration d'un VPN VLESS : serveur, clients, configurations
Un déploiement VLESS fonctionnel comporte trois parties : un serveur quelque part, un client sur chaque appareil et une chaîne de connexion qui les relie.
La configuration serveur est peu exigeante. N'importe quel VPS bon marché fera l'affaire : Hetzner, Vultr, OVH, ou tout fournisseur disposant d'une adresse IPv4 publique. Installez Xray-core à partir des binaires de la version publiée du projet ou via un gestionnaire de paquets, générez un UUID (`xray uuid`), générez une paire de clés X25519 pour REALITY (`xray x25519`), choisissez une cible d'usurpation d'identité (un site HTTPS réel prenant en charge TLS 1.3 et HTTP/2), et rédigez une configuration serveur JSON se liant au port 443. Une fois la configuration effectuée, le temps total est d'environ dix minutes. Des panneaux web comme 3X-UI et Hiddify-Manager proposent la même configuration dans une interface navigateur pour les opérateurs qui préfèrent ne pas modifier le JSON. Des appliances gérées existent également. AWS Marketplace propose une image de serveur VPN Xray VLESS à 0,063 $ par heure sur une instance t3.micro, avec un essai gratuit de 5 jours.
Côté client, l'écosystème est fragmenté mais fiable. v2rayN et Nekoray sont les clients Windows dominants. v2rayNG, NekoBox et Hiddify couvrent Android. Hiddify est également multiplateforme et compatible avec macOS et Linux. Sur iOS, où la politique de l'App Store d'Apple complique la tâche, Streisand est l'option gratuite, tandis que Shadowrocket ou V2Box sont payantes. Tous utilisent le protocole VLESS ; la plupart prennent en charge REALITY. La configuration est généralement importée via un schéma d'URI `vless://`, une URL unique contenant l'UUID, l'adresse, le port, le transport et les paramètres REALITY, ou scannée comme un code QR depuis le panneau côté serveur.
Performance, risques et cas où VLESS n'est pas l'outil approprié
La performance avant tout. Les tests comparatifs de la communauté indiquent que VLESS offre un débit environ 15 à 25 % supérieur à celui de VMess sur le même protocole de transport, principalement grâce à un en-tête VLESS beaucoup plus court et à l'absence de chiffrement interne. Avec XTLS Vision et l'optimisation de l'assemblage Linux, un déploiement VLESS bien configuré atteint un débit proche de celui du protocole TCP natif, limité uniquement par la bande passante du VPS et le temps d'aller-retour vers le serveur. WireGuard reste 2 à 3 % plus rapide sur les réseaux non censurés, où son protocole d'établissement de liaison ne constitue pas un inconvénient.
Les risques sont réels. Le protocole VLESS est neutre et open source, mais le statut légal de son utilisation pour contourner la censure d'État varie considérablement selon les juridictions. La loi fédérale russe sur les outils de contournement criminalise la promotion de configurations fonctionnelles plutôt que l'usage personnel ; la réglementation chinoise est plus stricte et plus arbitraire ; l'Iran poursuit les opérateurs de grands pools de serveurs proxy. Les réseaux d'entreprise interdisent souvent tout trafic proxy et VPN. Les utilisateurs de ces environnements doivent connaître la réglementation en vigueur avant toute configuration. Les applications VPN gratuites proposant des abonnements VLESS préinstallés relèvent d'une catégorie réglementaire distincte dans certaines juridictions et peuvent faire l'objet d'un contrôle différent.
Un dernier point, moins dramatique : si vous n’êtes pas connecté à un réseau censuré, VLESS est superflu. Pour une protection de votre vie privée contre la censure de votre FAI via une connexion sécurisée, WireGuard ou une configuration OpenVPN moderne sont plus rapides, plus simples et déjà pris en charge par tous les fournisseurs de VPN commerciaux. VLESS+REALITY est un outil conçu pour un problème spécifique ; l’utiliser pour un autre problème ne fait généralement qu’ajouter de la complexité.
