Configuration de Proxy Sécurisé - Guide VLESS + Reality

Mots-clés

Avant de plonger dans la configuration, voici les termes clés qui nécessitent probablement des éclaircissements 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 souvent associé à des transports furtifs modernes comme Reality.
🔀 Proxy vs VPN	Un proxy redirige généralement le trafic d’application via un serveur, tandis qu’un VPN traditionnel crée généralement un tunnel de réseau virtuel complet pour l’appareil ou le système.
🎭 Reality	Un mécanisme de transport furtif pour Xray qui rend le trafic beaucoup plus proche du HTTPS normal en utilisant des empreintes TLS semblables à celles des navigateurs et une validation spéciale basée sur des clés.
🔍 DPI (Inspection approfondie des paquets)	Une technique de filtrage de réseau qui analyse les modèles de paquets, les échanges 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 le JSON.
🚀 Xray	Le moteur proxy central qui fonctionne sous 3x-ui et 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 principale d’authentification.
🌐 SNI	Server Name Indication, un champ TLS qui indique au serveur quel nom d’hôte est demandé et doit correspondre correctement à la configuration cible de 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 afin 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 de client TLS imitant un navigateur, comme chrome, utilisée pour faire ressembler la connexion à un trafic de navigateur ordinaire.
📡 Inbound	La configuration d’écoute 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	La vérification publique utilisée par des 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 constater qu’il est bloqué. La connexion qui fonctionnait hier échoue aujourd’hui. Aucun changement de votre part, et pourtant soudainement rien ne fonctionne. Ce n’est pas un scénario hypothétique – c’est la réalité de l’utilisation 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 furtif Reality est l’une des approches auto-hébergées les plus efficaces disponibles en 2026 pour faire en sorte que le trafic proxy ressemble beaucoup plus à un 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 de pourquoi cette approche fonctionne à l’établissement d’une connexion fonctionnelle sur votre appareil.

Le Problème : Pourquoi les VPN Standards sont Bloqués

Les jours où un simple serveur OpenVPN ou WireGuard fonctionnait de manière fiable pendant des mois – voire des années – sont révolus. La technologie d’inspection approfondie des paquets (DPI) a considérablement avancé, 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.

La DPI examine plusieurs éléments lors de l’inspection de votre trafic. Les tailles de paquets révèlent des motifs qui ne correspondent pas à une navigation web normale – les protocoles VPN traditionnels produisent des distributions de taille de paquet distinctives que des algorithmes entraînés peuvent reconnaître. Les motifs de timing sont également importants ; l’intervalle entre les paquets dans un échange VPN diffère du comportement légitime d’un navigateur. Et lorsque qu’un protocole utilise TLS, son empreinte TLS est importante : si votre client initie une connexion avec des paramètres qui ne correspondent à aucun vrai navigateur, le système peut le signaler.

Considérez ce qui se passe lorsque vous vous connectez en utilisant OpenVPN ou WireGuard standard. Le trafic est chiffré, mais il a toujours une forme reconnaissable. OpenVPN expose souvent un échange TLS et un motif de trafic qui ne ressemble pas à une session de navigateur ordinaire. WireGuard n’utilise pas du tout TLS, mais son comportement d’échange et de paquet basé sur UDP est encore suffisamment distinctif pour se démarquer sur des réseaux filtrés. C’est comme avoir un passeport avec le mauvais code de 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ù un VPN nouvellement déployé pouvait fonctionner pendant des mois avant d’être détecté, de nouveaux serveurs peuvent maintenant être identifiés en quelques jours, voire quelques heures après leur mise en ligne. Le blocage est également plus omniprésent, se produisant au niveau des FAI, au niveau des réseaux 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 doit faire en sorte que votre trafic ressemble à quelque chose de complètement 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 un successeur plus léger et plus simple au protocole VMess, qui était le protocole de transport par défaut original dans le projet V2Ray. Alors que VMess regroupait le chiffrement, l’authentification et le transport en un seul système étroitement couplé, VLESS élimine les couches inutiles et laisse un protocole de transport propre et sans état.

Contrairement à son prédécesseur VMess, VLESS n’a pas de dépendance temporelle. VMess nécessitait des horloges synchronisées entre le client et le serveur et utilisait un mécanisme AlterID qui est devenu une empreinte reconnaissable. VLESS élimine ces deux exigences, le rendant plus léger et plus simple à configurer. Le mécanisme d’authentification utilise UUID (Identifiant Universel Unique) – le même format que vous rencontrez dans les systèmes d’authentification standard, ce qui le rend familier à utiliser.

Voici la distinction critique : VLESS fonctionne comme un proxy, pas 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 furtif 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 de 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 dès le départ pour fonctionner avec des mécanismes furtifs modernes basés sur TLS. Cette simplicité est une caractéristique, pas une limitation – cela signifie moins de choses qui peuvent mal tourner et moins d’empreintes qui peuvent être détectées.

Comprendre Reality : La Technologie Furtive

Reality est ce qui transforme VLESS d’un autre protocole proxy en quelque chose de beaucoup plus difficile à distinguer du trafic web chiffré ordinaire. Le mécanisme est élégant dans sa simplicité : au lieu d’essayer de cacher ce que vous faites, Reality fait en sorte que votre trafic ressemble à quelque chose de complètement différent.

Reality y parvient grâce à une technique qui opère au niveau de l’échange TLS. Lorsque un client se connecte à votre serveur, il envoie un TLS ClientHello qui imite un vrai navigateur – utilisant la bibliothèque uTLS pour reproduire l’empreinte 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 clients construits autour d’une paire de clés x25519. Si le client présente les valeurs Reality attendues, la connexion se poursuit comme un proxy VLESS. Si ce n’est pas le cas – ce qui se produit lorsque un système DPI ou une sonde active touche votre serveur – le trafic est redirigé vers un site web cible 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 garde-frontière inspectant des véhicules ne vérifie pas chaque voiture en profondeur – il laisse passer celles qui semblent légitimes en fonction de leur enregistrement, de leurs plaques et de l’apparence du conducteur. Votre trafic porte l’uniforme d’une grande entreprise, donc l’inspecteur réseau le laisse passer sans l’inspection détaillée qui révélerait qu’il s’agit en réalité de quelque chose d’autre. L’empreinte 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 exigeaient que vous possédiez un domaine et obteniez des certificats Let’s Encrypt, ce qui créait une traçabilité et une complexité supplémentaires. Reality ne nécessite rien d’autre qu’une adresse IP VPS. Les sites cibles (Microsoft, Apple, Google) ont un temps de disponibilité proche de 100 % et prennent en charge le dernier protocole TLS 1.3, ce qui en fait des ancres parfaites pour cette technique.

Le port 443 donne à ce déguisement la meilleure chance de se fondre. Le trafic HTTPS standard utilise normalement le port 443, donc garder 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

Avant de continuer, abordons trois idées reçues qui piègent les personnes explorant VLESS + Reality pour la première fois.

“VLESS est un VPN.” En termes techniques, VLESS est un protocole proxy, pas 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, du point de vue fonctionnel de l’utilisateur, il fournit exactement ce que vous attendez d’un VPN – votre trafic Internet semble provenir de l’adresse IP du serveur. La distinction est importante pour les ingénieurs réseau mais n’a que peu d’importance pour les utilisateurs finaux.

“Reality a besoin d’un domaine.” Cela était vrai pour les techniques furtives antérieures qui utilisaient des domaines auto-propriés et des certificats Let’s Encrypt. Reality a été spécifiquement conçu pour fonctionner sans aucun domaine que vous contrôlez. Il utilise l’imitation d’empreintes de navigateur et l’authentification par clé x25519, ce qui signifie que vous n’avez pas besoin d’enregistrer, de gérer ou de 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 réellement à un trafic HTTPS normal. Mais il n’est pas immunisé contre les améliorations futures de la technologie DPI, le fingerprinting de protocole potentiel ou les attaques ciblées. Ce qu’il fournit est la meilleure protection disponible en 2026 contre les formes les plus courantes de filtrage réseau. Considérez-le comme une solution robuste, pas comme un bouclier magique.

Ce dont vous avez besoin avant de commencer

Ceci est une liste de contrôle pratique. Avant de commencer l’implémentation, vérifiez que vous avez tout en place. Cela évite de se retrouver à mi-chemin de l’installation seulement pour découvrir qu’il vous manque un composant critique.

Vous aurez besoin d’un VPS de n’importe quel fournisseur (c’est-à-dire AvaHost), et des services similaires fonctionnent tous très bien. Pour des performances typiques d’utilisateur unique, 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 ont un support du noyau pour les fonctionnalités réseau requises dès le départ.

L’accès SSH root 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 offrent cela 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 clientes, 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 détails dans la section des applications clientes plus tard 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 exigent que vous enregistriez et gériez un domaine, mais Reality peut fonctionner directement à partir de l’adresse IP VPS tout en empruntant l’apparence d’une destination TLS légitime.

Une brève note sur les considérations légales : Les techniques décrites dans ce guide sont destinées à des besoins légitimes de confidentialité et d’accès. Les lois sur le filtrage Internet varient considérablement selon les juridictions. 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 d’installer tout logiciel, garantissant des performances maximales dès le départ.

💡 CONSEIL : Utilisez BBR avant de déployer – cela améliore souvent le débit et la latence sur des liens contraints ou à latence plus élevée.

Tout d’abord, mettez à jour vos paquets système. Cela garantit que vous avez les dernières mises à jour de sécurité et les dépendances requises :
apt update && apt upgrade -y
Cette étape peut prendre 1 à 5 minutes selon votre fournisseur de VPS et la vitesse du réseau. Certains fournisseurs pré-mettent à jour leurs images lors du déploiement, donc cela pourrait se terminer rapidement sur certains systèmes.

Ensuite, activez le contrôle de congestion BBR de Google. BBR (Bottleneck Bandwidth and Round-trip propagation time) est l’algorithme de contrôle de congestion de Google. Au lieu de se fier principalement à la perte de paquets comme signal, il essaie de modéliser la bande passante disponible et le temps de propagation aller-retour plus directement, ce qui peut améliorer le débit et la réactivité sur certains liens VPS.
# Verify BBR module is available lsmod | grep tcp_bbr
Si rien n’apparaît, chargez le module manuellement :
modprobe tcp_bbr

Maintenant, créez 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_control
Vous devriez voir bbr comme l’algorithme actif.

Certains systèmes bénéficient d’un redémarrage après avoir activé BBR – cela garantit que le module se charge correctement et que toutes les optimisations réseau prennent effet :
reboot
Maintenant, assurez-vous 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, pas pour le panneau lui-même. Si votre fournisseur de VPS a également un pare-feu cloud ou une couche 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 fonctionner techniquement, 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

Le panneau de contrôle web 3x-ui fournit une interface graphique pour gérer votre serveur VLESS + Reality. Il gère une grande partie de la configuration Xray pour vous et facilite la génération de clés par rapport à l’édition manuelle du JSON. Nous utiliserons le fork MHSanaei, qui est activement maintenu et prend en charge les protocoles actuels, y compris Reality. Une mise en garde : le projet lui-même présente 3x-ui comme un panneau d’utilisation personnelle, donc considérez-le comme une couche de commodité pour l’administrateur et sécurisez le panneau soigneusement.

Avant d’exécuter l’installateur, notez une exigence facile à manquer : si vous souhaitez que le flux intégré Let’s Encrypt de l’installateur émette un certificat SSL pour le panneau, 80/tcp doit être ouvert et accessible depuis Internet public. Ce port de validation ACME est séparé 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 le menu numéroté plus ancien Installer / Mettre à jour / Désinstaller que de nombreux tutoriels montrent encore. Au lieu de cela, le script commence immédiatement l’installation, installe toutes 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 générer un port 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’adresse IP du serveur
- 3 = utiliser un certificat existant
Complétez les invites de certificat si vous utilisez le flux intégré Let’s Encrypt.

⚠️ 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 avoir toujours besoin que le 80/tcp public soit ouvert pour que Let’s Encrypt puisse valider le certificat.

La règle importante est simple : utilisez les identifiants, le chemin et l’URL exacts imprimés par votre propre installateur, pas des suppositions copiées à partir d’anciens tutoriels.

Votre sortie finale 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 fonctionne :

systemctl status x-ui

Cette vérification est importante. Regardez spécifiquement la ligne du serveur web dans la sortie de statut :

Si vous voyez Serveur web fonctionnant en HTTPS …, le SSL du panneau fonctionne correctement.
Si vous voyez Serveur web fonctionnant en HTTP …, le panneau a été 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 supposez pas que le chemin est /panel, et ne supposez pas que les identifiants sont admin/admin à moins que votre propre installation ne le dise explicitement.

💡 CONSEIL 1 : Pour voir à nouveau les paramètres actuels du panneau et imprimer l’URL d’accès, dans la CLI, exécutez la commande “x-ui” et choisissez le numéro 10 “Voir les paramètres actuels” 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 fonctionne 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 Internet public lors de la validation Let’s Encrypt. Dans ce cas, le panneau peut toujours s’installer et démarrer, mais l’émission de certificat échoue.

Réparez d’abord le pare-feu :

ufw allow 80/tcp ufw status

Si votre fournisseur de VPS a un pare-feu cloud ou une couche de groupe de sécurité, autorisez également 80/tcp là-bas. Ensuite, relancez la configuration du certificat du panneau à partir du script de gestion 3x-ui :

x-ui

Pour un certificat de panneau basé sur IP, choisissez :

19 → 6 (Obtenir SSL pour l’adresse IP)

Pour un certificat de panneau basé sur un domaine, choisissez :

19 → 1 (Obtenir SSL (Domaine))

Après l’émission du certificat, vérifiez à nouveau :

systemctl status x-ui

Vous voulez que la sortie de statut affiche Serveur web fonctionnant en HTTPS … avant de continuer.

💡 CONSEIL : Enregistrez immédiatement les identifiants et l’URL du panneau générés. Notez également que le résumé de l’installateur peut être trompeur si l’émission de certificat échoue – si le dernier bloc imprime une URL HTTPS mais que systemctl status x-ui affiche toujours HTTP, faites confiance à la sortie de statut du service et corrigez SSL avant de passer à autre chose.

Configuration de VLESS + Reality Inbound

C’est l’étape de configuration critique où votre système semblable à un VPN est réellement créé. Dans le panneau 3x-ui, naviguez vers Inbounds → Ajouter Inbound.

Configurez les champs comme suit :

Champ	Valeur	Remarques
Protocole	VLESS	Sélectionnez dans le menu déroulant
IP d’écoute	0.0.0.0	Par défaut / toutes les interfaces
Port	443	Recommandé pour le camouflage HTTPS le plus naturel
Client → Authentification	Laisser vide / par défaut	Ne pas utiliser Obtenir de nouvelles clés pour cette configuration de base
Client → déchiffrement	aucun	Requis pour VLESS
Client → chiffrement	aucun	Laisser par défaut
Client → Flux	xtls-rprx-vision	Définissez ceci dans la sous-section Client. Si vous ne voyez pas encore ce champ, définissez d’abord Transmission sur TCP (RAW) et Sécurité sur reality.
Transmission	TCP (RAW)	Utilisez le transport TCP direct
Sécurité	reality	Sélectionnez parmi les options de sécurité
uTLS	chrome	Utilisez une empreinte de navigateur commune
Cible	www.microsoft.com:443	Cible TLS 1.3 stable pour le fallback/probing
SNI	www.microsoft.com	Gardez-le aligné avec la cible
Short IDs	Générer ou utiliser le défaut du panneau	Copiez une valeur générée vers le client
SpiderX	/	Défaut simple
Clé Publique	Générer avec Obtenir un nouveau Certificat	Copiez ceci vers le client
Clé Privée	Générer avec Obtenir un nouveau Certificat	Gardez ceci uniquement sur le serveur

📋 NOTE : Laissez 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 Enregistrer pour créer l’inbound.

⚠️ AVERTISSEMENT : Le port 443 est le meilleur par 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 proprement.

⚠️ AVERTISSEMENT : La cible Reality doit prendre en charge TLS 1.3 – Microsoft, Apple et Google sont des paris sûrs. Utiliser une cible qui ne prend pas en charge TLS 1.3 fera échouer Reality, car le protocole est spécifiquement conçu pour les échanges 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 sondes un endroit légitime où atterrir, et l’empreinte chrome garde le côté client aligné avec l’une des empreintes de navigateur les plus courantes sur Internet. Commencez simple, obtenez un chemin fonctionnel, puis élargissez plus tard si vous avez besoin de plusieurs cibles.

Gestion des Utilisateurs dans 3x-ui

Avec l’inbound configuré, vous devez créer des connexions utilisateur que vos appareils utiliseront pour s’authentifier. Dans 3x-ui, naviguez vers Inbounds → [Cliquez sur votre Menu VLESS inbound] → Ajouter Client.

Chaque utilisateur obtient un UUID unique (généré automatiquement), ainsi qu’un e-mail pour 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 au SNI.

En appuyant sur le signe plus (“+”) du inbound sélectionné, la liste des utilisateurs apparaîtra.

Exporter un client

Pour exporter les détails de connexion d’un seul client, développez d’abord la ligne inbound afin que la table des clients soit visible. Dans la ligne du client, utilisez les deux actions d’exportation par client :

Icône QR → ouvre la modal QR
Icône Info → ouvre la modal de détails

Ceci correspond 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 modal QR peut afficher deux codes QR :

Abonnement → un QR pour l’URL d’abonnement du client
Client QR (étiqueté avec l’e-mail ou l’identifiant du client, tel que example@mail.com) → un QR pour l’URI VLESS Reality direct

Le QR d’abonnement est utile pour les clients qui prennent en charge les mises à jour automatiques. Le QR client est l’importation directe unique pour ce client spécifique.

Partager le Lien / URL : Cliquez sur l’icône Info du client. Dans la modal de détails, vous pouvez voir deux types d’exportation de texte :

URL d’abonnement → un point de terminaison d’abonnement rafraîchissable
URL → l’URI VLESS Reality direct pour ce client

Utilisez le bouton de copie à côté de la section URL pour l’importation de bureau.

Au minimum, une URI Reality directe utilisable devrait inclure des valeurs peuplées 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 elle n’est que le point de récupération ; la configuration retournée contient les paramètres Reality réels.

Certaines versions de 3x-ui ont eu des bugs 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’exportation “configuration manuelle” séparé. En pratique, la configuration manuelle signifie soit entrer les valeurs directement dans l’application cliente, soit composer et vérifier vous-même l’URI VLESS Reality final à partir des valeurs brutes. Collectez les valeurs requises à partir de :

la modal Info : adresse du serveur, port, UUID, flux, et l’URI direct
les paramètres Reality de l’inbound : SNI, clé publique, ID court, empreinte (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 (Brève)

Certains utilisateurs préfèrent ne pas utiliser une interface graphique et souhaitent éditer directement la configuration de Xray. Sur une installation standard Linux 3x-ui, la configuration d’exécution active est écrite dans /usr/local/x-ui/bin/config.json, donc vous pouvez l’inspecter ou y apporter des modifications manuelles temporaires.

Traitez ce fichier comme un artefact d’exécution généré, pas comme la source de vérité du panneau. 3x-ui reconstruit config.json à partir de ses paramètres soutenus par une base de données, donc les modifications manuelles peuvent être écrasées lorsque Xray redémarre ou lorsque vous enregistrez des modifications dans le panneau.

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 du débogage, mais un JSON incorrect peut empêcher Xray de démarrer. Si 3x-ui répond à vos besoins, restez avec le panneau pour les changements persistants et utilisez les modifications directes de config.json uniquement pour des 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	Remarques
Windows	v2rayN	Client GUI avec intégration dans la zone de notification
macOS	V2Box, Streisand	V2Box est gratuit ; Streisand est sur l’App Store
Android	v2rayNG, NekoBox	Les deux 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, a une interface propre et gère la configuration Reality nativement. Pour mobile, v2rayNG et V2Box prennent tous deux en charge l’importation de code QR, ce qui rend la configuration rapide.

📋 NOTE : La disponibilité des clients sur les plateformes Apple change fréquemment. Si une application répertoriée n’est pas disponible dans votre région, vérifiez le site officiel du projet, la liste de l’App Store ou le chemin TestFlight avant de supposer que le protocole lui-même est le problème.

Connexion de Votre Premier Client

Passons en revue la connexion d’un client Windows utilisant v2rayN – le processus est similaire sur d’autres plateformes, mais cela vous donne un exemple complet.

Étape 1 : Télécharger v2rayN

Visitez https://github.com/2dust/v2rayN/releases et téléchargez la version actuelle pour bureau Windows. En 2026, l’option la plus simple est généralement v2rayN-windows-64-desktop.zip (ou le package de bureau équivalent actuel affiché sur la page de version).

Étape 2 : Extraire et Exécuter

Extrayez le ZIP dans un dossier (par exemple, C:v2rayN). Exécutez v2rayN.exe. Les versions de bureau récentes sont généralement autonomes, donc vous n’avez généralement pas besoin d’installer un runtime .NET de bureau séparé. L’application apparaît dans votre zone de notification.

Étape 3 : Importer la Configuration

Pour cette connexion, utilisez l’URL VLESS directe de 3x-ui – celle qui commence par vless:// – pas 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 inbound.

Dans v2rayN, ouvrez le menu Configuration dans la zone en haut à gauche de la fenêtre. La méthode la plus simple consiste à copier l’URL VLESS directe de 3x-ui, puis à sélectionner Configuration → Importer des liens de partage 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 : Connecter

Après 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 de v2rayN.

Étape 5 : Vérifier

Ouvrez votre navigateur et visitez https://whatismyipaddress.com/ ou https://ip.sb. L’adresse IP affichée devrait être l’adresse IP de votre serveur, pas votre IP locale. Cela confirme que votre trafic passe par 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 y a quelques tests supplémentaires qui valent la peine d’être effectués.

Vérification de l’Adresse IP : Visitez https://whatismyipaddress.com/ ou https://ip.sb pendant que vous êtes connecté. L’IP affichée devrait correspondre à l’IP de votre serveur VPS, pas à votre IP domestique ou de réseau local.

Test de Fuite DNS : Visitez https://dnsleak.com ou https://browserleaks.com/dns et effectuez le test. Un client correctement configuré ne devrait pas exposer vos résolveurs DNS locaux normaux pendant que 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 supposition /panel	Utilisez l’URL HTTPS exacte imprimée par l’installateur
Le lien importé ne se connecte pas	Le lien Reality manque pbk ou sid	Inspectez le lien ou passez à la configuration manuelle du client
Délai d’attente de connexion	SNI incorrect	Vérifiez que le 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 vérifiez à nouveau le SNI, la clé publique et l’ID court
Vitesse lente	BBR non activé	Réactivez BBR selon la section de préparation du serveur
“Pas de réponse du serveur”	Blocage du pare-feu	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 – le UUID, le SNI, la clé publique, l’ID court et le flux doivent tous correspondre entre le serveur et le client.

Prochaines Étapes & Options Avancées

Vous avez maintenant un VPN VLESS + Reality fonctionnel. À partir de là, plusieurs améliorations sont disponibles :

Ajouter un inbound de secours avec précaution : Si vous avez réellement besoin d’un fallback, vous pouvez ajouter quelque chose comme VMess + WebSocket comme inbound secondaire. N’oubliez pas que chaque inbound supplémentaire augmente la complexité et vous donne une surface de plus à sécuriser et à dépanner.

Évoluer pour plusieurs utilisateurs : Créez des clients supplémentaires dans 3x-ui pour des membres de la famille ou des 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 avec des certificats TLS 1.3 valides fonctionne.

Sécurité du panneau : Restreignez le port du panneau à votre propre IP admin si possible, faites tourner 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 à un trafic web chiffré ordinaire que les connexions de type OpenVPN ou WireGuard sur des réseaux fortement filtrés.

Si vous comprenez le modèle mental – le fingerprinting TLS semblable à un navigateur, le matériel 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 prochaines étapes naturelles consistent à renforcer la sécurité du panneau, à ajouter plus d’appareils clients, et à valider quelles cibles et applications clientes fonctionnent le mieux pour votre propre environnement. Pour l’hébergement, des fournisseurs comme AvaHost peuvent vous donner une base stable pour exécuter votre configuration VLESS + Reality, garantissant un temps de disponibilité fiable et une gestion simple.

Guide VLESS + Reality : Configuration de Proxy Sécurisé