# VLESS, VMess, Trojan ou Shadowsocks : lequel utiliser

HTML: https://v2rc.app/fr/learn/choosing-a-protocol/ · Dernière vérification: 2026-11-06

En quoi VLESS, VMess, Trojan et Shadowsocks diffèrent sur le réseau, lequel tient sur les réseaux restrictifs et que demander d’abord. Avec ce que v2rc importe.

Un client V2Ray ne choisit pas de protocole à votre place. C’est la configuration que vous importez qui en décide, et elle vient de votre fournisseur ou de votre propre serveur. La question pratique est donc : que demander, ou que mettre en place ? Cet article explique les différences qui comptent et se termine par une courte recommandation.

> **Réponse courte.** Si vous avez le choix et que le réseau est restrictif, commencez par VLESS avec REALITY sur TCP, port 443, avec le flux `xtls-rprx-vision`. Gardez une seconde configuration d’un autre type, comme Trojan ou VLESS sur TLS et WebSocket, en solution de repli. Sur un réseau ouvert, presque tout fonctionne. Aucun choix n’est définitif : les censeurs s’adaptent, et ce qui marche ce mois-ci peut ne plus marcher le mois prochain.

## Trois couches, pas un seul choix

« VLESS ou VMess » ressemble à une seule décision. Il y en a trois :

- **Protocole** : comment le client s’authentifie et à quoi ressemblent les données transportées (VMess, VLESS, Trojan, Shadowsocks).
- **Transport** : comment les octets circulent (TCP simple, WebSocket, gRPC et autres).
- **Sécurité** : ce qui enveloppe la connexion (rien, TLS ou REALITY).

Un même protocole peut être presque invisible ou facile à repérer selon les deux autres couches. Ce que voit un censeur dépend surtout du transport et de la sécurité.

## Ce qu’un censeur peut voir

- **Des octets d’apparence aléatoire.** Shadowsocks et VMess sur TCP simple n’ont pas d’en-tête reconnaissable. C’est en soi un signal : depuis fin 2021, le Grand Pare-feu de Chine bloque les connexions dont le premier paquet ressemble à des données entièrement chiffrées. L’[article sur la Chine](https://v2rc.app/fr/learn/china/) donne les détails.
- **Un handshake TLS.** Trojan, ainsi que VLESS ou VMess sur TLS, ressemblent à du HTTPS. Un censeur peut tout de même vérifier le nom du serveur, l’adresse IP, le certificat et le comportement de la connexion.
- **Un handshake emprunté.** REALITY imite le handshake TLS d’un vrai site web que vous choisissez. Une sonde qui ne détient pas la clé est transmise à ce vrai site et voit ses vraies pages. Vous n’avez besoin ni de nom de domaine ni de certificat à vous.

## Les quatre protocoles côte à côte

| | VMess | VLESS | Trojan | Shadowsocks |
|---|---|---|---|---|
| Chiffre lui-même les données | Oui | Non, s’appuie sur TLS ou REALITY | Non, s’appuie sur TLS | Oui |
| Ressemble, par défaut, à | Des octets aléatoires sur TCP simple | Dépend de la sécurité : octets aléatoires, TLS ou REALITY | Du HTTPS | Des octets aléatoires |
| Exige votre propre domaine et certificat | Seulement avec TLS | Seulement avec TLS, pas avec REALITY | Oui | Non |
| Échoue si l’horloge est fausse | Oui | Non | Non | Non |
| S’importe dans v2rc | Oui | Oui | Oui | Oui |

- **VMess** est le protocole V2Ray d’origine. Il s’authentifie avec un UUID et un horodatage, c’est pourquoi une horloge de téléphone ou de serveur décalée de quelques minutes le fait échouer sans message d’erreur. Utilisez alterId 0 (le mode AEAD) ; un alterId différent de 0 relève de l’ancien mode.
- **VLESS** est le successeur plus léger. Il ne chiffre rien lui-même : sa confidentialité est celle de la couche sous-jacente. Utilisez-le avec TLS ou REALITY, jamais avec la sécurité `none` à travers l’Internet ouvert.
- **Trojan** copie le HTTPS : un mot de passe à l’intérieur d’une connexion TLS ordinaire. Un client qui ne connaît pas le mot de passe se voit présenter une page web normale à la place. Il faut un vrai certificat pour un vrai domaine, et un domaine peut être bloqué.
- **Shadowsocks** est un proxy chiffré établi de longue date et le plus simple à exploiter. Utilisez un chiffrement AEAD ; les anciens chiffrements par flux comme `rc4-md5` ou `aes-256-cfb` sont faibles. Sans plug-in ni surcouche, son trafic est de type entièrement chiffré.

## Ce qu’apportent REALITY et Vision

Dans une configuration REALITY, vous verrez `security=reality`, un nom de serveur (`sni`), une clé publique (`pbk`) et un short ID (`sid`). Le nom de serveur doit être un vrai site web qui prend en charge TLS 1.3 et HTTP/2 ; la [documentation de REALITY](https://github.com/XTLS/REALITY) demande exactement cela.

`flow=xtls-rprx-vision` est le flux Vision. Une connexion TLS transportée à l’intérieur d’une autre connexion TLS laisse un motif reconnaissable ; la littérature de recherche l’appelle TLS-in-TLS, et [Xue et al. (USENIX Security 2024)](https://www.usenix.org/conference/usenixsecurity24/presentation/xue) ont montré que de tels motifs peuvent trahir des proxys obfusqués. Vision a été conçu pour atténuer ce motif pour le trafic qui est lui-même du HTTPS.

Ni l’un ni l’autre n’est magique. L’adresse IP et le réseau d’hébergement de votre serveur comptent toujours, et REALITY ne cache pas qu’une connexion part vers l’adresse d’un centre de données à l’étranger.

## Que demander

1. **Sur un réseau restrictif** (Russie, Iran, Chine et similaires) : VLESS avec REALITY et Vision sur TCP, port 443.
2. **Une seconde configuration d’un autre type :** Trojan, ou VLESS sur TLS avec WebSocket ou gRPC, éventuellement derrière un CDN. Un CDN masque l’adresse IP de votre serveur, mais cela suppose que le CDN lui-même soit joignable et non bridé là où vous êtes.
3. **Sur un réseau ouvert :** n’importe lequel des quatre. Utilisez ce que votre fournisseur prend déjà en charge.
4. **Si votre fournisseur vous donne un abonnement :** vous ne choisissez pas, mais vous pouvez lire les liens pour savoir ce que vous avez reçu. Voir [comment lire un lien de configuration](https://v2rc.app/fr/learn/read-a-config-link/).
5. **Gardez au moins deux configurations d’hébergeurs différents.** Quand l’une échoue, il vous faut une autre adresse IP et, idéalement, un autre protocole, pas une autre configuration du même serveur.

## Ce que v2rc peut et ne peut pas importer

v2rc importe VMess, VLESS (REALITY compris), Shadowsocks et Trojan depuis un lien, un fichier JSON V2Ray, le presse-papiers ou une URL d’abonnement. Il n’importe pas Hysteria 2, TUIC, WireGuard, AmneziaWG ni NaiveProxy. Les quatre premiers fonctionnent sur UDP, dont de nombreux réseaux restrictifs abandonnent les paquets ; NaiveProxy fonctionne sur HTTPS mais exige son propre client. Pour ceux-là, il vous faut une autre app.

v2rc n’inclut aucun serveur : vous apportez vos propres configurations. Smart Connect choisit la configuration la plus rapide et vérifie que le tunnel laisse vraiment passer le trafic avant de basculer.

## Sources

- [Documentation de REALITY](https://github.com/XTLS/REALITY) et [exemples de configuration Xray](https://github.com/XTLS/Xray-examples)
- [Description du protocole Trojan](https://trojan-gfw.github.io/trojan/protocol)
- [Spécification AEAD de Shadowsocks](https://shadowsocks.org/doc/aead.html)
- Xue, Kallitsis, Houmansadr, Ensafi : [Fingerprinting Obfuscated Proxy Traffic with Encapsulated TLS Handshakes](https://www.usenix.org/conference/usenixsecurity24/presentation/xue), USENIX Security 2024
- Wu et al. : [How the Great Firewall of China Detects and Blocks Fully Encrypted Traffic](https://gfw.report/publications/usenixsecurity23/en/), USENIX Security 2023