La pile VLESS moderne en 2026

En 2026, VLESS reste un protocole proxy léger et sans état, mais « VLESS n’a pas de chiffrement » n’est plus une description complète. Xray-core propose désormais VLESS Encryption en option. Les déploiements peuvent aussi associer VLESS à TLS, REALITY, XTLS Vision, XHTTP et XUDP selon leur modèle de menace. Ces couches résolvent des problèmes différents et ne doivent pas être confondues en un seul protocole.

Politique de sources : ce guide s’appuie sur les sources primaires de Project X, Xray-core, sing-box et AnyTLS. Les pull requests et discussions GitHub documentent la conception et l’implémentation décidées par les mainteneurs ; ce ne sont pas des audits de sécurité indépendants. Les mentions de SingLink sont des comparaisons d’architecture, et non des affirmations selon lesquelles SingLinkVPN implémenterait ces projets.

1. La pile VLESS moderne en un coup d’œil

• VLESS : une couche légère d’identité, de commande et de destination.
• VLESS Encryption : une couche native et optionnelle de protection de la charge utile dans le Xray-core actuel.
• TLS 1.3 / REALITY : sécurité du transport externe, authentification et apparence sur le réseau.
• XTLS Vision : contrôle de flux et optimisation du chemin des données, et non un chiffrement distinct.
• RAW / XHTTP / gRPC / WebSocket : les transports qui acheminent les données du proxy.
• XUDP : une option d’encodage des paquets UDP dans l’écosystème Xray.
• XMUX et autres systèmes MUX : des moyens de partager les connexions sous-jacentes.
• Padding / FinalMask / Browser Dialer : des outils qui agissent sur la longueur, le rythme, le comportement du transport externe ou la pile réseau du navigateur.

Une connexion peut donc se modéliser ainsi : trafic applicatif → identité et destination VLESS → sécurité du protocole ou sécurité externe → contrôle de flux Vision → un transport comme RAW ou XHTTP → TCP ou UDP. Tous les modules ne sont pas nécessaires ni compatibles dans chaque conception.

2. Ce que fait le protocole VLESS de base

La documentation de Project X définit VLESS comme un protocole de transport léger et sans état, qui ne dépend pas de l’heure système et s’authentifie par un UUID ou un identifiant associé. L’implémentation publique de l’encodage dans Xray-core montre la version, l’identifiant utilisateur, les extensions (addons), la commande, le port de destination, l’adresse et les données qui suivent.

Concrètement, la couche de base répond à trois questions : qui est le client, quelle connexion est demandée et où doit-elle aller ? Le routage intelligent, la charge des nœuds, les droits liés à l’offre et la reconnexion automatique relèvent normalement de couches produit et de contrôle supérieures.

Les configurations classiques utilisent couramment `encryption: "none"`. Les recommandations actuelles de Project X exigent une sécurité de transport externe, sauf si le pair et le lien relèvent d’une infrastructure privée de confiance, ou si VLESS Encryption est activé.

3. Ce que change VLESS Encryption

VLESS Encryption est une couche de protection native et optionnelle, fusionnée dans Xray-core en 2025. La PR #5067 fusionnée et la documentation de configuration actuelle décrivent la poignée de main `mlkem768x25519plus`, les apparences `native`, `xorpub` et `random`, les comportements de session `1rtt` et `0rtt`, ainsi qu’un padding variable.

Les objectifs de conception publiés

• Dériver les clés de session par une combinaison de ML-KEM-768 et de X25519 ;
• protéger les charges utiles VLESS sans exiger de TLS externe ;
• utiliser des tickets pour les reprises ultérieures en 0-RTT et un état de courte durée pour réduire le risque de rejeu ;
• utiliser un padding variable et des modes XOR optionnels pour modifier l’apparence des longueurs fixes ou des clés publiques.

Il s’agit d’affirmations des mainteneurs sur la conception et l’implémentation. Nous n’avons trouvé aucun audit cryptographique indépendant couvrant toutes ces propriétés ; ce guide ne qualifie donc pas cette conception de « résistante à tout rejeu » ni d’« absolument sûre face au quantique ».

Ce qu’elle ne remplace pas automatiquement

VLESS Encryption protège la charge utile du protocole. Elle ne crée pas automatiquement une chaîne de certificats HTTPS ordinaire, une poignée de main de site web, un comportement HTTP/2 ou HTTP/3, ni une compatibilité CDN. Elle n’équivaut donc pas à TLS ou à REALITY.

4. TLS 1.3 et REALITY

TLS apporte une validation de certificats normalisée, l’échange de clés, l’intégrité et le chiffrement du transport. Il peut accompagner RAW, XHTTP, gRPC ou WebSocket ; la version négociée, l’ALPN et les vérifications de certificat dépendent toujours de la configuration et de ce que prend en charge le pair.

La documentation REALITY de Project X décrit une couche de sécurité de type TLS modifiée, avec les paramètres target, serverNames, les clés X25519 et shortId, plus des données de vérification ML-DSA-65 optionnelles. REALITY peut accompagner RAW, XHTTP et gRPC.

REALITY ne doit pas être réduit à « TLS sans certificat ». Son fonctionnement associe l’autorisation du client à l’apparence d’une poignée de main externe. Le résultat dépend toujours de la cible, de l’empreinte du client, du transport et de la qualité du déploiement ; il ne peut garantir l’invisibilité face à tous les classificateurs.

5. XTLS Vision n’est pas un protocole de chiffrement

La documentation VLESS/Vision classe Vision dans le contrôle de flux. Dans les conditions prises en charge, il peut reconnaître le trafic TLS interne et réduire le chiffrement ou les copies superflus. Sur les chemins Linux et TCP compatibles, le cœur peut tenter un `splice` afin que le noyau transfère directement les données.

La répartition exacte est la suivante : TLS, REALITY ou VLESS Encryption assurent la sécurité ; Vision optimise la façon dont les données protégées traversent la couche proxy. Toutes les plateformes, tous les transports et tous les types de trafic ne peuvent pas utiliser splice.

6. Les trois modes de XHTTP

La discussion de conception de XHTTP menée par les mainteneurs décrit un système de transport HTTP capable de fonctionner dans des environnements HTTP/1.1, HTTP/2 et HTTP/3 :

• packet-up : plusieurs requêtes POST montantes et une réponse descendante continue ; conçu pour une large compatibilité avec les intermédiaires.
• stream-up : un POST montant en streaming et un GET descendant en streaming distinct.
• stream-one : une seule requête bidirectionnelle en streaming ; performances et compatibilité dépendent des intermédiaires.

XHTTP peut aussi utiliser le padding d’en-têtes, des chemins d’envoi et de réception séparés, et XMUX. Son fonctionnement à travers un CDN donné dépend du mode, de la version HTTP, du comportement du proxy inverse et de la configuration du fournisseur.

7. XMUX, multiplexage général et blocage en tête de ligne

XMUX gère la concurrence de XHTTP, le nombre de connexions sous-jacentes, leur réutilisation, leur durée de vie et le keepalive. Son but n’est pas de maintenir indéfiniment une seule connexion : il équilibre le coût des poignées de main, la concurrence et les schémas de connexions longues.

La documentation du multiplexage de sing-box mentionne aussi smux, yamux et h2mux. Le multiplexage peut réduire le nombre de poignées de main, mais une perte ou un blocage sur une connexion TCP sous-jacente peut affecter plusieurs flux. HTTP/3 évite le blocage en tête de ligne entre flux au niveau TCP, mais un flux QUIC donné peut encore attendre la récupération d’une perte.

8. XUDP est une option d’encodage UDP

La documentation VLESS de sing-box cite `xudp` comme option d’encodage des paquets, aux côtés de `packetaddr` et de la désactivation de tout encodage supplémentaire. Cela permet seulement de conclure que XUDP achemine l’UDP dans cet écosystème ; ce n’est pas une spécification de paquets complète et versionnée.

Le comportement détaillé des sessions, des adresses, des limites et des migrations doit être vérifié sur la version exacte du cœur et sur son code. Ce guide évite délibérément de présenter comme une norme universelle des détails de trame déduits.

9. Padding, FinalMask, ECH et Browser Dialer

• Padding : modifie les caractéristiques de longueur ou de rythme ; ce n’est pas du chiffrement.
• FinalMask : sa documentation de configuration le situe à une étape de traitement du transport externe, avec des paramètres liés à TCP, UDP et QUIC.
• ECH : la documentation TLS de sing-box inclut la configuration d’Encrypted ClientHello pour protéger une partie du ClientHello ; ECH ne remplace pas le chiffrement du tunnel.
• Browser Dialer : selon la documentation de Project X, il laisse un vrai navigateur établir les connexions TLS et HTTP, ce qui donne un comportement de navigateur plus authentique au prix de contraintes de déploiement et de performances.

10. Ce que Fallback peut faire, et ce qu’il ne peut pas faire

La documentation Fallback de Project X montre comment un SNI, un chemin ou un trafic de protocole non reconnu peut être redirigé vers Nginx, Caddy ou un site web ordinaire, ce qui permet à un même point d’entrée d’héberger à la fois le proxy et des services ordinaires.

Fallback évite de répondre à chaque échec d’authentification par une même erreur évidente. Il ne protège pas contre le sondage actif ; la possibilité d’être reconnu dépend toujours de TLS, du transport, des réponses, du rythme et de la configuration du serveur.

11. AnyTLS est un point de comparaison, pas un composant de VLESS

Le document du protocole AnyTLS décrit l’enchaînement TCP → TLS → authentification `SHA-256(password)` → une session → plusieurs flux. Les trames contiennent Command, Stream ID, Data Length et Data, avec les commandes SYN, PSH, FIN, settings, padding, heartbeat et, en version 2, SYNACK.

Son modèle de session, ses flux multiples, son padding dynamique et ses contrôles de santé en font un point de comparaison utile. AnyTLS reste un protocole distinct ; VLESS n’hérite pas automatiquement de ces fonctions.

12. Les combinaisons courantes et leurs limites

• VLESS + REALITY + Vision + RAW : orientée vers la performance en connexion directe et une apparence externe de type TLS ; aucune dépendance à un CDN.
• VLESS + TLS/REALITY + XHTTP : orientée vers le transport sur HTTP, les proxys inverses et une compatibilité CDN sous conditions.
• VLESS Encryption + Vision : protège la charge utile du protocole pour les scénarios de relais ou de sécurité externe non standard, sans apparence HTTPS ordinaire.
• VLESS + TLS + XHTTP + Browser Dialer : utilise la pile réseau d’un vrai navigateur, avec un coût d’exploitation plus élevé.
• AnyTLS + TLS : une conception distincte de sessions/flux et de padding, et non une pile VLESS.

Aucune configuration n’est toujours la meilleure à la fois pour les performances, la compatibilité, la maintenabilité, l’apparence et la sécurité. Le choix doit partir d’un modèle de menace, du chemin réseau, des contraintes du CDN ou du proxy, des plateformes clientes et des besoins d’observabilité.

13. Ce que cela implique pour la recherche de SingLink

Les documents publics sur VLESS et AnyTLS peuvent nourrir la recherche sur l’identité, l’échange de clés, les sessions, les flux, l’UDP, le padding, le multiplexage, la reprise et la négociation de version. Cet article n’établit pas que SingLink 2.0 repose sur VLESS, REALITY, XHTTP ou AnyTLS.

SingLinkVPN doit continuer à distinguer le comportement publié, les axes de recherche et l’implémentation non divulguée. Consultez le plan open source de SingLinkVPN pour connaître le périmètre actuellement publié.

14. Questions fréquentes (FAQ)

VLESS chiffre-t-il le trafic à lui seul ?

VLESS dans sa configuration classique `encryption: "none"` ne protège pas la charge utile du protocole et exige une infrastructure privée de confiance ou une sécurité externe. Le Xray-core actuel peut activer VLESS Encryption : la réponse dépend donc de l’implémentation et de la configuration.

VLESS Encryption peut-il remplacer TLS ou REALITY ?

VLESS Encryption n’en est pas l’équivalent. Il protège les charges utiles VLESS, mais ne fournit pas automatiquement de certificat HTTPS standard, de poignée de main ni d’apparence de site web.

XTLS Vision effectue-t-il un chiffrement ?

Non. XTLS Vision assure avant tout le contrôle de flux et l’optimisation du chemin des données.

Comment choisir entre les trois modes de XHTTP ?

Parmi les trois modes de XHTTP, packet-up privilégie la compatibilité, stream-up sépare les sens de streaming et stream-one utilise un seul flux bidirectionnel. Chacun doit être testé sur le chemin réel des intermédiaires.

En quoi XUDP diffère-t-il d’un proxy UDP générique ?

XUDP est une option d’encodage UDP de l’écosystème Xray. Son comportement exact dépend du cœur et de sa version, et ne doit pas être déduit de son seul nom.

SingLink 2.0 repose-t-il sur VLESS ou sur AnyTLS ?

Les éléments publics ne suffisent pas à établir ce lien avec VLESS ou AnyTLS. Cet article est une comparaison technique, et non une divulgation d’implémentation.

15. Conclusion et date des sources

Le VLESS moderne est une pile modulaire : VLESS porte l’identité et la destination, VLESS Encryption ajoute une protection optionnelle au niveau du protocole, TLS ou REALITY fournissent la sécurité externe, Vision optimise le flux, XHTTP et XUDP acheminent le trafic, et le multiplexage ou le padding modifient encore le comportement des connexions.

Date de publication initiale : 20 mai 2026. Sources techniques revues le 28 juillet 2026. Ces projets continuent d’évoluer ; vérifiez la documentation, le journal des modifications et la compatibilité de la version exacte avant tout déploiement.