Comment installer 3x-ui et choisir la bonne configuration anti-censure
Mots-clés
Le glossaire rapide ci-dessous clarifie les termes avant le début de l’installation :
| Emoji + mot-clé | Brève explication |
|---|---|
| ⚙️ 3x-ui | Un panneau de contrôle web pour Xray-core |
| 🚀 Xray-core | Le moteur proxy réel |
| 📥 inbound | Un point d’entrée d’écoute sur le serveur |
| 🔀 transport layer | La façon dont le flux de trafic est transporté |
| 🎭 Reality | Un mécanisme de discrétion/sécurité pour Xray |
Comment installer 3x-ui sur un VPS et choisir la bonne configuration anti-censure
Un jour votre VPN fonctionne. Le lendemain, il cesse de fonctionner. Dans les réseaux restrictifs, le blocage vise souvent moins à savoir si le trafic est chiffré qu’à savoir si le trafic semble facile à classifier.

C’est la partie que de nombreux anciens tutoriels VPN oublient. Le chiffrement seul ne garantit pas la discrétion. Les réseaux peuvent toujours inspecter les modèles de poignée de main, le comportement des paquets et les empreintes digitales de protocole suffisamment bien pour décider que votre trafic ne semble pas ordinaire. La question cesse donc d’être « comment installer un VPN ? » et devient « comment faire en sorte que la forme du trafic semble assez normale pour survivre au filtrage ? »
Ce guide est l’étape fondamentale. Vous installerez un panneau 3x-ui fonctionnel sur un VPS Ubuntu, sécuriserez correctement la surface d’administration, et repartirez avec un cadre clair pour choisir ce qu’il faut configurer ensuite dans le panneau. Si vous auto-hébergez sur un petit VPS — que ce soit chez AlexHost ou un autre fournisseur — c’est là que la configuration commence à devenir gérable.
Ce qu’est réellement 3x-ui — et ce qu’il n’est pas

L’idée fausse la plus importante à corriger dès le départ est celle-ci : 3x-ui n’est pas la technologie de contournement de censure elle-même. C’est le tableau de bord. Xray est le moteur qui se trouve dessous. Les choix de protocole, de transport et de sécurité au sein de ce moteur sont ce qui détermine le comportement de votre trafic sur le réseau.
3x-ui est important car il transforme Xray d’un tas de JSON édités à la main en quelque chose qu’un humain moyen peut utiliser. Vous obtenez un panneau de contrôle web pour créer des inbounds, ajouter des clients, exporter des liens ou des codes QR, gérer les limites, mettre à jour les fichiers géo et gérer l’accès administrateur et le SSL du panneau.
Le glossaire rapide ci-dessous clarifie les termes avant le début de l’installation :
| Terme | Signification simple | Pourquoi c’est important ici |
|---|---|---|
| 3x-ui | Un panneau de contrôle web pour Xray-core | C’est la couche de gestion que vous installez dans ce guide |
| Xray-core | Le moteur proxy réel | C’est ce qui gère les protocoles, le routage et le comportement du trafic |
| inbound | Un point d’entrée d’écoute sur le serveur | C’est là que vous définissez comment les clients se connectent |
| transport | Comment le flux de trafic est transporté | Les exemples incluent TCP brut, WebSocket ou gRPC |
| Reality | Un mécanisme de discrétion/sécurité pour Xray | Il aide le trafic à ressembler davantage à du HTTPS ordinaire |
📝 Remarque : 3x-ui se comprend mieux comme une couche de gestion pour Xray-core, et le projet lui-même le présente comme un logiciel à usage personnel plutôt que comme quelque chose à traiter légèrement comme une infrastructure de production renforcée.
Cette distinction est également importante pour la sécurité. Un panneau activé en HTTPS avec des identifiants administrateur forts protège la surface de contrôle — l’endroit où vous vous connectez et gérez le serveur. Il ne rend pas automatiquement le trafic utilisateur discret. L’installation vous donne le contrôle ; la pile de protocoles choisie ensuite détermine l’apparence de la connexion sur le fil.
Avant d’installer : liste de contrôle du serveur et de l’accès

3x-ui n’a pas besoin d’un serveur énorme, mais il a besoin d’un chemin d’installation propre. Pour ce guide, la base de référence est Ubuntu 22.04 LTS ou 24.04 LTS, un accès SSH avec des privilèges root ou sudo, une adresse IP publique et des ressources modestes comme 1 vCPU et 1 GB RAM. N’importe quel VPS approprié fonctionne, y compris les plans d’entrée à bas coût, tant qu’il vous donne un accès réseau prévisible et un contrôle du pare-feu.
Avant de toucher à des commandes, vérifiez cette liste de contrôle :
- Système d’exploitation : Ubuntu 22.04 LTS ou 24.04 LTS
- Niveau d’accès : accès SSH root, ou un utilisateur avec des privilèges sudo complets
- Réseau : adresse IP publique et la capacité d’ouvrir les ports requis
- Port de trafic : 443/tcp pour le trafic proxy de style HTTPS ultérieurement
- Port de validation ACME : 80/tcp uniquement si vous voulez le flux Let’s Encrypt intégré de l’installateur pour le panneau ; ACME est la vérification de réachabilité publique utilisée pour la validation des certificats
- Réachabilité du panneau : soyez prêt pour que l’installateur attribue un port de panneau aléatoire et un webBasePath aléatoire
- État final attendu : une URL de panneau accessible, des identifiants sauvegardés et un service de panneau HTTPS vérifié
⚠️ Avertissement : Si vous activez UFW sur un VPS distant pour la première fois, autorisez SSH avant d’activer le pare-feu. Sinon, vous pouvez vous verrouiller hors du serveur que vous essayez de configurer.
Une fois que ces bases sont vraies, le reste devient simple. Les deux sections suivantes vous font passer de « J’ai un VPS » à « J’ai un panneau de contrôle fonctionnel » sans devinettes.
Préparation du serveur : BBR et bases
Les prérequis vérifiés, préparons le serveur. Cette phase optimise votre VPS avant d’installer tout logiciel VPN, 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.
Tout d’abord, mettez à jour les paquets de votre 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 comme Vultr 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, pas 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 mélangent 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
Nous utiliserons le fork MHSanaei, qui est activement maintenu et supporte les protocoles actuels. Rappel important : le projet lui-même présente 3x-ui comme un panneau à usage personnel, traitez-le donc comme une couche de commodité d’administration et sécurisez le panneau avec soin.
Avant d’exécuter le programme d’installation, notez une exigence facile à oublier : si vous souhaitez que la configuration Let’s Encrypt intégrée du programme d’installation é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 du programme d’installation ne commencent pas par le menu numéroté Installer / Mettre à jour / Désinstaller plus ancien 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 le programme d’installation en générer un aléatoire.
- Laissez le programme d’installation 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 avoir toujours besoin que 80/tcp public soit ouvert 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 programme d’installation, et non 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 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 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 le programme d’installation 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 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é du programme d’installation 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.
La carte mentale de la décision : où le « contournement de la censure » commence réellement

Une fois le panneau installé, le problème change. Vous ne cherchez plus à installer le logiciel correctement. Vous décidez comment le trafic client doit se présenter au réseau. C’est là que le « configurer pour contourner la censure » commence réellement.
Le moyen le plus simple de réduire le fouillis terminologique est de penser en trois couches : comment le client et le serveur communiquent, comment le flux est transporté, et comment ce trafic apparaît à un observateur externe. Sinon, si vous aplatissez cela en une seule liste de termes à la mode, 3x-ui semble beaucoup plus compliqué qu’il ne l’est réellement.
| Couche | À quelle question elle répond | Exemples courants |
|---|---|---|
| Protocole | Comment le client et le serveur s’identifient-ils et communiquent-ils entre eux ? | VLESS, Trojan, VMess, Shadowsocks |
| Transport | Comment le flux de trafic est-il transporté ? | TCP (RAW), WebSocket, gRPC, QUIC |
| Sécurité / obfuscation | À quoi ressemble le trafic pour le réseau ? | Reality, TLS, empreintes digitales ressemblant à un navigateur, piles ressemblant à du domain fronting |
Prenez un exemple d’ancrage : VLESS + TCP/RAW + Reality sur 443. VLESS est le protocole. TCP/RAW transporte le flux. Reality façonne la façon dont la connexion ressemble à un comportement HTTPS ordinaire. Et 443 importe parce que le camouflage fonctionne mieux quand il correspond aussi au port par défaut du trafic web chiffré normal. À certains endroits, la documentation Xray dit raw tandis que l’interface du panneau dit TCP ; pour cet article, traitez-les comme le même choix de transport conceptuel.
⚠️ Avertissement : Il n’y a pas de gagnant universel et aucune combinaison définitivement incontournable. Les réseaux changent, les filtres évoluent, et ce qui se fond bien sur un chemin peut se démarquer sur un autre. L’objectif n’est pas la magie. L’objectif est de choisir la pile la plus sensée pour votre environnement.
C’est pourquoi cet article s’arrête à la carte au lieu de prétendre qu’une seule page peut couvrir chaque construction complète. L’étape suivante consiste à choisir la famille de configuration qui correspond à votre réseau et à vos objectifs.
Quel chemin 3x-ui correspond à votre cas d’usage ?

Si vous voulez la réponse par défaut la plus claire en premier, la voici : pour les environnements restrictifs et lourds en DPI, commencez par VLESS + Reality. Il sépare le protocole de la discrétion clairement, fonctionne bien sur le port 443, et ne vous oblige pas à commencer par un domaine ou un reverse proxy.
Cela ne fait pas de c’est la réponse à chaque situation. Si vous gérez déjà un domaine ou préférez un flux de travail plus traditionnel avec TLS et reverse proxy, alors VLESS ou Trojan sur TLS avec WebSocket ou gRPC est souvent le meilleur choix. Ce chemin a plus de sens quand vous gérez déjà un domaine et des certificats.
Si votre priorité est le débit et que votre réseau gère bien l’UDP, Hysteria 2 mérite de l’attention. C’est le chemin spécialisé ici parce que son attrait est moins « ressembler à la session de navigateur la plus ordinaire possible » et plus « obtenir de bonnes performances d’une conception basée sur QUIC/UDP ». C’est convaincant, mais pas la recommandation par défaut pour les débutants axés sur la discrétion.
Shadowsocks 2022, VMess et chemins de compatibilité similaires ont toujours leur place, mais surtout pour la migration, le support des anciens clients, ou des contraintes de compatibilité étroites. VMess en particulier n’est pas le meilleur choix égal en premier pour les débutants en raison de sa dépendance temporelle — un détail opérationnel de plus à mal faire quand des options plus simples existent déjà.
| Chemin | Idéal pour | Besoin d’un domaine ? | Pourquoi le choisir | Pourquoi ce n’est pas le standard universel |
|---|---|---|---|---|
| VLESS + Reality | Réseaux restrictifs ou fortement filtrés | Non | Modèle mental solide pour les débutants orientés vers la discrétion sur le port 443 | Toujours pas à l’épreuve du temps, et certains réseaux ou clients peuvent vous pousser ailleurs |
| VLESS/Trojan + TLS + WebSocket/gRPC | Piles basées sur domaine, reverse proxies, configurations site web + proxy | Généralement oui | Convient aux lecteurs déjà à l’aise avec les domaines, certificats et stratification de pile web | Plus de pièces mobiles qu’un chemin Reality sans domaine |
| Hysteria 2 | Configurations axées sur la vitesse où l’UDP fonctionne bien | Non | Excellent quand le débit et les performances QUIC/UDP sont l’objectif principal | Pas l’histoire de camouflage la plus ressemblante à un navigateur, et les conditions UDP varient |
| Shadowsocks 2022 / VMess / chemins de compatibilité | Migration, support des anciens clients, contraintes plus étroites | Dépend | Utile quand la compatibilité est la vraie exigence | Pas le meilleur standard pour les débutants quand des choix modernes plus clairs sont disponibles |
💡 Liste de contrôle de décision rapide
- Réseau censuré : commencez par VLESS + Reality
- Configuration domaine / reverse proxy : évaluez TLS + WS/gRPC ou Trojan
- UDP haute vitesse : testez Hysteria 2
- Cas limites de compatibilité : considérez Shadowsocks 2022 ou VMess
WireGuard et OpenVPN sont des exemples de contraste utiles ici, pas l’étape suivante recommandée, parce que les formes de protocole VPN ordinaires sont souvent ce que les réseaux restrictifs apprennent à reconnaître en premier. Choisissez le chemin qui correspond à votre environnement, puis construisez ce chemin avant d’ajouter plus d’options.
Ce que vous pouvez faire ensuite dans 3x-ui après avoir choisi un chemin
Une fois que vous choisissez le chemin, 3x-ui devient la couche opérationnelle. C’est là que vous créez l’inbound, ajoutez des clients, exportez un lien de partage ou un code QR, définissez des limites de trafic ou des dates d’expiration, et maintenez le serveur gérable au fil du temps au lieu de fouiller dans les fichiers Xray bruts.

📝 Remarque : Le panneau n’est pas « juste l’écran de connexion ». C’est la surface d’administration où les décisions de protocole deviennent des inbounds en cours d’exécution, des identifiants de client, des contrôles d’utilisation et de la visibilité.
En termes pratiques, la séquence est généralement simple : créer l’inbound, ajouter une identité de client, exporter les détails de connexion, les importer dans l’application client, et revenir plus tard pour les limites, les renouvellements, les journaux, les statistiques de trafic, et les mises à jour de routage ou de fichiers géo si nécessaire. Cette visibilité opérationnelle est une grande partie de la raison pour laquelle l’utilisation du panneau en vaut la peine.
Si vous continuez cette configuration en tant que série, le premier guide de suivi devrait être la construction VLESS + Reality pour les lecteurs sur des réseaux restrictifs. C’est l’article suivant le plus naturel car il transforme ce modèle mental en une configuration concrète.
Conclusion

L’installation de 3x-ui n’est pas la solution anti-censure finale. C’est la salle de contrôle. Le vrai résultat provient de ce que vous configurez à l’intérieur ensuite. Gardez la séparation simple : le tableau de bord rend Xray gérable, mais le moteur et la route — choix du protocole, du transport et de la sécurité — décident de la qualité de survie de la connexion face au filtrage.
Alors franchissez l’étape honnête suivante, et sélectionnez le chemin réel qui correspond le mieux à vos objectifs. Et une fois que vous devenez sérieux au sujet de l’auto-hébergement de votre choix, une infrastructure VPS stable importe aussi — que cela signifie AlexHost ou un autre fournisseur qui vous donne un contrôle réseau prévisible et un accès firewall propre.
sur tous les services d'hébergement