v2rcUn lien de configuration regroupe en une seule ligne tout ce dont un client a besoin : le serveur, la clé et les réglages de transport. Savoir en lire un vous apprend ce qu’on vous a donné et pourquoi une configuration échoue. Tous les exemples ci-dessous utilisent des valeurs fictives, pas de vrais serveurs.
VLESS
vless://[email protected]:443?encryption=none&security=reality&sni=site.example&fp=chrome&pbk=PUBLIC_KEY&sid=SHORT_ID&type=tcp&flow=xtls-rprx-vision#my-config| Partie | Signification |
|---|---|
00000000-… | L’ID utilisateur (UUID). C’est la clé : quiconque le possède peut utiliser le serveur. |
server.example:443 | Adresse et port du serveur. |
encryption=none | VLESS ne chiffre rien lui-même ; la couche de sécurité protège le trafic. |
security | none, tls ou reality. |
sni | Le nom de serveur présenté dans le handshake TLS. Avec REALITY, c’est le vrai site imité. |
fp | L’empreinte TLS que le client imite, par exemple chrome. |
pbk, sid | Clé publique REALITY et short ID. Les deux doivent correspondre exactement au serveur. |
type | Transport : tcp, ws (WebSocket), grpc et d’autres. |
flow | xtls-rprx-vision est le flux Vision, utilisé avec REALITY ou TLS sur TCP. |
path, host, serviceName | Réglages du transport WebSocket ou gRPC, quand il est utilisé. |
#my-config | L’étiquette affichée dans votre liste. |
VMess
Un lien vmess:// est le préfixe suivi du Base64 d’un petit document JSON. Décodé, il ressemble à ceci :
{"v":"2","ps":"my-config","add":"server.example","port":"443","id":"00000000-0000-0000-0000-000000000000","aid":"0","scy":"auto","net":"ws","type":"none","host":"server.example","path":"/path","tls":"tls","sni":"server.example"}add et port désignent le serveur, id est l’UUID, aid est l’ancien alter ID (il doit valoir 0), net est le transport, host et path relèvent de WebSocket, tls active TLS et ps est l’étiquette. Pour en décoder un à la main, prenez le texte après vmess:// et passez-le dans base64 -d.
Shadowsocks
ss://BASE64(method:password)@server.example:8388#my-configLa partie avant le @ est le chiffrement et le mot de passe, encodés en Base64. Utilisez un chiffrement AEAD. Les anciens chiffrements par flux comme rc4-md5 ou aes-256-cfb sont faibles. Certains anciens liens encodent plutôt en Base64 l’ensemble method:password@host:port.
Trojan
trojan://[email protected]:443?security=tls&sni=server.example&type=tcp#my-configLa partie avant le @ est le mot de passe. Trojan a besoin de TLS pour protéger le trafic, donc security=tls doit être présent.
Abonnements
Une URL d’abonnement renvoie une liste de liens, généralement encodée en Base64, un par ligne. L’app la récupère, la décode et ajoute chaque lien. Quand un fournisseur remplace des serveurs bloqués, actualiser l’abonnement apporte les nouveaux.
Erreurs qui cassent un lien
Le décodeur de liens vérifie les plus courantes :
- un UUID ou un port invalide ;
- REALITY sans clé publique ni nom de serveur ;
- VLESS ou Trojan sans TLS ;
allowInsecureactivé, ce qui désactive la vérification des certificats ;- un chiffrement Shadowsocks obsolète ;
- un alter ID VMess différent de zéro.
Un seul caractère erroné dans pbk ou sid fait échouer une configuration REALITY sans aucun message. Voir pourquoi une connexion peut réussir et ne rien charger.
Un lien est un identifiant d’accès
L’UUID ou le mot de passe contenu dans un lien est la clé du serveur. Quiconque a le lien peut l’utiliser, et sur un serveur partagé cela peut entamer votre quota. Ne publiez pas de liens dans des discussions publiques ; un lien public est aussi bloqué plus tôt.
Le décodeur de ce site décode dans la page et n’envoie rien nulle part : la page n’effectue aucune requête réseau quand elle décode un lien. Malgré cela, soyez prudent avec tout outil en ligne dans lequel vous collez un lien. Vous pouvez toujours en décoder un hors ligne avec base64 -d, comme ci-dessus.
Sources
- Exemples de configuration Xray
- Documentation de REALITY
- Description du protocole Trojan
- Shadowsocks SIP002, qui définit le format des liens