Configuración sing-box VLESS Reality 2026: los campos que casi todas las guías siguen equivocando

Una configuración actual de sing-box VLESS + Reality, contrastada con la documentación oficial de la 1.13. Incluye los campos del inbound que quedaron obsoletos en la 1.11 y que se siguen copiando en la mayoría de tutoriales.

Por Eric GerardFundador · VPNSmith - Especialista en VPN self-host y VPS GDPR

Actualizado 8 min de lectura8 min

Enlaces de afiliado: podemos cobrar una comisión, sin coste extra. Método

Generar mi config REALITYLeer la guía

Plain WireGuard packet blocked by DPI, VLESS + REALITY packet passing as HTTPS to microsoft.comDPIWG UDP 51820plain WireGuardsignature matchflow droppedTCP 443 TLS 1.3SNI microsoft.comYOUR VPSXray REALITYlooks like HTTPSprobe gets the real microsoft cert
fig. 01 / tunneling-obfuscation

Busca una guía de sing-box Reality y encontrarás un montón de archivos de configuración que eran correctos en 2024. Siguen parseándose, y ahí está el problema: nada te avisa de que acabas de construir sobre campos que el proyecto declaró obsoletos. Aquí repasamos una configuración VLESS Reality campo por campo contra la documentación actual, y señalamos las partes que se han movido en silencio.

Plain WireGuard packet blocked by DPI, VLESS + REALITY packet passing as HTTPS to microsoft.comDPIWG UDP 51820plain WireGuardsignature matchflow droppedTCP 443 TLS 1.3SNI microsoft.comYOUR VPSXray REALITYlooks like HTTPSprobe gets the real microsoft cert
fig. 01 / tunneling-obfuscation

Como referencia, la versión contra la que se ha contrastado esto es sing-box 1.13.15, publicada el 29 de julio de 2026.

¿Aún no tienes servidor? La configuración de abajo necesita un VPS con IPv4 pública, acceso root y el puerto 443 libre, fuera de la red que te filtra: un Contabo Cloud VPS 4 (enlace de afiliado) sirve desde 5,50 € al mes con permanencia de 24 meses.

¿Tarjeta bancaria rechazada? Ultahost también acepta Bitcoin y otras criptomonedas, Alipay, WeChat Pay y Qiwi (su página de pagos, leída el 25 de octubre de 2026). Es un enlace de afiliado; revisa sus condiciones para tu país antes de contratar.

¿Prefieres no montar el JSON a mano? Nuestro generador de config VLESS REALITY gratuito crea el par de claves X25519, el UUID y el short ID en tu navegador y escribe las configs de servidor y cliente correspondientes para sing-box y Xray-core, listas para pegar en los pasos de abajo.

REALITY necesita un servidor que controles

¿Más RAM para el mismo uso? ver la oferta Contabo Cloud VPS

Enlace de afiliado: podemos recibir una comisión, sin coste extra para ti. El generador sigue siendo gratuito y no depende de ello.

Ver HostPapa VPS Lite, 2,95 $/mes a 3 años

Todo ocurre en tu navegador: claves, UUID y configuraciones se generan en local y no se envían a ningún sitio.

La IP pública de tu VPS (o un dominio que apunte a ella). Se usa en la configuración del cliente y en el enlace.

443 es lo habitual: REALITY imita HTTPS.

Un sitio de terceros con TLS 1.3 y HTTP/2, accesible desde tus clientes. Mira la lista de comprobación bajo la herramienta.

Huella uTLS (cliente)

La huella TLS que imita el cliente. chrome es la opción habitual.

Par de claves X25519

La clave privada va solo en el servidor. La pública va a cada cliente.

Hexadecimal, longitud par, hasta 16 caracteres.

  • Faltan las claves o no son válidas (32 bytes, base64url, 43 caracteres). Genera un par o pega el tuyo.

Enlace vless:// para compartir

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

Impórtalo en v2rayN, v2rayNG, Hiddify, Streisand o Shadowrocket, o escanea el código QR.

config.json
{
  "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"
    }
  ]
}
client-xray.json
{
  "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"
    }
  ]
}
install.sh
# Instalar Xray-core con el script oficial (servicio systemd incluido)
bash -c "$(curl -L https://github.com/XTLS/Xray-install/raw/main/install-release.sh)" @ install

# Opcional: confirmar que la clave pública corresponde a la privada
xray x25519 -i ""

# Comprobar que el destino responde en TLS 1.3 y HTTP/2
xray tls ping www.example.com

# Abrir el puerto
sudo ufw allow 443/tcp

# Pegar la configuración del servidor, probarla y arrancar el servicio
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

# Seguir el registro mientras se conecta el primer cliente
sudo journalctl -u xray -f

REALITY necesita un servidor que controles

Un servidor REALITY es un VPS con IP pública y el puerto 443 libre, nada más. El VPS de entrada de Contabo incluye IPv4 pública, acceso root y mucho tráfico, y puedes elegir el datacenter más cercano a tus usuarios.

Segunda opción, un proveedor estadounidense con 30 días de devolución: el VPS Basic de Ultahost, 5,52 $/mes a 24 meses, 1 CPU, 1 GB DDR5 e IPv4 dedicada (leído el 21 de octubre de 2026), suficiente para un servidor Xray. También acepta Bitcoin y otras criptomonedas, Alipay, WeChat Pay y Qiwi (su página de pagos, leída el 25 de octubre de 2026), útil si tu tarjeta bancaria es rechazada; revisa sus condiciones para tu país antes de contratar. Ver VPS de Ultahost

Enlace de afiliado: podemos recibir una comisión, sin coste extra para ti. El generador sigue siendo gratuito y no depende de ello.

Ver el VPS de Contabo

¿Prefieres archivos ya probados de principio a fin?

El pack de configuración VLESS + REALITY incluye un servidor Xray comentado en el puerto 443, un cliente de escritorio (proxy SOCKS5 y HTTP local), una plantilla de enlace vless:// para v2rayN, v2rayNG y Shadowrocket, y dos cosas que este generador no escribe: una variante del servidor con contadores de tráfico por dispositivo y un README con una lista de solución de problemas en 10 puntos. Cada archivo JSON pasa xray run -test con Xray-core 26.10.31. Solo Xray-core, sin archivos sing-box.

Ver el pack de configuración VLESS + REALITY (4,90 EUR)

Producto propio, pago único, ZIP de archivos de texto en inglés (página en inglés). Plantillas para tu propio servidor, no una suscripción VPN, y sin promesa de que REALITY siga pasando un DPI concreto. Los archivos generados arriba funcionan sin él.

¿Aún no has elegido el servidor? Nuestra guía Mejor VPS para V2Ray y Xray compara proveedores según lo que decide cuánto aguanta un servidor contra la censura: ubicación del centro de datos, reputación de la IP, tráfico incluido y rapidez para sustituir una IP bloqueada.

Qué cambia Reality en realidad

Los proxies convencionales basados en TLS tienen una debilidad estructural: el certificado es tuyo. Un censor que inspecciona el handshake ve un dominio y un certificado que no se corresponden con un sitio web real y popular, y ese desajuste es en sí mismo la señal.

El enfoque de Reality consiste en tomar prestado el handshake de un sitio de terceros genuino. Tu servidor se configura para apuntar a un host externo real, y el tráfico que no supera la autenticación se le pasa a él. Para un observador, la conexión se parece a una conexión con ese sitio, porque en parte lo es.

Por eso la configuración tiene un bloque handshake. No es decoración, y su elección importa más que cualquier otro valor que vayas a fijar.

Los tres campos Reality obligatorios en el servidor

Dentro del objeto tls, el bloque reality requiere exactamente tres cosas según la documentación:

  • handshake (objeto), que contiene server y server_port, el sitio externo del que tu servidor toma prestado
  • private_key (cadena), que según la documentación se genera con sing-box generate reality-keypair
  • short_id (cadena), descrita como una cadena hexadecimal de cero a ocho dígitos

También hay un booleano enabled, y un max_time_difference opcional, que fija la diferencia de reloj tolerada entre los dos extremos. La documentación señala que la comprobación se desactiva cuando se deja vacío. Si lo fijas, ten en cuenta que ahora dependes de que ambas máquinas mantengan la hora exacta.

Generar las claves

Hay dos valores que hay que generar antes de escribir nada:

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

El keypair imprime una clave privada y una clave pública. La clave privada se queda en el servidor. La clave pública va a cada cliente. El UUID es la identidad de usuario VLESS.

Guarda el par junto en un sitio seguro cuando lo generes. Si solo conservas la clave privada, en una configuración de servidor por ejemplo, la pública no está perdida: se deriva de la privada, con xray x25519 -i "<clave privada>" o pegándola en nuestro generador de configuración VLESS REALITY, que funciona en local. Regenerar el par, en cambio, invalida a todos los clientes que ya hayas repartido.

Cables ethernet azules enchufados en los puertos numerados de un switch de red, con LED de estado verdes encendidos a lo largo del panel frontal.
Cables ethernet azules enchufados en los puertos numerados de un switch de red, con LED de estado verdes encendidos a lo largo del panel frontal.

La parte de servidor que sigue funciona en cualquier VPS con una IPv4 pública, acceso root y el puerto 443 libre para el inbound. Si aún no tienes uno:

El inbound del servidor

Un inbound VLESS requiere type, tag, los campos de escucha y un array users. Cada entrada de usuario admite un uuid, opcionalmente un name, y opcionalmente un flow. La documentación lista exactamente un valor 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"
    }
  }
}

Fíjate en server_name y en el server del handshake. Son campos separados que normalmente contendrán el mismo host, y un desajuste entre ellos es una causa habitual de un montaje que se construye bien y luego falla en el momento de la conexión.

La parte que casi todas las guías equivocan

Aquí está la diferencia entre una configuración de 2024 y una actual. Estos tres campos del inbound quedaron obsoletos en la versión 1.11.0:

  • sniff
  • sniff_timeout
  • domain_strategy

Salieron del inbound y pasaron a ser acciones de reglas de enrutado. La guía de migración da las equivalencias directas:

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

Así, "sniff": true pasa a ser un action de sniff, sniff_timeout pasa a ser el timeout de esa acción, y domain_strategy pasa a ser un action de resolve con un strategy.

Por ser exactos sobre lo que está en juego: la documentación los marca como obsoletos y no anuncia una fecha de eliminación. Hoy no se rompe nada. Pero una configuración que todavía los lleva está escrita contra una interfaz de la que el proyecto se ha alejado, y eso conviene saberlo cuando eliges qué tutorial seguir.

Dos campos relacionados, sniff_override_destination y udp_disable_domain_unmapping, también aparecen marcados como obsoletos en la documentación actual de los campos de escucha.

El lado del cliente

El cliente necesita menos que el servidor. Reality en el cliente requiere:

  • public_key, la contraparte de la clave privada del servidor
  • short_id, que debe coincidir con un valor que el servidor acepte

El objeto utls va junto a él, con enabled y fingerprint. Los valores de fingerprint aceptados que están documentados son chrome, firefox, edge, safari, 360, qq, ios, android, random y randomized. La documentación indica que se usa el fingerprint de Chrome cuando el campo está vacío.

Un apunte de honestidad aquí, porque las guías tienden a afirmar lo contrario: la documentación de sing-box presenta utls como una opción TLS independiente y no afirma que Reality lo requiera. La mayoría de configuraciones de cliente lo activan de todos modos.

Elegir el host de handshake

Ningún valor de la configuración afecta más al resultado, y ninguna guía puede elegirlo por ti, porque la respuesta correcta depende de dónde está tu servidor y dónde están tus clientes.

Las propiedades que importan:

  • Debe ser un host que soporte de verdad TLS 1.3 en el puerto al que apuntas
  • Debe ser tráfico plausible desde la ubicación de red de tu servidor
  • No debe ser un sitio que esté bloqueado en el país desde el que te conectas, lo que echaría por tierra todo el propósito
  • No debe ser un sitio que tú controles, porque la gracia está en que sea tráfico real de otra persona

Un consejo que se repite mucho es elegir algo grande y genérico. Cuidado con ese razonamiento: un host que todos los tutoriales recomiendan es, por definición, un host que aparece en todas las configuraciones, y ser popular dentro de la comunidad de proxies no es lo mismo que pasar desapercibido.

Antes de dar por hecho que funciona

Dos comprobaciones que merecen la pena y que van más allá de "el cliente conectó".

Confirma que el fallback se comporta. Apunta un navegador normal a la dirección y el puerto de tu servidor. Lo que deberías ver es el sitio del handshake, no un error ni un timeout. Si obtienes otra cosa, el passthrough no está haciendo su trabajo y el montaje resulta más llamativo que un proxy corriente.

Comprueba los dos relojes. Si fijas max_time_difference, la deriva en cualquiera de las dos máquinas producirá fallos que parecen problemas de autenticación y te mandará a editar claves que nunca estuvieron mal.

Si todavía estás decidiendo entre motores en vez de configurando uno, las ventajas y contrapartidas están detalladas en nuestra comparativa sing-box frente a Xray.

La mayoría de las instalaciones REALITY fallan al copiar los valores. Nuestra VLESS REALITY Cheat Sheet gratuita (PDF de 3 páginas en inglés, descarga directa, sin registro) pone lado a lado el nombre de cada campo en Xray, sing-box y el enlace vless://, con las comprobaciones del servidor y las causas de fallo habituales. Descargar la ficha.

La versión corta

Tres campos Reality obligatorios en el servidor: handshake, private_key, short_id. Dos en el cliente: public_key, short_id. Las claves salen de sing-box generate reality-keypair. Y si la guía que estás leyendo pone sniff o domain_strategy dentro del inbound, es anterior a la versión 1.11 y el equivalente actual es una acción de regla de enrutado.

Los nombres de campo, los requisitos y las obsolescencias de este artículo se han tomado de la documentación oficial de sing-box y de su guía de migración, contrastados con la release 1.13.15 el 30 de julio de 2026. Las interfaces de configuración cambian entre versiones, así que verifica contra la documentación de la release que estés ejecutando. Sortear la censura está restringido o es ilegal en algunas jurisdicciones; comprueba qué se aplica donde estés.

Enlace de afiliado

Precio revisado el 17/10/2026, permanencia 24 meses

Preguntas frecuentes

¿Qué campos de sing-box necesito realmente para un inbound VLESS Reality?
El propio inbound VLESS requiere type, tag, una dirección de escucha y un puerto, y un array users donde cada entrada lleva un uuid. La parte Reality vive dentro del objeto tls y requiere tres cosas en el servidor: un objeto handshake que apunte a un sitio externo real con su server y su server_port, una private_key generada por sing-box, y un short_id. Todo lo demás en el inbound es opcional.
¿Qué genera la clave privada y la clave pública de Reality?
El comando sing-box generate reality-keypair. Imprime un par emparejado. La private_key se queda en la configuración del servidor y la public_key va en la configuración del cliente. No son intercambiables, y un cliente que use la public_key equivocada fallará el handshake en lugar de caer a TLS normal.
¿Se permite que el short_id esté vacío?
La documentación describe short_id como una cadena hexadecimal de cero a ocho dígitos, así que un valor vacío entra dentro de la especificación. El valor en el cliente debe coincidir con un valor que el servidor acepte, que es la parte que la gente pasa por alto cuando copia una configuración de servidor y solo edita el UUID.
¿Por qué los tutoriales antiguos de sing-box ponen sniff y domain_strategy dentro del inbound?
Porque eso era correcto antes de la versión 1.11.0. Esos campos, junto con sniff_timeout, quedaron obsoletos entonces y se movieron a acciones de reglas de enrutado: action sniff con un parámetro timeout, y action resolve con un parámetro strategy. Las configuraciones escritas a la antigua siguen parseándose, pero estás siguiendo una vía obsoleta, algo que conviene saber antes de construir sobre ella.
¿Necesito utls en el cliente?
La documentación de sing-box presenta utls como su propia opción dentro del bloque TLS, con un flag enabled y un fingerprint, y no afirma que Reality lo requiera. Muchas configuraciones de cliente lo activan igualmente. Si dejas el fingerprint vacío, la documentación dice que se usa el fingerprint de Chrome.