Configuration sing-box VLESS Reality 2026 : les champs que la plupart des guides continuent de se tromper

Cherchez un guide sing-box Reality et vous tomberez sur quantité de fichiers de configuration qui étaient corrects en 2024. Ils se parsent toujours, et c'est bien le problème : rien ne vous avertit que vous venez de bâtir sur des champs que le projet a dépréciés. Cet article déroule une configuration VLESS Reality vérifiée champ par champ face à la documentation actuelle, et signale les éléments qui ont discrètement changé de place.

Pour référence, la version face à laquelle tout ceci a été vérifié est sing-box 1.13.15, publiée le 29 juillet 2026.

Pas encore de serveur ? La configuration ci-dessous demande un VPS avec une IPv4 publique, un accès root et le port 443 libre, hors du réseau qui vous filtre : un Contabo Cloud VPS 4 (lien affilié) fait l'affaire dès 5,50 € par mois sur 24 mois.

Carte bancaire refusée ? Ultahost accepte aussi le Bitcoin et d'autres cryptomonnaies, Alipay, WeChat Pay et Qiwi (page des paiements, relevée le 25 octobre 2026). Lien affilié ; ses conditions par pays sont à vérifier avant de commander.

Vous préférez ne pas assembler le JSON à la main ? Notre générateur de config VLESS REALITY gratuit crée la paire de clés X25519, l'UUID et le short ID dans votre navigateur et écrit les configs serveur et client correspondantes pour sing-box et Xray-core, prêtes à coller dans les étapes ci-dessous.

vless://@203.0.113.10:443?encryption=none&flow=xtls-rprx-vision&security=reality&sni=www.example.com&fp=chrome&pbk=&sid=&type=tcp&headerType=none#my-reality

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "listen": "0.0.0.0",
      "port": 443,
      "protocol": "vless",
      "settings": {
        "clients": [
          {
            "id": "",
            "flow": "xtls-rprx-vision",
            "email": "my-reality"
          }
        ],
        "decryption": "none"
      },
      "streamSettings": {
        "network": "tcp",
        "security": "reality",
        "realitySettings": {
          "show": false,
          "target": "www.example.com:443",
          "xver": 0,
          "serverNames": [
            "www.example.com"
          ],
          "privateKey": "",
          "shortIds": [
            ""
          ]
        }
      },
      "sniffing": {
        "enabled": true,
        "destOverride": [
          "http",
          "tls",
          "quic"
        ],
        "routeOnly": true
      }
    }
  ],
  "outbounds": [
    {
      "protocol": "freedom",
      "tag": "direct"
    },
    {
      "protocol": "blackhole",
      "tag": "block"
    }
  ]
}

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "udp": true
      }
    },
    {
      "listen": "127.0.0.1",
      "port": 10809,
      "protocol": "http"
    }
  ],
  "outbounds": [
    {
      "protocol": "vless",
      "tag": "proxy",
      "settings": {
        "vnext": [
          {
            "address": "203.0.113.10",
            "port": 443,
            "users": [
              {
                "id": "",
                "flow": "xtls-rprx-vision",
                "encryption": "none"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "tcp",
        "security": "reality",
        "realitySettings": {
          "serverName": "www.example.com",
          "fingerprint": "chrome",
          "publicKey": "",
          "shortId": "",
          "spiderX": "/"
        }
      }
    },
    {
      "protocol": "freedom",
      "tag": "direct"
    }
  ]
}

# Installer Xray-core avec le script officiel (service systemd inclus)
bash -c "$(curl -L https://github.com/XTLS/Xray-install/raw/main/install-release.sh)" @ install

# Facultatif : vérifier que la clé publique correspond à la clé privée
xray x25519 -i ""

# Vérifier que la cible répond en TLS 1.3 et HTTP/2
xray tls ping www.example.com

# Ouvrir le port
sudo ufw allow 443/tcp

# Coller la config serveur, la tester, puis démarrer le service
sudo nano /usr/local/etc/xray/config.json
xray run -test -c /usr/local/etc/xray/config.json
sudo systemctl restart xray && sudo systemctl enable xray

# Suivre le journal pendant la connexion du premier client
sudo journalctl -u xray -f

Vous n'avez pas encore choisi le serveur ? Notre guide Meilleur VPS pour V2Ray et Xray compare les hébergeurs sur ce qui décide de la durée de vie d'un serveur anti-censure : emplacement du datacenter, réputation de l'IP, trafic inclus et rapidité pour remplacer une IP bloquée.

Ce que Reality change réellement

Les proxies classiques fondés sur TLS ont une faiblesse structurelle : le certificat vous appartient. Un censeur qui inspecte le handshake voit un domaine et un certificat qui ne correspondent à aucun site réel et populaire, et ce décalage constitue à lui seul le signal.

L'approche de Reality consiste à emprunter le handshake d'un vrai site tiers. Votre serveur est configuré pour pointer vers un hôte externe réel, et le trafic qui échoue à l'authentification lui est transmis. Pour un observateur, la connexion ressemble à une connexion vers ce site, parce qu'en partie c'en est une.

C'est pour cela que la configuration comporte un bloc handshake. Ce n'est pas de la décoration et son choix compte davantage que n'importe quelle autre valeur que vous allez définir.

Les trois champs Reality obligatoires côté serveur

À l'intérieur de l'objet tls, le bloc reality exige exactement trois choses selon la documentation :

• handshake (objet), contenant server et server_port, le site externe auquel votre serveur emprunte son handshake
• private_key (chaîne), dont la documentation indique qu'elle est générée par sing-box generate reality-keypair
• short_id (chaîne), décrite comme une chaîne hexadécimale de zéro à huit chiffres

Il existe également un booléen enabled, et un max_time_difference facultatif, qui fixe l'écart d'horloge toléré entre les deux extrémités. La documentation précise que la vérification est désactivée lorsque ce champ est laissé vide. Si vous le renseignez, gardez à l'esprit que vous dépendez désormais du maintien d'une heure exacte sur les deux machines.

Générer les clés

Deux valeurs doivent être générées avant d'écrire quoi que ce soit :

sing-box generate reality-keypair
sing-box generate uuid

La paire de clés affiche une clé privée et une clé publique. La clé privée reste sur le serveur. La clé publique va vers chaque client. L'UUID est l'identité de l'utilisateur VLESS.

Conservez la paire ensemble en lieu sûr au moment où vous la générez. Si seule la clé privée a survécu, dans une config serveur par exemple, la clé publique n'est pas perdue : elle se dérive de la privée, avec xray x25519 -i "<clé privée>" ou en la collant dans notre générateur de config VLESS REALITY, qui fonctionne en local. Régénérer la paire, en revanche, invalide tous les clients que vous avez déjà distribués.

La partie serveur ci-dessous tourne sur n'importe quel VPS avec une IPv4 publique, un accès root et le port 443 libre pour l'inbound. Si vous n'en avez pas encore :

L'inbound côté serveur

Un inbound VLESS exige type, tag, les champs d'écoute et un tableau users. Chaque entrée utilisateur prend un uuid, éventuellement un name, et éventuellement un flow. La documentation ne liste qu'une seule valeur de flow disponible : xtls-rprx-vision.

{
  "type": "vless",
  "tag": "vless-in",
  "listen": "::",
  "listen_port": 443,
  "users": [
    {
      "name": "me",
      "uuid": "PASTE-YOUR-GENERATED-UUID",
      "flow": "xtls-rprx-vision"
    }
  ],
  "tls": {
    "enabled": true,
    "server_name": "your-handshake-host.example",
    "reality": {
      "enabled": true,
      "handshake": {
        "server": "your-handshake-host.example",
        "server_port": 443
      },
      "private_key": "PASTE-YOUR-PRIVATE-KEY",
      "short_id": "0123abcd"
    }
  }
}

Notez server_name et le server du handshake. Ce sont deux champs distincts qui contiendront normalement le même hôte, et une discordance entre eux est une cause fréquente d'installation qui se construit sans erreur puis échoue au moment de la connexion.

Le point que la plupart des guides ratent

Voici la différence entre une configuration de 2024 et une configuration actuelle. Ces trois champs d'inbound ont été dépréciés en version 1.11.0 :

• sniff
• sniff_timeout
• domain_strategy

Ils sont sortis de l'inbound pour devenir des actions de règles de routage. Le guide de migration donne les équivalences directes :

{
  "route": {
    "rules": [
      { "inbound": "vless-in", "action": "sniff", "timeout": "1s" },
      { "inbound": "vless-in", "action": "resolve", "strategy": "prefer_ipv4" }
    ]
  }
}

Ainsi "sniff": true devient une action de type sniff, sniff_timeout devient le timeout de cette action, et domain_strategy devient une action de type resolve avec un strategy.

Pour être exact sur l'enjeu : la documentation les marque comme dépréciés et n'annonce pas de date de suppression. Rien ne casse aujourd'hui. Mais une configuration qui les porte encore est écrite face à une interface dont le projet s'est éloigné, et cela mérite d'être su au moment de choisir quel tutoriel suivre.

Deux champs voisins, sniff_override_destination et udp_disable_domain_unmapping, sont eux aussi marqués comme dépréciés dans la documentation actuelle des champs d'écoute.

Le côté client

Le client demande moins que le serveur. Reality côté client exige :

• public_key, la contrepartie de la clé privée du serveur
• short_id, qui doit correspondre à une valeur acceptée par le serveur

L'objet utls se place à côté, avec enabled et fingerprint. Les valeurs de fingerprint documentées comme acceptées sont chrome, firefox, edge, safari, 360, qq, ios, android, random et randomized. La documentation indique que le fingerprint Chrome est utilisé lorsque le champ est vide.

Un point d'honnêteté ici, car les guides ont tendance à affirmer le contraire : la documentation sing-box présente utls comme une option TLS indépendante et n'indique pas que Reality l'exige. La plupart des configurations client l'activent malgré tout.

Choisir l'hôte du handshake

Aucune valeur de configuration n'influence davantage votre résultat, et aucun guide ne peut la choisir à votre place, parce que la bonne réponse dépend de l'emplacement de votre serveur et de celui de vos clients.

Les propriétés qui comptent :

• Ce doit être un hôte qui prend réellement en charge TLS 1.3 sur le port que vous visez
• Ce doit être du trafic plausible depuis l'emplacement réseau de votre serveur
• Ce ne doit pas être un site lui-même bloqué dans le pays depuis lequel vous vous connectez, ce qui ruinerait totalement l'intérêt de la manoeuvre
• Ce ne doit pas être un site que vous contrôlez, puisque tout l'intérêt est qu'il s'agisse du vrai trafic de quelqu'un d'autre

Un conseil fréquemment répété consiste à choisir quelque chose de gros et de générique. Méfiez-vous de ce raisonnement : un hôte que tous les tutoriels recommandent est, par définition, un hôte qui figure dans toutes les configurations, et la popularité au sein de la communauté proxy n'est pas la même chose que le fait de se fondre dans la masse.

Avant de conclure que ça marche

Deux vérifications qui valent la peine et qui vont plus loin que « le client s'est connecté ».

Confirmez que le fallback se comporte bien. Pointez un simple navigateur vers l'adresse et le port de votre serveur. Ce que vous devez voir, c'est le site du handshake, pas une erreur ni un délai d'attente. Si vous obtenez autre chose, le passthrough ne fait pas son travail et l'installation est plus voyante qu'un proxy ordinaire.

Vérifiez les deux horloges. Si vous avez défini max_time_difference, une dérive sur l'une ou l'autre machine produira des échecs qui ressemblent à des problèmes d'authentification et vous enverra modifier des clés qui n'ont jamais été fausses.

Si vous en êtes encore à choisir entre plusieurs moteurs plutôt qu'à en configurer un, les arbitrages sont exposés dans notre comparatif sing-box contre Xray.

C'est en recopiant les valeurs que la plupart des installations REALITY cassent. Notre VLESS REALITY Cheat Sheet gratuite (PDF de 3 pages en anglais, téléchargement direct, sans inscription) met côte à côte le nom de chaque champ dans Xray, sing-box et le lien vless://, avec les vérifications côté serveur et les causes de panne habituelles. Télécharger la fiche.

La version courte

Trois champs Reality obligatoires côté serveur : handshake, private_key, short_id. Deux côté client : public_key, short_id. Les clés viennent de sing-box generate reality-keypair. Et si le guide que vous lisez place sniff ou domain_strategy dans l'inbound, il est antérieur à la version 1.11 et l'équivalent actuel est une action de règle de routage.

Les noms de champs, exigences et dépréciations de cet article proviennent de la documentation officielle sing-box et de son guide de migration, vérifiés face à la version 1.13.15 le 30 juillet 2026. Les interfaces de configuration changent d'une version à l'autre, vérifiez donc face à la documentation de la version que vous faites tourner. Le contournement de la censure est restreint ou illégal dans certaines juridictions, renseignez-vous sur ce qui s'applique là où vous êtes.