Français
Guide VLESS + Reality : Configuration de Proxy Sécurisé
Mots-clés
Avant de commencer la configuration, voici les termes clés qui nécessitent probablement une clarification dans ce guide.
| Mot-clé | Définition |
|---|---|
| 🔐 VLESS | Un protocole proxy léger de l’écosystème V2Ray/Xray qui authentifie les utilisateurs avec un UUID et est généralement associé à des transports de dissimulation modernes comme Reality. |
| 🔀 Proxy vs VPN | Un proxy achemine généralement le trafic applicatif via un serveur, tandis qu’un VPN traditionnel crée généralement un tunnel réseau virtuel complet pour l’appareil ou le système. |
| 🎭 Reality | Un mécanisme de transport de dissimulation pour Xray qui rend le trafic beaucoup plus proche du HTTPS normal en utilisant des empreintes TLS imitant les navigateurs et une validation basée sur des clés spéciales. |
| 🔍 DPI (Deep Packet Inspection) | Une technique de filtrage réseau qui analyse les motifs de paquets, les poignées de main et les empreintes de protocole pour identifier et bloquer le trafic tel que les VPN et les proxies. |
| 🖥️ VPS | Un serveur privé virtuel que vous louez et contrôlez à distance, qui agit comme la machine hôte pour votre configuration VLESS + Reality. |
| ⚙️ 3x-ui | Un panneau de gestion basé sur le web pour Xray qui vous permet de créer des inbounds, des utilisateurs et des paramètres Reality sans éditer manuellement JSON. |
| 🚀 Xray | Le moteur proxy principal fonctionnant sous 3x-ui qui gère réellement VLESS, Reality, le routage et les connexions clients. |
| 🆔 UUID | Un identifiant unique attribué à chaque client et utilisé par VLESS comme valeur d’authentification principale. |
| 🌐 SNI | Server Name Indication, un champ TLS qui indique au serveur quel nom d’hôte est demandé et doit correspondre correctement à la configuration de la cible Reality. |
| 🧬 Paire de clés x25519 | La paire de clés publique/privée utilisée par Reality afin que les clients approuvés puissent établir la connexion tandis que les sondes indésirables sont traitées différemment. |
| 🔑 Clé publique vs clé privée | La clé publique est partagée avec le client pour qu’il puisse se connecter, tandis que la clé privée reste uniquement sur le serveur et ne doit jamais être exposée. |
| 🧭 Empreinte uTLS | Une empreinte TLS client imitant un navigateur, telle que chrome, utilisée pour rendre la connexion semblable au trafic ordinaire des navigateurs. |
| 📡 Inbound | La configuration du listener côté serveur dans Xray/3x-ui qui définit comment les clients se connectent, y compris le protocole, le port, le transport et les paramètres de sécurité. |
| ⚡ BBR | Un algorithme de contrôle de congestion TCP de Google qui peut améliorer le débit et la réactivité sur certains chemins réseau VPS. |
| ✅ Validation ACME | L’étape de vérification publique utilisée par les services de certificats comme Let’s Encrypt pour confirmer que votre serveur ou domaine est accessible et autorisé à demander le certificat. |
Configuration de VLESS VPN avec Reality Stealth en 2026
La frustration est familière : vous configurez un serveur VPN, tout fonctionne parfaitement, et puis un matin vous vous réveillez pour découvrir qu’il est bloqué. La connexion qui fonctionnait hier échoue aujourd’hui. Aucun changement de votre côté, pourtant soudainement plus rien ne marche. Ce n’est pas un scénario hypothétique—c’est la réalité d’utiliser des protocoles VPN traditionnels en 2026, où la technologie d’inspection approfondie des paquets a évolué pour identifier et bloquer même le trafic correctement chiffré.
La solution n’est pas un algorithme de chiffrement différent ou un protocole plus rapide—c’est une approche fondamentalement différente de la façon dont votre trafic apparaît sur le réseau. VLESS combiné avec le protocole de furtivité Reality est l’une des approches autohébergées les plus efficaces disponibles en 2026 pour faire ressembler le trafic proxy beaucoup plus à du trafic HTTPS ordinaire. Ce guide vous accompagne dans le déploiement de votre propre serveur VLESS + Reality en utilisant le panneau de contrôle 3x-ui, de la compréhension du fonctionnement de cette approche à l’obtention d’une connexion fonctionnelle sur votre appareil.
Le Problème : Pourquoi les VPN Standard Sont Bloqués
L’époque où un simple serveur OpenVPN ou WireGuard fonctionnait de manière fiable pendant des mois—voire des années—est révolue. La technologie d’Inspection Approfondie des Paquets (DPI) a considérablement progressé, et il ne s’agit plus seulement de détecter le trafic non chiffré. Les systèmes DPI modernes examinent plusieurs caractéristiques de votre trafic réseau pour identifier les connexions VPN avec une précision remarquable.
Considérez ce qui se passe lorsque vous vous connectez à l’aide d’OpenVPN ou WireGuard standard. Le trafic est chiffré, mais il a toujours une forme reconnaissable. OpenVPN expose souvent une poignée de main TLS et un motif de trafic qui ne ressemble pas à une session de navigateur ordinaire. WireGuard n’utilise pas du tout TLS, mais sa poignée de main basée sur UDP et le comportement des paquets sont toujours assez distinctifs pour se démarquer sur les réseaux filtrés. C’est comme avoir un passeport avec le mauvais code pays—le document est valide, mais les détails ne correspondent à aucun voyageur légitime.
En 2026, ce blocage se produit plus rapidement que jamais. Là où autrefois un VPN nouvellement déployé pouvait fonctionner pendant des mois avant d’être détecté, désormais les nouveaux serveurs peuvent être identifiés en quelques jours ou même en quelques heures après leur mise en ligne. Le blocage est également plus généralisé, se produisant au niveau du FAI, au niveau du réseau d’entreprise, et dans certaines juridictions, au niveau du pare-feu national. Vous avez besoin d’une solution qui ne se contente pas de chiffrer votre trafic—elle fait en sorte que votre trafic ressemble à quelque chose d’entièrement différent.
Qu’est-ce que VLESS ? Le protocole expliqué
VLESS signifie « VMess Less »—un nom qui reflète directement sa philosophie de conception. Il a été créé comme successeur plus léger et plus simple du protocole VMess, qui était le protocole de transport par défaut original du projet V2Ray. Alors que VMess regroupait le chiffrement, l’authentification et le transport dans un seul système étroitement couplé, VLESS supprime les couches inutiles et laisse un protocole de transport propre et sans état.
Voici la distinction critique : VLESS fonctionne comme un proxy, et non comme un tunnel VPN complet. Le protocole redirige votre trafic via le serveur plutôt que de créer une interface réseau virtuelle complète. Pour la plupart des utilisateurs, cette distinction est académique—le résultat fonctionnel est exactement ce que vous attendez d’un VPN : votre trafic semble provenir de l’adresse IP du serveur. Mais cette architecture proxy est précisément la raison pour laquelle VLESS fonctionne si bien avec Reality, car la surcharge de protocole plus légère permet au mécanisme de discrétion de fonctionner sans interférence.
La conception proxy signifie également moins de surcharge par rapport aux protocoles VPN traditionnels. Il n’y a pas d’interface tunnel au niveau du noyau à gérer, pas de couches de chiffrement supplémentaires au-delà de ce qui est nécessaire, et le protocole a été conçu de zéro pour fonctionner avec les mécanismes de discrétion modernes basés sur TLS. Cette simplicité est une caractéristique, non une limitation—cela signifie moins de choses qui peuvent mal tourner et moins d’empreintes digitales qui peuvent être détectées.
Comprendre la réalité : la technologie furtive
Reality est ce qui transforme VLESS d’un simple protocole proxy en quelque chose beaucoup plus difficile à distinguer du trafic web chiffré ordinaire. Le mécanisme est élégant dans sa simplicité : au lieu de chercher à cacher ce que vous faites, Reality fait en sorte que votre trafic ressemble à quelque chose d’entièrement différent.
Reality réalise ceci par une technique qui opère au niveau de la poignée de main TLS. Lorsqu’un client se connecte à votre serveur, il envoie un ClientHello TLS qui imite un vrai navigateur—en utilisant la bibliothèque uTLS pour reproduire l’empreinte digitale de Chrome, Firefox ou un autre navigateur populaire. Le serveur valide ensuite la connexion en utilisant le matériel clé de Reality et les paramètres client construits autour d’une paire de clés x25519. Si le client présente les valeurs Reality attendues, la connexion fonctionne comme un proxy VLESS. S’il ne le fait pas—ce qui se produit lorsqu’un système DPI ou une sonde active frappe votre serveur—le trafic est transféré vers un site web légitime tel que www.microsoft.com ou www.apple.com. Pour le système de sondage, votre serveur ressemble à un site web normal plutôt qu’à un point de terminaison proxy évident.
Pensez-y comme porter un uniforme. Un agent des douanes inspectant des véhicules ne contrôle pas chaque voiture en détail—il laisse passer celles qui semblent légitimes en fonction de leur immatriculation, plaques et apparence du conducteur. Votre trafic porte l’uniforme d’une grande entreprise, de sorte que l’inspecteur réseau le laisse passer sans l’inspection détaillée qui révélerait que c’est en réalité quelque chose d’autre. L’empreinte digitale uTLS est le déguisement, et l’échange de clés x25519 est la poignée de main secrète que seul votre client connaît.
Un point critique : vous n’avez pas besoin de votre propre domaine pour que cela fonctionne. Les méthodes furtives précédentes vous obligeaient à posséder un domaine et à obtenir des certificats Let’s Encrypt, ce qui créait une piste documentaire et une complexité supplémentaire. Reality ne nécessite rien d’autre qu’une adresse IP VPS. Les sites web cibles (Microsoft, Apple, Google) ont un temps d’activité proche de 100 % et supportent le protocole TLS 1.3 le plus récent, ce qui en fait des ancres parfaites pour cette technique.
Le port 443 donne à ce déguisement sa meilleure chance de se fondre. Le trafic HTTPS standard utilise normalement le port 443, donc maintenir Reality sur ce port rend la connexion beaucoup plus proche de la navigation web ordinaire. D’autres ports peuvent fonctionner techniquement, mais ils affaiblissent le camouflage car ils ne correspondent plus à la forme par défaut du trafic HTTPS quotidien.
Idées reçues courantes
Avant de poursuivre, clarifions trois idées reçues qui trompent les personnes découvrant VLESS + Reality pour la première fois.
« VLESS est un VPN. » En termes techniques, VLESS est un protocole proxy, non un VPN au sens traditionnel. Il n’y a pas d’interface TUN/TAP, pas d’adaptateur réseau virtuel, et pas de manipulation de table de routage. Cependant, d’un point de vue fonctionnel pour l’utilisateur, il offre exactement ce que vous attendriez d’un VPN : votre trafic Internet semble provenir de l’adresse IP du serveur. Cette distinction importe pour les ingénieurs réseau mais rarement pour les utilisateurs finaux.
« Reality nécessite un domaine. » C’était vrai pour les techniques de dissimulation antérieures qui utilisaient des domaines contrôlés et des certificats Let’s Encrypt. Reality a spécifiquement été conçu pour fonctionner sans aucun domaine que vous contrôlez. Il utilise l’imitation d’empreinte digitale du navigateur et l’authentification par clé x25519, ce qui signifie que vous n’avez besoin d’enregistrer, gérer ou renouveler quoi que ce soit. Configurez-le une fois et il continue de fonctionner.
« C’est inviolable. » Rien n’est inviolable. Reality est hautement résistant à la détection et au blocage car il ressemble véritablement à du trafic HTTPS normal. Mais il n’est pas immunisé contre les améliorations futures de la technologie DPI, l’empreinte digitale potentielle du protocole, ou les attaques ciblées. Ce qu’il offre, c’est la meilleure protection disponible en 2026 contre les formes les plus courantes de filtrage réseau. Traitez-le comme une solution robuste, non comme un bouclier magique.
Ce qu’il vous faut avant de commencer
Vous aurez besoin d’un VPS auprès de n’importe quel fournisseur (par exemple AvaHost), et les services similaires fonctionnent tout aussi bien. Pour des performances typiques en mono-utilisateur, un plan de base avec 1 cœur CPU et 1 Go de RAM est suffisant. Le serveur doit exécuter Ubuntu 22.04 LTS ou 24.04 LTS ; ces versions disposent du support du noyau pour les fonctionnalités réseau requises dès le départ.
L’accès root SSH est essentiel. Vous devez avoir la capacité de vous connecter à votre serveur via la ligne de commande et d’exécuter des commandes privilégiées. La plupart des fournisseurs de VPS l’offrent par défaut — vous recevrez une adresse IP, un nom d’utilisateur (généralement root) et soit un mot de passe, soit une clé SSH après le déploiement.
Pour les applications client, selon vos appareils, vous aurez besoin de : v2rayNG pour Android, v2rayN pour Windows, V2Box ou Streisand pour macOS, et Shadowrocket ou FoXray pour iOS. Nous couvrirons ces points en détail dans la section des applications client plus loin dans ce guide.
Un avantage significatif de la méthode Reality : vous n’avez pas besoin d’un domaine que vous contrôlez. De nombreuses configurations furtives vous obligent à en enregistrer et gérer un, mais Reality peut fonctionner directement à partir de l’adresse IP du VPS tout en empruntant l’apparence d’une destination TLS légitime.
Une brève note sur les considérations juridiques : Les techniques décrites dans ce guide sont destinées à des besoins légitimes de confidentialité et d’accès. Les lois de filtrage Internet varient considérablement selon la juridiction. Assurez-vous que votre utilisation de ces outils est conforme aux lois applicables dans votre région.
Préparation du serveur : BBR et bases
Avec les prérequis vérifiés, préparons le serveur. Cette phase optimise votre VPS avant l’installation de tout logiciel, garantissant des performances maximales dès le départ.
💡 CONSEIL : Utilisez BBR avant le déploiement — cela améliore souvent le débit et la latence sur les liaisons contraintes ou à latence plus élevée.
Commencez par mettre à jour les paquets système. Cela garantit que vous disposez des dernières mises à jour de sécurité et des dépendances requises :
apt update && apt upgrade -y
Cette étape peut prendre 1 à 5 minutes selon votre fournisseur VPS et la vitesse du réseau. Certains fournisseurs pré-mettent à jour leurs images lors du déploiement, donc cette opération peut se terminer rapidement sur certains systèmes.
Ensuite, activez le contrôle de congestion Google BBR. BBR (Bottleneck Bandwidth and Round-trip propagation time) est l’algorithme de contrôle de congestion de Google. Au lieu de s’appuyer principalement sur la perte de paquets comme signal, il essaie de modéliser la bande passante disponible et le temps d’aller-retour plus directement, ce qui peut améliorer le débit et la réactivité sur certaines liaisons VPS.
# Verify BBR module is available
lsmod | grep tcp_bbrSi rien n’apparaît, chargez le module manuellement :
modprobe tcp_bbr
Créez maintenant la configuration sysctl pour activer BBR de manière persistante :
cat >> /etc/sysctl.d/99-bbr.conf << 'EOF'
net.core.default_qdisc=fq
net.ipv4.tcp_congestion_control=bbr
EOF
Appliquez la configuration :
sysctl -p /etc/sysctl.d/99-bbr.conf
Vérifiez que BBR est actif :
sysctl net.ipv4.tcp_congestion_control
sysctl net.ipv4.tcp_available_congestion_controlVous devriez voir bbr comme algorithme actif.
Certains systèmes bénéficient d’un redémarrage après l’activation de BBR — cela garantit que le module se charge correctement et que toutes les optimisations réseau prennent effet :
reboot
Assurez-vous maintenant que le port 443 est accessible. Si vous prévoyez d’utiliser le flux Let’s Encrypt intégré de l’installateur 3x-ui pour le panneau, autorisez également 80/tcp — ce port est utilisé pour la validation du certificat ACME, et non pour le panneau lui-même. Si votre fournisseur VPS dispose également d’une couche de pare-feu cloud ou de groupe de sécurité, autorisez les mêmes ports là aussi. Sur Ubuntu, le chemin le plus sûr est généralement UFW.
# If this is a remote VPS and you're enabling UFW for the first time, allow SSH before enabling the firewall
ufw allow OpenSSH
# Allow HTTPS-style Reality traffic
ufw allow 443/tcp
# Allow ACME validation for the 3x-ui panel's built-in Let's Encrypt setup
ufw allow 80/tcp
# Review rules, then enable only if UFW is not already active
ufw status
ufw enable⚠️ AVERTISSEMENT : Le port 443 est fortement recommandé car il correspond au trafic HTTPS normal. D’autres ports peuvent techniquement fonctionner, mais ils se fondent moins naturellement et rendent la configuration plus facile à signaler.
Votre serveur est maintenant optimisé et prêt pour l’installation de 3x-ui.
Installation du panneau 3x-ui
Avant d’exécuter l’installateur, notez une exigence facile à manquer : si vous souhaitez que la configuration Let’s Encrypt intégrée de l’installateur émette un certificat SSL pour le panneau, 80/tcp doit être ouvert et accessible depuis l’Internet public. Ce port de validation ACME est distinct du port du panneau que vous choisissez lors de la configuration.
Exécutez la commande d’installation :
bash <(curl -Ls https://raw.githubusercontent.com/mhsanaei/3x-ui/master/install.sh)Les versions actuelles de l’installateur ne commencent pas par l’ancien menu numéroté Installer / Mettre à jour / Désinstaller que de nombreux tutoriels montrent encore. Au lieu de cela, le script démarre l’installation immédiatement, installe les dépendances manquantes, télécharge la dernière version, puis vous guide à travers les invites de configuration du panneau.
Un flux d’installation typique ressemble maintenant à ceci :
- Choisissez si vous souhaitez définir un port de panneau personnalisé ou laisser l’installateur en générer un aléatoire.
- Laissez l’installateur générer un nom d’utilisateur, un mot de passe et un webBasePath aléatoires.
- Choisissez comment configurer le SSL du panneau :
- 1 = Let’s Encrypt pour un domaine
- 2 = Let’s Encrypt pour l’IP du serveur
- 3 = utiliser un certificat existant
- Complétez les invites de certificat si vous utilisez le flux Let’s Encrypt intégré.
⚠️ IMPORTANT : Le port du panneau n’est pas la même chose que le port de validation ACME. Vous pourriez exécuter le panneau sur un port aléatoire tel que 13525 et toujours avoir besoin que 80/tcp soit ouvert publiquement pour que Let’s Encrypt puisse valider le certificat.
La règle importante est simple : utilisez les identifiants exacts, le chemin et l’URL imprimés par votre propre installateur, pas des hypothèses copiées à partir de tutoriels plus anciens.
Votre résultat final ressemblera davantage à ceci :
Username: GENERATED_USERNAME Password: GENERATED_PASSWORD Port: 13525 WebBasePath: RANDOM_PATH Access URL: https://YOUR_SERVER_IP:13525/RANDOM_PATH
Vérifiez que le service est en cours d’exécution :
systemctl status x-ui
Cette vérification est importante. Regardez spécifiquement la ligne du serveur web dans la sortie d’état :
- Si vous voyez Web server running HTTPS …, le SSL du panneau fonctionne correctement.
- Si vous voyez Web server running HTTP …, le panneau s’est installé avec succès mais la configuration SSL n’a pas été complétée.
Accédez au panneau en utilisant l’URL exacte, le nom d’utilisateur et le mot de passe générés par votre propre installation. Ne pas supposer que le chemin est /panel, et ne pas supposer que les identifiants sont admin/admin à moins que votre propre installation ne le dise explicitement.
💡 CONSEIL 1 : Pour afficher à nouveau les paramètres actuels du panneau et imprimer l’URL d’accès, exécutez la commande « x-ui » dans le CLI, et choisissez le numéro 10 « View Current Settings » dans la sortie du menu.
💡 CONSEIL 2 : Si l’URL d’accès ne se charge pas, assurez-vous que le port du panneau 3x-ui est ouvert sur le pare-feu de votre VPS. Par exemple, si votre panneau s’exécute sur le port « 13525 », autorisez-le avec : « ufw allow 13525/tcp ». Remplacez 13525 par le port réel que vous avez configuré pour le panneau 3x-ui.
Si l’installateur se termine mais que systemctl status x-ui affiche HTTP au lieu de HTTPS
La cause la plus courante est que 80/tcp n’était pas accessible depuis l’Internet public lors de la validation Let’s Encrypt. Dans ce cas, le panneau peut toujours s’installer et démarrer, mais l’émission du certificat échoue.
Corrigez d’abord le pare-feu :
ufw allow 80/tcp
ufw statusSi votre fournisseur VPS dispose d’une couche de pare-feu cloud ou de groupe de sécurité, autorisez également 80/tcp là-bas. Ensuite, réexécutez la configuration du certificat du panneau à partir du script de gestion 3x-ui :
x-ui
Pour un certificat de panneau basé sur l’IP, choisissez :
- 19 → 6 (Get SSL for IP Address)
Pour un certificat de panneau basé sur un domaine, choisissez :
- 19 → 1 (Get SSL (Domain))
Après l’émission du certificat, vérifiez à nouveau :
systemctl status x-ui
Vous voulez que la sortie d’état affiche Web server running HTTPS … avant de continuer.
💡 CONSEIL : Enregistrez immédiatement les identifiants générés et l’URL du panneau. Notez également que le résumé de l’installateur peut être trompeur si l’émission du certificat échoue — si le bloc final imprime une URL HTTPS mais que systemctl status x-ui affiche toujours HTTP, faites confiance à la sortie d’état du service et corrigez SSL avant de continuer.
Configuration de VLESS + Reality Inbound
Ceci est l’étape de configuration critique où votre système de type VPN est réellement créé. Dans le panneau 3x-ui, accédez à Inbounds → Add Inbound.
Configurez les champs comme suit :
| Champ | Valeur | Notes |
|---|---|---|
| Protocol | VLESS | Sélectionner dans le menu déroulant |
| Listen IP | 0.0.0.0 | Par défaut / toutes les interfaces |
| Port | 443 | Recommandé pour le camouflage HTTPS le plus naturel |
| Client → Authentication | Laisser vide / par défaut | Ne pas utiliser Get New keys pour cette configuration de base |
| Client → decryption | none | Requis pour VLESS |
| Client → encryption | none | Laisser par défaut |
| Client → Flow | xtls-rprx-vision | Définir ceci dans la sous-section Client. Si vous ne voyez pas encore ce champ, commencez par définir Transmission sur TCP (RAW) et Security sur reality. |
| Transmission | TCP (RAW) | Utiliser le transport TCP direct |
| Security | reality | Sélectionner parmi les options de sécurité |
| uTLS | chrome | Utiliser une empreinte digitale de navigateur courante |
| Target | www.microsoft.com:443 | Cible TLS 1.3 stable pour le fallback/probing |
| SNI | www.microsoft.com | Garder aligné avec Target |
| Short IDs | Générer ou utiliser la valeur par défaut du panneau | Copier une valeur générée vers le client |
| SpiderX | / | Défaut simple |
| Public Key | Générer avec Get New Cert | Copier ceci vers le client |
| Private Key | Générer avec Get New Cert | Garder ceci sur le serveur uniquement |
📋 NOTE : Laisser les autres champs visibles — tels que Total Flow, Traffic Reset, Duration, Fallbacks, Proxy Protocol, HTTP Obfuscation, Sockopt, External Proxy, Show, Xver, Max Time Diff, Min Client Ver, Max Client Ver, Sniffing, et les champs ML-DSA — à leurs valeurs par défaut pour cette configuration de base.
Enfin, cliquez sur Save pour créer l’inbound.
⚠️ AVERTISSEMENT : Le port 443 est le meilleur défaut car il correspond au trafic HTTPS ordinaire. Si vous le changez, l’inbound peut toujours fonctionner, mais il ne se fond plus aussi bien.
⚠️ AVERTISSEMENT : La cible Reality doit supporter TLS 1.3 — Microsoft, Apple et Google sont des choix sûrs. Utiliser une cible qui ne supporte pas TLS 1.3 causera l’échec de Reality, car le protocole est conçu spécifiquement pour les handshakes TLS 1.3.
La raison pour laquelle ces valeurs sont importantes : le port 443 vous donne le profil HTTPS le plus crédible, une cible TLS 1.3 stable donne aux probes un endroit légitime où atterrir, et l’empreinte digitale chrome garde le côté client aligné avec l’une des empreintes digitales de navigateur les plus courantes sur internet. Commencez simplement, obtenez un chemin fonctionnant, puis développez plus tard si vous avez besoin de plusieurs cibles.
Gestion des utilisateurs dans 3x-ui
Une fois l’inbound configuré, vous devez créer des connexions utilisateur que vos appareils utiliseront pour s’authentifier. Dans 3x-ui, accédez à Inbounds → [Cliquez sur votre menu inbound VLESS] → Add Client.
Chaque utilisateur reçoit un UUID unique (généré automatiquement), ainsi qu’une adresse e-mail pour l’identification et des limites de trafic/expiration optionnelles. Lorsque vous créez un client, le panneau génère les valeurs dont vous avez besoin pour la connexion : adresse du serveur, UUID, flux, clé publique, ID court et paramètres liés à SNI.
En appuyant sur le signe plus (« + ») de l’inbound sélectionné, la liste des utilisateurs s’affichera.
Exporter un client
Pour exporter les détails de connexion d’un seul client, commencez par développer la ligne inbound afin que le tableau des clients soit visible. Dans la ligne du client, utilisez les deux actions d’export par client :
- Icône QR → ouvre la fenêtre modale QR
- Icône Info → ouvre la fenêtre modale des détails
Celles-ci correspondent aux deux premières méthodes de partage.
Code QR : Cliquez sur l’icône QR du client. Si les abonnements sont activés, la fenêtre modale QR peut afficher deux codes QR :
- Abonnement → un code QR pour l’URL d’abonnement du client
- QR du client (étiqueté avec l’e-mail ou l’identifiant du client, tel que example@mail.com) → un code QR pour l’URI VLESS Reality direct
Le code QR d’abonnement est utile pour les clients qui prennent en charge les mises à jour automatiques. Le code QR du client est l’importation directe unique pour ce client spécifique.
Lien de partage / URL : Cliquez sur l’icône Info du client. Dans la fenêtre modale des détails, vous pouvez voir deux types d’export de texte :
- URL d’abonnement → un point de terminaison d’abonnement actualisable
- URL → l’URI VLESS Reality direct pour ce client
Utilisez le bouton de copie à côté de la section URL pour l’importation sur ordinateur de bureau.
Au minimum, un URI Reality direct utilisable doit inclure des valeurs remplies telles que :
type=tcp encryption=none security=reality sni=www.microsoft.com fp=chrome pbk=YOUR_PUBLIC_KEY sid=YOUR_SHORT_ID spx=/ flow=xtls-rprx-vision
pbk= est la clé publique Reality et appartient à l’URI VLESS direct. L’URL d’abonnement elle-même ne contiendra généralement pas pbk= car il s’agit uniquement du point de terminaison de récupération ; la configuration renvoyée contient les paramètres Reality réels.
Certaines versions de 3x-ui ont eu des bogues de lien de partage Reality où pbk= est vide. Si l’URI direct manque pbk= ou sid=, ne lui faites pas confiance aveuglément. Dans ce cas, utilisez plutôt la configuration manuelle.
Configuration manuelle : Il n’y a pas de bouton d’export « configuration manuelle » distinct. En pratique, la configuration manuelle signifie soit entrer les valeurs directement dans l’application client, soit composer et vérifier vous-même l’URI VLESS Reality final à partir des valeurs brutes. Collectez les valeurs requises à partir de :
- la fenêtre modale Infoadresse du serveur, port, UUID, flux et l’URI direct
- les paramètres Reality de l’inbound : SNI, clé publique, ID court, empreinte digitale (chrome) et SpiderX (/) si nécessaire
Vous pouvez créer plusieurs utilisateurs pour différents appareils ou différentes personnes. Chaque UUID est indépendant, donc révoquer l’accès pour un utilisateur n’affecte pas les autres.
Configuration manuelle de Xray (Résumé)
Certains utilisateurs préfèrent ne pas utiliser une interface graphique et souhaitent éditer la configuration de Xray directement. Sur une installation standard de 3x-ui sous Linux, la configuration runtime active est écrite dans /usr/local/x-ui/bin/config.json, vous pouvez donc l’inspecter ou y apporter des modifications manuelles temporaires.
Traitez ce fichier comme un artefact runtime généré, non comme la source de vérité du panel. 3x-ui reconstruit config.json à partir de ses paramètres sauvegardés en base de données, donc les éditions manuelles peuvent être écrasées au redémarrage de Xray ou lorsque vous enregistrez les modifications dans le panel.
Avant de l’éditer, créez une sauvegarde :
cp /usr/local/x-ui/bin/config.json /usr/local/x-ui/bin/config.json.bak
L’édition manuelle peut être utile pour des tests rapides ou le débogage, mais un JSON incorrect peut empêcher Xray de démarrer. Si 3x-ui répond à vos besoins, restez avec le panel pour les modifications persistantes et utilisez les éditions directes de config.json uniquement pour les cas avancés.
Applications clientes par plateforme
Pour vous connecter à votre serveur, vous aurez besoin d’un logiciel client sur vos appareils. Voici ce qui est disponible :
| Plateforme | Applications recommandées | Notes |
|---|---|---|
| Windows | v2rayN | Client GUI avec intégration à la barre système |
| macOS | V2Box, Streisand | V2Box est gratuit ; Streisand est disponible sur l’App Store |
| Android | v2rayNG, NekoBox | Les deux sont disponibles sur GitHub et F-Droid |
| iOS | Shadowrocket, FoXray, V2Box | Shadowrocket est payant ; la disponibilité de FoXray peut varier |
Pour Windows, v2rayN est le choix recommandé — il est activement maintenu, dispose d’une interface épurée et gère nativement la configuration Reality. Pour mobile, v2rayNG et V2Box supportent tous deux l’importation par code QR, ce qui rend la configuration rapide.
📋 NOTE : La disponibilité des applications clientes pour les plateformes Apple change fréquemment. Si une application listée n’est pas disponible dans votre région, consultez le site officiel du projet, la page App Store ou le chemin TestFlight avant de supposer que le problème vient du protocole lui-même.
Connexion de votre premier client
Parcourons ensemble la connexion d’un client Windows à l’aide de v2rayN — le processus est similaire sur d’autres plateformes, mais cet exemple vous donne une procédure complète.
Étape 1 : Télécharger v2rayN
Visitez https://github.com/2dust/v2rayN/releases et téléchargez la version actuelle pour Windows. En 2026, l’option la plus simple est généralement v2rayN-windows-64-desktop.zip (ou le paquet desktop équivalent actuel affiché sur la page des versions).
Étape 2 : Extraire et exécuter
Extrayez le ZIP dans un dossier (par exemple, C:v2rayN). Exécutez v2rayN.exe. Les versions desktop récentes sont généralement autonomes, vous n’avez donc généralement pas besoin d’installer un runtime .NET desktop séparé. L’application apparaît dans votre barre système.
Étape 3 : Importer la configuration
Pour cette connexion, utilisez l’URL VLESS directe de 3x-ui — celle qui commence par vless:// — et non l’URL d’abonnement. Si votre lien Reality exporté manque de valeurs requises telles que pbk= ou sid=, retournez à la section 3x-ui précédente et utilisez plutôt les valeurs manuelles des paramètres d’entrée.
Dans v2rayN, ouvrez le menu Configuration dans la zone supérieure gauche de la fenêtre. La méthode la plus simple est de copier l’URL VLESS directe de 3x-ui, puis de sélectionner Configuration → Importer les liens partagés depuis le presse-papiers. Sur la plupart des versions, vous pouvez également simplement appuyer sur Ctrl+V. Assurez-vous d’avoir d’abord copié l’URL VLESS directe, afin que l’application puisse coller la valeur.
Si l’importation depuis le presse-papiers n’est pas l’option souhaitée, le code QR ou l’importation manuelle peuvent également être utilisés.
Étape 4 : Connexion
Une fois que le client a été importé, pour activer le tunnel entre le client Windows et le serveur, appuyez sur « Activer le tunnel » en bas de l’interface v2rayN.
Étape 5 : Vérifier
Ouvrez votre navigateur et visitez https://whatismyipaddress.com/ ou https://ip.sb. L’adresse IP affichée doit être celle de votre serveur, et non votre adresse IP locale. Cela confirme que votre trafic est acheminé via le VPN.
Vérification de votre configuration
La vérification de la connexion confirme que tout fonctionne comme prévu. Au-delà de la vérification de votre adresse IP dans le navigateur, il existe quelques tests supplémentaires à exécuter.
Vérification de l’adresse IP : Visitez https://whatismyipaddress.com/ ou https://ip.sb en étant connecté. L’adresse IP affichée doit correspondre à l’adresse IP de votre serveur VPS, et non à votre adresse IP domestique ou locale.
Test de fuite DNS : Visitez https://dnsleak.com ou https://browserleaks.com/dns et exécutez le test. Un client correctement configuré ne doit pas exposer vos résolveurs DNS locaux normaux lorsque le proxy est actif.
Problèmes courants et solutions
| Problème | Cause | Solution |
|---|---|---|
| Pas de connexion | Port 443 bloqué | Vérifiez le pare-feu : ufw allow 443/tcp et la console du fournisseur cloud |
| Le panneau ne s’ouvre pas | URL incorrecte ou ancienne hypothèse /panel | Utilisez l’URL HTTPS exacte imprimée par l’installateur |
| Le lien importé ne se connecte pas | Lien Reality manquant pbk ou sid | Inspectez le lien ou passez à la configuration manuelle du client |
| Délai d’expiration de la connexion | SNI incorrect | Vérifiez que SNI correspond (www.microsoft.com) dans les paramètres du client |
| Erreur TLS | Empreinte incorrecte ou valeurs Reality non correspondantes | Définissez l’empreinte sur chrome et revérifiez SNI, clé publique et ID court |
| Vitesse lente | BBR non activé | Réactivez BBR selon la section de préparation du serveur |
| « Pas de réponse du serveur » | Pare-feu bloquant | Vérifiez à la fois le pare-feu du serveur et les groupes de sécurité du fournisseur cloud |
Si vous rencontrez des problèmes, vérifiez que la configuration de votre client correspond exactement à ce qui a été généré dans 3x-ui — l’UUID, SNI, clé publique, ID court et flux doivent tous correspondre entre le
Étapes suivantes et options avancées
Vous disposez maintenant d’un VPN VLESS + Reality fonctionnel. À partir de là, plusieurs améliorations sont disponibles :
Ajouter une entrée de secours avec prudence : Si vous avez réellement besoin d’un basculement, vous pouvez ajouter quelque chose comme VMess + WebSocket en tant qu’entrée secondaire. N’oubliez pas que chaque entrée supplémentaire augmente la complexité et vous donne une surface de plus à sécuriser et à dépanner.
Mise à l’échelle pour plusieurs utilisateurs : Créez des clients supplémentaires dans 3x-ui pour les membres de la famille ou les appareils. Chacun obtient un UUID unique, et vous pouvez suivre l’utilisation séparément.
Optimisation des performances : BBR est déjà activé, mais vous pouvez explorer l’optimisation TCP/UDP, le réglage des tampons réseau et le réglage TCP côté serveur pour des améliorations marginales.
Cibles SNI alternatives : Bien que Microsoft/Apple/Google soient fiables, certains utilisateurs préfèrent www.oracle.com ou d’autres cibles. Le principe reste le même : tout site disposant de certificats TLS 1.3 valides fonctionne.
Sécurité du panneau : Limitez le port du panneau à votre propre adresse IP d’administrateur si possible, renouvelez les identifiants si vous les avez choisis manuellement, et envisagez d’installer Fail2Ban pour protéger le panneau contre les tentatives de force brute.
Conclusion
VLESS + Reality est une option auto-hébergée solide pour 2026 si vous avez besoin d’une configuration qui se fond mieux que les protocoles VPN traditionnels. Son avantage n’est pas une invisibilité magique ; c’est que le trafic ressemble beaucoup plus à du trafic web chiffré ordinaire que les connexions de style OpenVPN ou WireGuard ne le font sur les réseaux fortement filtrés.
Si vous comprenez le modèle mental—empreinte TLS de type navigateur, matériel de clé Reality, une cible crédible et un port HTTPS standard—vous aurez beaucoup plus de facilité à déployer, déboguer et maintenir la configuration. À partir de là, les étapes naturelles suivantes sont le renforcement de la sécurité du panneau, l’ajout de plus d’appareils clients et la validation des cibles et applications clients qui fonctionnent le mieux pour votre propre environnement. Pour l’hébergement, des fournisseurs comme AvaHost peuvent vous offrir une base stable pour exécuter votre configuration VLESS + Reality, en assurant un temps d’activité fiable et une gestion simple.
Articles connexes
