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.
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.
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 contieneserveryserver_port, el sitio externo del que tu servidor toma prestadoprivate_key(cadena), que según la documentación se genera consing-box generate reality-keypairshort_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. La clave pública no se puede recuperar a partir de un archivo de configuración que solo almacena la privada, y regenerar el par invalida a todos los clientes que ya hayas repartido.
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:
sniffsniff_timeoutdomain_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 servidorshort_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 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.
★ Datacenter Núremberg GDPR · ✓ IPv4 dedicada incluida · 200+ Mbps garantizados
Un VPS que controlas para túnel y ofuscación → ContaboAcceso root · abre cualquier puerto · tu propia stack→
