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.

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. La clé publique n'est pas récupérable depuis un fichier de configuration qui ne stocke que la clé privée, et régénérer la paire invalide tous les clients que vous avez déjà distribués.

Des câbles ethernet bleus branchés dans les ports numérotés d'un switch réseau, avec des LED d'état vertes allumées le long de la face avant.

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.

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.

★ Datacenter Nuremberg GDPR · ✓ IPv4 dédiée incluse · 200+ Mbps garantis

Un VPS que tu contrôles pour le tunneling & l'obfuscation → ContaboAccès root · ouvre n'importe quel port · ta propre stack→

Questions fréquentes

De quels champs sing-box ai-je réellement besoin pour un inbound VLESS Reality ?

L'inbound VLESS lui-même exige type, tag, une adresse d'écoute et un port, ainsi qu'un tableau users dont chaque entrée porte un uuid. La partie Reality se trouve dans l'objet tls et requiert trois choses côté serveur : un objet handshake qui pointe vers un vrai site externe avec son server et son server_port, une private_key générée par sing-box, et un short_id. Tout le reste dans l'inbound est facultatif.

Qu'est-ce qui génère la clé privée et la clé publique Reality ?

La commande sing-box generate reality-keypair. Elle affiche une paire correspondante. La private_key reste dans la configuration du serveur et la public_key va dans celle du client. Elles ne sont pas interchangeables, et un client qui utilise la mauvaise public_key échouera au handshake au lieu de retomber sur du TLS classique.

Le short_id a-t-il le droit d'être vide ?

La documentation décrit short_id comme une chaîne hexadécimale de zéro à huit chiffres, donc une valeur vide reste dans les clous. La valeur côté client doit correspondre à une valeur acceptée par le serveur, et c'est le point que l'on rate en recopiant une configuration serveur pour n'y modifier que l'UUID.

Pourquoi les anciens tutoriels sing-box placent-ils sniff et domain_strategy dans l'inbound ?

Parce que c'était correct avant la version 1.11.0. Ces champs, ainsi que sniff_timeout, y ont été dépréciés et déplacés vers les actions de règles de routage : action sniff avec un paramètre timeout, et action resolve avec un paramètre strategy. Les configurations écrites à l'ancienne se parsent toujours, mais vous suivez une voie dépréciée, ce qui mérite d'être su avant de construire dessus.

Ai-je besoin d'utls côté client ?

La documentation sing-box présente utls comme une option à part entière dans le bloc TLS, avec un indicateur enabled et un fingerprint, et elle n'indique pas que Reality l'exige. Beaucoup de configurations client l'activent quand même. Si vous laissez fingerprint vide, la documentation indique que le fingerprint Chrome est utilisé.