Cómo VLESS Reality hace invisible el tráfico VPN para los
Cada protocolo VPN tiene un fingerprint. La iniciación de handshake de WireGuard es siempre exactamente 148 bytes con una estructura fija. El canal de control de OpenVPN tiene patrones de timing que son obvios bajo análisis. Hasta Shadowsocks, diseñado específicamente para resistencia a la censura, produce tráfico con entropía mediblemente alta que los sistemas DPI pueden flagear como "no HTTPS normal."
La encriptación protege contenido. No hace nada para ocultar el hecho de que estás usando una VPN.
VLESS Reality, lanzado en Xray-core v1.8.0 a principios de 2023, toma un enfoque completamente distinto. En lugar de encriptar tráfico y esperar que los censores no puedan identificar el wrapper, hace que las conexiones VPN parezcan idénticas a la navegación HTTPS ordinaria. No similar. Idénticas. El certificado TLS que tu conexión presenta es real, emitido por una autoridad certificadora real, para un sitio web real.
Acá cómo funciona, por qué es difícil de bloquear, y qué resignás para conseguirlo.
El problema de detección
Un sistema de inspección profunda de paquetes no necesita desencriptar tu tráfico para saber qué protocolo estás corriendo. Sólo necesita reconocer patrones.
WireGuard es el ejemplo más fácil. El mensaje de iniciación de handshake empieza con un campo de tipo de 1 byte, 3 bytes de ceros reservados, un sender index de 4 bytes, luego una clave efímera no encriptada de 32 bytes. Esta estructura nunca cambia. El TSPU de Rusia (Sistemas Técnicos para Contrarrestar Amenazas) puede detectar WireGuard con casi 100% de precisión matcheando este patrón en el primer paquete.
OpenVPN es ligeramente más difícil de detectar pero no por mucho. Su handshake TLS tiene timing distintivo y su canal de control usa un formato de framing reconocible. El Great Firewall de China lo viene bloqueando confiablemente por años.
El problema más difícil es el análisis de entropía. El tráfico totalmente encriptado (bytes aleatorios sin estructura reconocible) realmente parece sospechoso. El tráfico HTTPS normal tiene un perfil estadístico específico: un handshake TLS con cadenas de certificados predecibles, seguido de data de aplicación encriptada con tamaños característicos de record. Una conexión Shadowsocks es un stream de bytes de alta entropía desde el primer paquete. Para un clasificador estadístico, esa diferencia es obvia.
Este es el desafío fundamental. La encriptación hace tu data ilegible, pero el tráfico mismo aún tiene una forma. Los censores no necesitan leer tu data. Sólo necesitan reconocer esa forma.
Por qué falla la ofuscación tradicional
Antes de que existiera Reality, la comunidad de resistencia a la censura intentó varios enfoques de ofuscación de tráfico para este problema.
obfs4 envuelve tráfico en una capa diseñada para parecer ruido aleatorio. Funcionó por un tiempo. Después China e Irán desplegaron clasificadores que flagean streams de alta entropía que no matchean con ningún protocolo conocido. Si el tráfico no se ve como HTTP, HTTPS, DNS, u otro protocolo común, se bloquea o se le hace throttling. El ruido aleatorio es realmente bastante distintivo cuando todo a su alrededor está estructurado.
Shadowsocks tuvo el mismo problema de entropía. Las variantes AEAD mejoraron las cosas, pero el problema fundamental quedó: el tráfico no se ve como nada legítimo. Los sistemas DPI chinos empezaron a bloquear conexiones Shadowsocks detectando la ausencia de un handshake TLS estándar combinado con payloads de alta entropía.
Domain fronting (mandar tráfico a un dominio vía un CDN que lo enruta a otro) funcionó bien hasta que Google, Amazon, y Cloudflare todos lo desactivaron entre 2018 y 2020. Dependía de que los proveedores CDN tolerasen la práctica. Lo dejaron de hacer.
Trojan fue una mejora. Imita HTTPS efectivamente realizando un handshake TLS y sirviendo un sitio web real a conexiones no autorizadas. Pero Trojan usa un certificado TLS auto-configurado, lo que significa que la cadena de certificados es distinta de la que un sitio web real presentaría. Un prober activo que compara el certificado de tu servidor contra logs conocidos de transparencia de certificados puede detectar la discrepancia.
El patrón en todas estas herramientas: tratan de aproximarse al tráfico normal sin ser efectivamente tráfico normal. Dado suficiente análisis, la aproximación siempre se rompe.
RPRX (el creador del proyecto XTLS) resumió el problema claramente: la censura por whitelist de SNI había hecho que todas las herramientas de circunvención basadas en TLS antes de Reality quedaran no disponibles en ciertas áreas de la noche a la mañana. Si un censor decide sólo permitir conexiones a servidores TLS legítimos conocidos, cualquier herramienta usando su propio certificado está muerta.
Cómo funciona realmente Reality
Reality no aproxima un handshake TLS. Realiza uno real.
Acá el flujo de conexión, paso por paso:
Paso 1: El cliente manda ClientHello. Tu cliente inicia un handshake TLS 1.3. El campo Server Name Indication (SNI) contiene el hostname de un sitio web real, popular, como www.microsoft.com. El cliente usa la librería uTLS para copiar el fingerprint TLS exacto de un navegador real (Chrome 120, Firefox, Safari, lo que configurés). El ClientHello es byte-por-byte idéntico a lo que ese navegador mandaría.
Paso 2: El servidor recibe el ClientHello. El servidor Reality verifica un shortId pre-compartido y valida al cliente usando acuerdo de claves X25519. Esta autenticación pasa dentro de campos que son opacos a cualquier observador, ocultos en la extensión key share del handshake TLS.
Paso 3: El servidor contacta al sitio de camuflaje real. El servidor Reality abre su propia conexión TLS al www.microsoft.com real (o cualquier dominio que hayas configurado como target de camuflaje). Realiza un handshake TLS legítimo con los servidores de Microsoft.
Paso 4: El servidor reenvía el certificado real. La cadena de certificados que Microsoft retorna se reenvía al cliente. Este es un certificado real, firmado por una CA real, para un dominio real. No hay nada que detectar porque no hay nada falso.
Paso 5: Los clientes autenticados reciben túnel. Si el cliente pasó la autenticación de shortId y X25519 en el paso 2, el servidor establece el túnel VLESS. El tráfico VPN fluye dentro de lo que parece una sesión HTTPS normal con microsoft.com.
Paso 6: Las conexiones no autenticadas son reenviadas. Si alguien (un prober activo de un censor, un investigador, cualquiera) se conecta sin credenciales válidas, el servidor transparentemente proxy a su conexión a la microsoft.com real. Ven contenido real. Headers reales. Comportamiento real. No hay nada que distinga al servidor de un proxy reverso legítimo.
Esta es la diferencia clave de cualquier enfoque previo. El certificado es real. El sitio web detrás es real. El fingerprint TLS matchea con un navegador real. No hay mentira detectable en toda la cadena.
Resistencia al active probing
Los censores no sólo analizan tráfico pasivamente. Probean servidores sospechosos activamente.
El Great Firewall de China viene haciendo esto desde al menos 2012. Cuando detecta una conexión que podría ser un proxy, replay-ea el handshake del cliente o manda su propio probe al servidor. Si el servidor responde de un modo que difiere de un servicio legítimo, se bloquea.
Así es como los servidores Trojan eventualmente son detectados. Un prober se conecta, no se autentica, y el servidor retorna una página web genérica. Pero el certificado TLS no matchea con lo que los logs de transparencia de certificados dicen que ese dominio debería tener. O los headers de respuesta HTTP son sutilmente distintos de un despliegue real de ese software de servidor web. Inconsistencias chicas, pero suficientes.
Reality derrota el active probing completamente. Cuando un prober se conecta a un servidor Reality sin credenciales válidas, son reenviados al sitio de camuflaje real. La respuesta no es una simulación. ES microsoft.com, servida a través de un proxy transparente. Mismo certificado. Mismos headers. Mismo comportamiento. Mismo contenido.
Un censor necesitaría distinguir entre "un usuario visitando microsoft.com" y "un servidor Reality proxeando a microsoft.com." Desde afuera, son idénticos. La sesión TLS se ve igual. Las respuestas HTTP son las mismas. La dirección IP es lo único que es distinto, y una dirección IP hosteando un proxy reverso a microsoft.com no es inherentemente sospechosa.
Vision flow y TLS-en-TLS
Hay un vector de detección más sutil que Reality también aborda. Cuando corrés una VPN dentro de un túnel TLS, el tráfico VPN encriptado contiene sus propios handshakes TLS (cada sitio HTTPS que visitás genera uno). Esto crea un patrón TLS-en-TLS: records TLS conteniendo lo que claramente son más records TLS, visible a través de análisis de tráfico aunque el contenido esté encriptado.
El XTLS Vision flow (xtls-rprx-vision) elimina esto. En lugar de doble-encriptar el tráfico TLS, Vision detecta cuando el payload interno ya está protegido por TLS y lo pasa con wrapping mínimo. La capa TLS externa maneja autenticación y framing; la data TLS interna fluye sin encriptación redundante.
Un paper de USENIX confirmó que Vision logró sus metas de diseño. El patrón de tráfico de una conexión VLESS+Vision es estadísticamente indistinguible de una conexión HTTPS directa al sitio de camuflaje.
Esto importa porque el análisis de tráfico (mirando tamaños de paquete, timing, y patrones sin desencriptar nada) es el ataque restante más plausible contra Reality. Vision cierra ese gap.
Qué lo hace difícil de bloquear
Para bloquear VLESS Reality, un censor necesitaría hacer una de las siguientes:
Bloquear el dominio de camuflaje completamente. Si Reality está configurado para impersonar microsoft.com, el censor necesitaría bloquear microsoft.com. O google.com. O cualquier otro dominio que los operadores elijan. Bloquear servicios mayores de nube y productividad tiene costos económicos enormes. China ha aceptado ese costo para algunos servicios, pero hasta China no ha bloqueado microsoft.com.
Detectar la autenticación X25519 en el handshake TLS. Esta información se lleva en la extensión key share, que está encriptada en TLS 1.3. Sin romper el handshake TLS en sí, la autenticación es invisible.
Identificar servidores Reality por reputación de IP. Este es realmente el enfoque más efectivo que los censores han encontrado hasta ahora. El TSPU de Rusia ha empezado a flagear direcciones IP de VPS que reciben conexiones matcheando ciertos patrones de comportamiento: conexiones de IPs residenciales a IPs VPS que también proxy-ean a sitios bien conocidos. Esto no es detectar Reality en sí. Es detectar los patrones de infraestructura alrededor. La tasa de detección para VLESS Reality correctamente configurado está aún por debajo del 5% basado en reportes de la comunidad de febrero 2026.
Análisis de timing de tráfico. El tráfico VPN tiene características de timing distintas que la navegación web normal. Un usuario streameando video por Reality genera flujos sostenidos de alto throughput que no matchean los patrones típicos de navegación HTTPS a microsoft.com. Esta es una debilidad real, aunque requiere análisis sofisticado y produce muchos falsos positivos.
Irán ha estado investigando el bloqueo de Reality (discutido en GitHub issue #3269 en el repositorio de Xray-core). Hasta ahora, ningún método confiable de detección ha sido desplegado. El enfoque ruso de scoring de reputación de IP es el más exitoso, pero atrapa una pequeña fracción de conexiones y requiere ajuste manual constante.
Los trade-offs
Corremos VLESS Reality en producción en Fexyn, junto a WireGuard y OpenVPN. No vamos a pretender que es un almuerzo gratis. Hay costos reales.
Latencia. Una conexión Reality agrega aproximadamente 100ms de latencia comparado con WireGuard. El handshake TLS extra con el sitio de camuflaje, la autenticación X25519, y la capa de proxying todos toman tiempo. Para navegación general, esto es apenas notable. Para gaming o voz en tiempo real, lo vas a sentir.
Overhead TCP. VLESS Reality corre sobre TCP. WireGuard corre sobre UDP. TCP tiene head-of-line blocking: si un paquete se pierde, todo lo que está detrás espera. En redes con pérdida (conexiones móviles, Wi-Fi congestionado), esto significa stalls periódicos que los protocolos basados en UDP evitan. El modo de transporte XHTTP ayuda multiplexando, pero la limitación fundamental TCP queda.
Complejidad de configuración. WireGuard necesita un par de claves y un endpoint. Reality necesita un dominio de camuflaje, un shortId, un par de claves X25519, una selección de fingerprint uTLS, una configuración de transporte, y testeo cuidadoso para asegurarse de que el sitio de camuflaje funciona correctamente. Manejamos esto automáticamente en Fexyn (el cliente recibe una configuración completa de nuestro API), pero los self-hosters tienen más para gestionar.
Dificultad de debugging. Cuando una conexión WireGuard falla, los modos de falla son directos: clave incorrecta, endpoint incorrecto, puerto bloqueado. Cuando una conexión Reality falla, podría ser el dominio de camuflaje, el shortId, el par de claves, el fingerprint uTLS, la capa de transporte, el sitio de camuflaje siendo inalcanzable desde el servidor, o media docena de otras cosas. Hemos pasado tiempo significativo de debugging en conexiones Reality que terminaron siendo problemas de dominio de camuflaje.
No todos los dominios de camuflaje funcionan igual de bien. El sitio de camuflaje necesita soportar TLS 1.3, tener un certificado que enlaza a una CA confiable, y ser alcanzable desde tu servidor. Algunos dominios funcionan perfectamente. Otros tienen quirks que causan fallas sutiles. Hemos testeado extensivamente y nos asentamos en un set de targets confiables de camuflaje, pero esto requirió trabajo real de prueba-y-error.
Tasas de detección del mundo real
Basado en reportes de la comunidad y nuestro propio testeo:
| País | WireGuard | OpenVPN | VLESS Reality |
|---|---|---|---|
| Rusia (TSPU) | Bloqueado al instante | Bloqueado/throttled | ~95% éxito |
| China (GFW) | Bloqueado | Bloqueado | Funciona, bloqueos IP periódicos |
| Irán | Bloqueado | Intermitente | Funciona, bajo investigación activa |
| Turkmenistán | Bloqueado | Bloqueado | Datos limitados, reportado funcionando |
La tasa de fallo del ~5% en Rusia viene primariamente del scoring de reputación de IP, no de detección de protocolo. Usar rangos IP que parecen residenciales o proveedores de nube que no están en blacklists lleva la tasa de éxito cerca del 100%.
En China, la amenaza principal es el bloqueo basado en IP en lugar de detección de protocolo. El GFW mantiene listas de rangos IP de VPS conocidos y periódicamente los bloquea. Las conexiones Reality desde IPs limpias funcionan consistentemente.
Cuándo usarlo
Si estás en un país sin censura activa, WireGuard es la mejor elección. Es más rápido, más simple, y usa UDP. No hay razón para aceptar los trade-offs de Reality si nadie está tratando de bloquear tu conexión.
Si estás en o viajando a un país con DPI activo (Rusia, China, Irán, EAU, muchos otros), VLESS Reality con Vision flow es el protocolo que efectivamente funciona. WireGuard será bloqueado antes de que termines el handshake.
Fexyn soporta ambos, con rotación automática de protocolo que cambia a VLESS Reality cuando WireGuard está bloqueado. Obtenés la velocidad de WireGuard cuando está disponible y la resistencia a la censura de Reality cuando la necesitás.
Si querés entender más sobre el protocolo VLESS en sí (separado del transporte Reality), escribimos un desglose detallado de VLESS que cubre la arquitectura del protocolo y cómo se compara con alternativas.
Probá Fexyn gratis 7 días: Stealth (VLESS Reality con Vision flow) está incluido en cada plan. Activistas y organizadores de movimiento pueden querer la página VPN para activistas por el framing del modelo de amenaza.