La pila VLESS moderna en 2026

En 2026, VLESS sigue siendo un protocolo proxy ligero y sin estado, pero decir que «VLESS no tiene cifrado» ya no es una descripción completa. Xray-core ofrece ahora VLESS Encryption como opción. Además, los despliegues pueden combinar VLESS con TLS, REALITY, XTLS Vision, XHTTP y XUDP según su modelo de amenazas. Estas capas resuelven problemas distintos y no deberían fundirse en un solo protocolo.

Política de fuentes: Esta guía utiliza fuentes primarias de Project X, Xray-core, sing-box y AnyTLS. Las pull requests y los debates de GitHub documentan el diseño y la implementación de los mantenedores; no son auditorías de seguridad independientes. Las referencias a SingLink son comparaciones de arquitectura, no afirmaciones de que SingLinkVPN implemente estos proyectos.

1. La pila VLESS moderna de un vistazo

• VLESS: una capa ligera de identidad, comando y destino.
• VLESS Encryption: una capa nativa y opcional de protección de la carga útil en el Xray-core actual.
• TLS 1.3 / REALITY: seguridad del transporte exterior, autenticación y apariencia en la red.
• XTLS Vision: control de flujo y optimización de la ruta de datos, no un cifrado independiente.
• RAW / XHTTP / gRPC / WebSocket: transportes que llevan los datos del proxy.
• XUDP: una opción de codificación de paquetes UDP en el ecosistema Xray.
• XMUX y otros sistemas MUX: formas de compartir las conexiones subyacentes.
• Padding / FinalMask / Browser Dialer: herramientas para la longitud, la temporización, el comportamiento del transporte exterior o el uso de la red del navegador.

Así, una conexión puede modelarse como tráfico de la aplicación → identidad y destino de VLESS → seguridad del protocolo o exterior → control de flujo de Vision → un transporte como RAW o XHTTP → TCP o UDP. No todos los módulos son necesarios ni compatibles en todos los diseños.

2. Qué hace el protocolo base VLESS

La documentación de Project X define VLESS como un protocolo de transporte ligero y sin estado que no depende de la hora del sistema y usa un UUID o un ID asignado para la autenticación. La implementación pública de la codificación en Xray-core muestra la versión, el ID de usuario, los addons, el comando, el puerto de destino, la dirección y los datos que siguen.

En la práctica, la capa base responde a estas preguntas: ¿quién es el cliente, qué conexión se solicita y adónde debe ir? El enrutamiento inteligente, la carga de los nodos, los permisos según el plan y la reconexión automática suelen pertenecer a capas superiores de producto y de control.

Las configuraciones tradicionales suelen usar `encryption: "none"`. Las indicaciones actuales de Project X exigen seguridad en el transporte exterior, salvo que el extremo remoto y el enlace sean infraestructura privada de confianza o que esté activado VLESS Encryption.

3. Qué cambia VLESS Encryption

VLESS Encryption es una capa de protección nativa y opcional que se incorporó a Xray-core en 2025. La PR #5067 fusionada y la documentación de configuración actual describen el handshake `mlkem768x25519plus`, las apariencias `native`, `xorpub` y `random`, el comportamiento de sesión `1rtt` y `0rtt` y el relleno variable.

Objetivos de diseño publicados

• Derivar las claves de sesión mediante una combinación de ML-KEM-768 y X25519;
• proteger las cargas útiles de VLESS sin necesidad de TLS exterior;
• usar tickets para la reanudación 0-RTT posterior y un estado de corta duración para reducir el riesgo de repetición;
• usar relleno variable y modos XOR opcionales para alterar las apariencias de longitud fija o de clave pública.

Estas son afirmaciones de diseño e implementación de los mantenedores. No hemos encontrado una auditoría criptográfica independiente que cubra todas las propiedades, así que esta guía no califica el diseño de «inmune a la repetición» ni de «absolutamente resistente a la computación cuántica».

Lo que no sustituye automáticamente

VLESS Encryption protege la carga útil del protocolo. No crea automáticamente una cadena de certificados HTTPS normal, un handshake de sitio web, un comportamiento HTTP/2 o HTTP/3 ni compatibilidad con CDN. Por tanto, no equivale a TLS ni a REALITY.

4. TLS 1.3 y REALITY

TLS ofrece validación de certificados estandarizada, intercambio de claves, integridad y cifrado del transporte. Puede acompañar a RAW, XHTTP, gRPC o WebSocket; la versión negociada, el ALPN y las comprobaciones de certificados siguen dependiendo de la configuración y de lo que admita el extremo remoto.

La documentación de REALITY de Project X describe una capa de seguridad modificada de estilo TLS con los ajustes target, serverNames, claves X25519 y shortId, además de datos de verificación ML-DSA-65 opcionales. REALITY puede acompañar a RAW, XHTTP y gRPC.

REALITY no debería reducirse a «TLS sin certificado». Su comportamiento combina la autorización del cliente con la apariencia de un handshake externo. Los resultados siguen dependiendo del destino, la huella del cliente, el transporte y la calidad del despliegue; no puede garantizar ser invisible para cualquier clasificador.

5. XTLS Vision no es un protocolo de cifrado

La documentación de VLESS/Vision clasifica Vision como control de flujo. En las condiciones admitidas, puede reconocer el tráfico TLS interno y reducir el cifrado o las copias adicionales. En rutas Linux y TCP compatibles, el núcleo puede intentar usar `splice` para que el kernel transfiera los datos directamente.

La división precisa es esta: TLS, REALITY o VLESS Encryption aportan la seguridad; Vision optimiza cómo viajan los datos protegidos por la capa del proxy. No todas las plataformas, transportes o tipos de tráfico pueden usar splice.

6. Los tres modos de XHTTP

El debate de diseño de XHTTP de los mantenedores describe un sistema de transporte HTTP que puede funcionar en entornos HTTP/1.1, HTTP/2 y HTTP/3:

• packet-up: varias solicitudes POST de subida con una respuesta de bajada continua; pensado para una amplia compatibilidad con intermediarios.
• stream-up: un POST de subida en streaming y un GET de bajada en streaming independiente.
• stream-one: una única solicitud bidireccional en streaming; el rendimiento y la compatibilidad dependen de los intermediarios.

XHTTP también puede usar relleno en las cabeceras, rutas separadas de subida y bajada y XMUX. Que funcione a través de una CDN concreta depende del modo, la versión de HTTP, el comportamiento del proxy inverso y la configuración del proveedor.

7. XMUX, la multiplexación general y el bloqueo de cabeza de línea

XMUX gestiona la concurrencia de XHTTP, el número de conexiones subyacentes, su reutilización, su duración y el keepalive. Su objetivo no es mantener exactamente una conexión para siempre, sino equilibrar el coste de los handshakes, la concurrencia y los patrones de conexión de larga duración.

La documentación de multiplexación de sing-box también incluye smux, yamux y h2mux. La multiplexación puede reducir los handshakes, pero una pérdida o un bloqueo en una conexión TCP subyacente puede afectar a varios flujos. HTTP/3 evita el bloqueo de cabeza de línea entre flujos a nivel de TCP, aunque un flujo QUIC concreto puede seguir esperando a que se recupere una pérdida.

8. XUDP es una opción de codificación UDP

La documentación de VLESS de sing-box incluye `xudp` como opción de codificación de paquetes, junto con `packetaddr` y la posibilidad de desactivar la codificación adicional. Esto respalda la conclusión limitada de que XUDP transporta UDP en este ecosistema; no es una especificación de paquetes completa y versionada.

El comportamiento detallado de las sesiones, las direcciones, los límites y la migración debe comprobarse con la versión exacta del núcleo y su código. Esta guía evita deliberadamente presentar detalles de encapsulado deducidos como si fueran un estándar universal.

9. Padding, FinalMask, ECH y Browser Dialer

• Padding: cambia las características de longitud o de temporización; no es cifrado.
• FinalMask: su documentación de configuración lo sitúa en una fase exterior de procesamiento del transporte, con ajustes relacionados con TCP, UDP y QUIC.
• ECH: la documentación de TLS de sing-box incluye la configuración de Encrypted ClientHello para proteger parte del ClientHello; ECH no sustituye al cifrado del túnel.
• Browser Dialer: según la documentación de Project X, permite que un navegador real establezca las conexiones TLS y HTTP, lo que aporta un comportamiento de navegador más auténtico a cambio de limitaciones de despliegue y de rendimiento.

10. Lo que Fallback puede y no puede hacer

La documentación de Fallback de Project X muestra cómo el tráfico cuyo SNI, ruta o protocolo no coincide puede reenviarse a Nginx, Caddy o un sitio web normal, de modo que un mismo punto de entrada aloje el proxy y servicios corrientes.

Fallback puede evitar que todos los intentos de autenticación fallidos reciban el mismo error evidente. No es inmunidad frente al sondeo activo; que se pueda reconocer sigue dependiendo de TLS, el transporte, las respuestas, la temporización y la configuración del servidor.

11. AnyTLS es una comparación, no un componente de VLESS

El documento del protocolo AnyTLS describe TCP → TLS → autenticación con `SHA-256(password)` → una sesión → varios flujos. Las tramas contienen Command, Stream ID, Data Length y Data, con los comandos SYN, PSH, FIN, settings, padding, heartbeat y SYNACK de la versión 2.

Su modelo de sesión, sus múltiples flujos, su relleno dinámico y sus comprobaciones de estado sirven como comparación útil. AnyTLS sigue siendo un protocolo distinto; VLESS no hereda automáticamente estas funciones.

12. Combinaciones habituales y sus límites

• VLESS + REALITY + Vision + RAW: orientada al rendimiento directo y a una apariencia exterior de estilo TLS; sin depender de una CDN.
• VLESS + TLS/REALITY + XHTTP: orientada al transporte sobre HTTP, a los proxies inversos y a una compatibilidad condicional con CDN.
• VLESS Encryption + Vision: protege la carga útil del protocolo en escenarios de retransmisión o con seguridad exterior no estándar, sin una apariencia HTTPS normal.
• VLESS + TLS + XHTTP + Browser Dialer: usa la pila de red de un navegador real, con un coste operativo mayor.
• AnyTLS + TLS: un diseño propio de sesiones, flujos y relleno, no una pila VLESS.

Ninguna configuración es siempre la mejor a la vez en rendimiento, compatibilidad, mantenimiento, apariencia y seguridad. La elección debe empezar por un modelo de amenazas, la ruta de red, las limitaciones de la CDN o del proxy, las plataformas cliente y los requisitos de observabilidad.

13. Qué significa esto para la investigación de SingLink

Los materiales públicos de VLESS y AnyTLS pueden orientar la investigación sobre identidad, intercambio de claves, sesiones, flujos, UDP, relleno, multiplexación, recuperación y negociación de versiones. Este artículo no demuestra que SingLink 2.0 se base en VLESS, REALITY, XHTTP o AnyTLS.

SingLinkVPN debería seguir separando el comportamiento publicado, las líneas de investigación y la implementación no divulgada. Consulta el plan de código abierto de SingLinkVPN para conocer el alcance publicado actualmente.

14. Preguntas frecuentes (FAQ)

¿VLESS cifra el tráfico por sí solo?

La configuración tradicional `encryption: "none"` no protege la carga útil del protocolo y requiere infraestructura privada de confianza o seguridad exterior. El Xray-core actual puede activar VLESS Encryption, así que la respuesta depende de la implementación y de la configuración.

¿Puede VLESS Encryption sustituir a TLS o a REALITY?

No como equivalente. VLESS Encryption protege las cargas útiles de VLESS, pero no ofrece automáticamente un certificado HTTPS estándar, un handshake ni la apariencia de un sitio web.

¿XTLS Vision realiza cifrado?

No. XTLS Vision ofrece principalmente control de flujo y optimización de la ruta de datos.

¿Cómo elegir entre los tres modos de XHTTP?

packet-up prioriza la compatibilidad, stream-up separa las direcciones del streaming y stream-one usa un único flujo bidireccional. Cada modo debe probarse con la ruta real de intermediarios.

¿En qué se diferencia XUDP de un proxy UDP genérico?

XUDP es una opción de codificación UDP del ecosistema Xray. Su comportamiento exacto depende del núcleo y de la versión, y no debería deducirse solo por el nombre.

¿SingLink 2.0 se basa en VLESS o en AnyTLS?

No hay suficientes pruebas públicas para establecer esa relación. Este artículo es una comparación técnica, no una divulgación de la implementación.

15. Conclusión y fecha de las fuentes

VLESS moderno es una pila combinable: VLESS lleva la identidad y el destino, VLESS Encryption añade una protección opcional en la capa del protocolo, TLS o REALITY aportan la seguridad exterior, Vision optimiza el flujo, XHTTP y XUDP transportan el tráfico, y la multiplexación o el relleno modifican aún más el comportamiento de la conexión.

Fecha de publicación original: 20 de mayo de 2026. Fuentes técnicas revisadas: 28 de julio de 2026. Estos proyectos siguen cambiando; antes de desplegar, comprueba la documentación, el registro de cambios y la compatibilidad de la versión exacta.