XRay core explicado

La gente sigue llamando a XRay un protocolo VPN. No lo es. XRay es una plataforma proxy. Piénsalo como nginx, pero en vez de rutear solicitudes HTTP a servidores backend, rutea conexiones de red enteras a través de túneles encriptados usando cualquier protocolo que quieras.

VLESS es un protocolo. Reality es una capa de autenticación. WireGuard es un protocolo. XRay es la cosa que corre VLESS y Reality del lado del servidor. Acertar esta distinción importa si quieres entender por qué el ecosistema de resistencia a censura funciona como funciona.

De dónde vino XRay

La historia empieza con V2Ray, un proyecto creado alrededor de 2015 por alguien usando el seudónimo "Victoria Raymond". V2Ray introdujo el protocolo VMess y una arquitectura modular donde podías intercambiar transportes (TCP, WebSocket, gRPC) independientemente del protocolo proxy mismo. Era una buena idea y ganó tracción rápido, especialmente en China donde la gente necesitaba herramientas que pudieran sobrevivir al Great Firewall.

Para 2020, el creador original de V2Ray se había quedado callado. La comunidad V2Fly mantenía un fork llamado v2fly-core. Un desarrollador conocido como RPRX contribuyó XTLS, una optimización de rendimiento que dejaba al tráfico proxy saltarse capas redundantes de encriptación TLS. Era una contribución técnica significativa.

Después las cosas se complicaron.

En noviembre de 2020, el código XTLS de RPRX fue removido de v2ray-core por una disputa de licenciamiento. Los detalles son complicados y algo políticos, pero el resultado fue limpio: RPRX forkeó v2fly-core (desde el commit 9a03cc5) y creó xray-core. Una ruptura limpia.

XRay se movió más rápido tras la división. RPRX envió XTLS Vision, después Reality, después XHTTP. El proyecto actualmente está en 35,900+ estrellas de GitHub vs los aproximadamente 22,000 de V2Ray. La comunidad votó con sus commits. La mayoría del desarrollo activo en el espacio de proxy anti-censura ahora pasa en xray-core o proyectos construidos sobre él.

Qué hace realmente XRay

XRay es un binario Go. Le das un config JSON que define inbounds (listeners) y outbounds (destinos), y hace proxy de tráfico entre ellos. Ese es todo el modelo.

El poder está en lo que puedes combinar. XRay soporta múltiples protocolos proxy:

• VLESS, que es ligero sin overhead de encriptación (depende de la capa de transporte para eso)
• VMess, el protocolo original de V2Ray con encriptación AES-128-GCM (la auth MD5 fue removida recientemente)
• Trojan, que imita tráfico HTTPS usando auth basada en contraseña
• Shadowsocks-2022, la reescritura moderna con ciphers AEAD-2022

Cada uno de estos puede correr sobre cualquiera de los transportes de XRay:

• TCP raw
• mKCP (basado en UDP, como KCP pero modificado)
• WebSocket
• HTTP/2 (h2)
• gRPC
• QUIC
• XHTTP (transporte HTTP multiplexado propio de XRay, agregado en 2025)

Así que puedes correr VLESS sobre WebSocket detrás de un CDN, o Trojan sobre gRPC a través de Cloudflare, o VLESS sobre TCP raw con autenticación Reality. El protocolo y el transporte son independientes. Mezcla y combina según lo que tu entorno de red permita.

XRay también tiene un motor de routing. Puedes escribir reglas que mandan tráfico para ciertos dominios por un outbound, bloquean anuncios por otro y dirigen todo lo demás por el proxy. Está más cerca de un stack de red programable que de un túnel simple.

XTLS y por qué importa el rendimiento

Los setups de proxy estándar tienen un problema. Cuando visitas https://ejemplo.com por un proxy, la encriptación TLS pasa dos veces: una entre tu navegador y ejemplo.com (TLS interno), y una entre tu cliente y el servidor proxy (TLS externo). Estás encriptando data ya encriptada. Eso es CPU desperdiciado y latencia agregada.

XTLS Vision arregla esto. Cuando XRay detecta que la conexión interna ya es TLS 1.3, deja de encriptar el payload en la capa proxy después de que el handshake termina. El TLS interno provee confidencialidad. La capa externa sólo necesita manejar la negociación inicial.

XTLS splice va más allá en Linux. Usa el syscall splice() del kernel para reenviar data TCP directamente entre file descriptors sin copiarla a través de memoria de userspace en absoluto. La data se mueve del socket de red al socket del túnel enteramente en kernel space. El proceso Go de XRay apenas la toca.

El resultado: throughput de proxy que está dentro de pocos puntos porcentuales de una conexión directa. En un servidor con un link de 1 Gbps, XTLS splice puede saturarlo. Los proxies tradicionales con doble encriptación se topan bien por debajo.

Por esto VLESS con Reality rinde mucho mejor que herramientas de evasión más viejas. El protocolo es ligero, el transporte es eficiente y XTLS elimina el impuesto de encriptación redundante.

El ecosistema alrededor de XRay

XRay es el motor. Un ecosistema entero de herramientas ha crecido alrededor.

Paneles de gestión de servidor como 3X-UI te dan una interfaz web para configurar inbounds de XRay, manejar cuentas de usuario y monitorear ancho de banda. Son populares para servidores proxy personales porque remueven la necesidad de editar configs JSON a mano. Si has visto screenshots del setup proxy de alguien con gráficos lindos y listas de usuarios, probablemente es 3X-UI o un fork de él.

Clientes de escritorio como V2RayN (Windows) y V2RayA (Linux) envuelven xray-core con una GUI. Leen links de suscripción, manejan listas de servidores y manejan reglas de routing. La mayoría de los usuarios en países censurados interactúan con XRay a través de uno de estos clientes, no con el binario raw.

sing-box es el interesante. Es una plataforma proxy más nueva escrita desde cero por el desarrollador de SagerNet. Soporta todos los protocolos de XRay (VLESS, VMess, Trojan, Shadowsocks) más Hysteria2, TUIC y otros. Más importante, compila a librería móvil vía gomobile. Eso es lo que hace posible VLESS Reality en teléfonos. No puedes razonablemente correr xray-core en iOS o Android, pero puedes embeber libbox de sing-box en una app nativa.

El ecosistema se divide aproximadamente en estas líneas: xray-core domina en servidores, V2RayN/V2RayA en escritorios y sing-box en móvil. Todos hablan los mismos protocolos.

Cómo Fexyn usa XRay

Corremos xray-core en nuestros servidores VPN. Cada servidor tiene un inbound de VLESS Reality en puerto 443 (TCP con autenticación Reality) y un inbound XHTTP en puerto 8444 (para entornos donde TCP raw al puerto 443 está filtrado pero los transportes basados en HTTP pasan).

En el servidor, nuestro Fexyn Agent maneja el proceso xray-core, maneja rotación de llaves y provee UUID por usuario. Cuando te conectas con VLESS seleccionado, el agente genera tus credenciales y el cliente recibe un config que apunta al servidor correcto con las llaves Reality correctas.

El lado del cliente es donde se pone interesante. En Windows, no usamos xray-core para nada. En cambio, creamos un adaptador TUN Wintun y corremos tun2socks para rutear todo el tráfico del sistema a un proxy SOCKS5 que provee xray-core. En realidad, corremos un xray-core reducido en modo proxy SOCKS, y tun2socks captura paquetes de la interfaz TUN, reconstruye sesiones TCP/UDP y las reenvía a través de ese proxy SOCKS. El sistema operativo ve un adaptador de red normal. Todo el tráfico pasa por él. Sin configuración de proxy a nivel de app necesaria.

En Android e iOS, usamos sing-box compilado como librería nativa. Maneja el mismo protocolo VLESS Reality pero corre dentro del framework VPN del SO (VpnService de Android, NEPacketTunnelProvider de iOS). sing-box fue la elección correcta aquí porque xray-core no buildea limpio para plataformas móviles, y libbox de sing-box fue diseñado para exactamente este caso de uso.

El resultado es el mismo en todas las plataformas: tu tráfico parece alguien navegando microsoft.com (o cualquier SNI que el config Reality apunte). Los sistemas DPI ven una conexión TLS 1.3 a un dominio legítimo. Las sondas activas contra nuestro servidor son redirigidas al sitio real. La comparación de protocolo con WireGuard se reduce exactamente a esto: WireGuard es más rápido pero trivialmente fingerprinteable, mientras VLESS Reality sacrifica algo de throughput por invisibilidad casi total.

XRay comparado con otras herramientas

El espacio anti-censura tiene muchos proyectos. Aquí está dónde encaja XRay.

Shadowsocks fue el original. Proxy encriptado simple, rápido, de propósito único. La reescritura de 2022 (Shadowsocks-2022) arregló debilidades criptográficas viejas, pero Shadowsocks tiene un problema de detección: el GFW puede identificar sus patrones de tráfico a través de análisis estadístico de longitudes y timing de paquetes. Todavía funciona en algunas regiones. Es menos confiable que VLESS Reality en las muy censuradas.

V2Ray (v2fly-core) es el ancestro de XRay. Todavía mantenido, todavía funciona. Pero le falta XTLS Vision, Reality y XHTTP. Si necesitas esas funciones, y en 2026 casi seguro las necesitas, necesitas xray-core.

Trojan-GFW fue ingenioso cuando se lanzó. Disfraza tráfico proxy como HTTPS corriendo un servidor web real junto al proxy. Reality llevó esta idea más lejos eliminando la necesidad de tener un certificado TLS real para el dominio objetivo.

Hysteria 2 usa QUIC (basado en UDP) con ofuscación. Gran throughput, pero los protocolos basados en QUIC están recibiendo más atención de los censores. Algunas redes ahora bloquean o throttlean QUIC enteramente. Las herramientas basadas en TCP como VLESS Reality son más difíciles de bloquear de manera amplia porque tendrías que bloquear HTTPS mismo.

NaiveProxy usa el stack de red de Chrome para generar tráfico estadísticamente idéntico a un navegador Chrome real. Muy difícil de detectar, pero el setup del lado del cliente es más complejo y no tiene el mismo ecosistema de paneles y clientes.

La ventaja de XRay no es que haga una cosa mejor que cada alternativa. La ventaja es que es una plataforma. Corre múltiples protocolos, soporta múltiples transportes, tiene un motor de routing maduro y tiene la comunidad activa más grande. Cuando el GFW desarrolla un nuevo método de detección, xray-core obtiene una contramedida en semanas. Ese es el beneficio de 35,000+ estrellas y un mantenedor activo que trata esto como una carrera armamentista.

A dónde va

El desarrollo de XRay no se ha frenado. Releases recientes quitaron código legacy: la autenticación MD5 de VMess se fue, el soporte MTProto fue removido. La base de código se está volviendo más liviana.

Dos funciones próximas destacan. XDRIVE es un transporte que disfraza tráfico proxy como operaciones de almacenamiento en la nube. XICMP usa paquetes ICMP como capa de transporte. Ambos son experimentales, pero representan el mismo patrón que ha definido la evolución de XRay: encuentra un tipo de tráfico que los censores permiten, y construye un transporte alrededor.

El esquema de versión te dice algo sobre el ritmo. XRay usa formato vYY.M.DD. La versión v26.2.6 significa 6 de febrero de 2026. Las releases son frecuentes. El proyecto se mueve rápido porque tiene que. El Great Firewall no espera por ciclos de release trimestrales.

Si estás construyendo algo que necesita sobrevivir en una red censurada, XRay es el motor que probablemente quieres corriendo del lado del servidor. No es la única opción. Pero es el que tiene más momentum, el soporte de protocolos más amplio y la respuesta más rápida a nuevas técnicas de censura. Por eso lo elegimos para Fexyn.