VLESS vs WireGuard
WireGuard es probablemente el mejor protocolo VPN diseñado para redes no restringidas. VLESS Reality es probablemente el mejor protocolo para redes donde alguien está activamente tratando de pararte. Estos son problemas distintos, y los protocolos que los resuelven no se parecen en nada.
La mayoría de los artículos comparativos eligen un ganador. Nosotros no, porque la respuesta depende de dónde estés y de cómo se ve la red entre vos y el servidor. Enviamos ambos protocolos en Fexyn y auto-cambiamos entre ellos por esta razón. (Para una visión más alta de qué es realmente un protocolo VPN, empezá ahí.)
Acá lo que realmente importa al elegir entre ellos.
WireGuard: por qué se volvió el default
WireGuard ganó su reputación. El protocolo entero son aproximadamente 4,000 líneas de código de kernel. Para comparación, OpenVPN tiene más de 100,000 líneas. Las implementaciones IPsec corren incluso más largo. Codebases más chicos significan menos lugares para que se escondan bugs, lo que importa enormemente para software crítico de seguridad.
Las elecciones criptográficas son opinionadas y fijas: ChaCha20-Poly1305 para encriptación simétrica, Curve25519 para intercambio de claves, BLAKE2s para hashing. No hay negociación de cifradores, ni matriz de configuración, ni menú de "elegí tu algoritmo favorito." Esta es una decisión deliberada de diseño de Jason Donenfeld, y elimina toda una clase de ataques de downgrade que plagan a los protocolos con cipher suites configurables.
El rendimiento sigue de la arquitectura. WireGuard opera a nivel kernel (o en userspace vía boringtun), procesando paquetes con context switching mínimo. El transporte UDP evita por completo el problema de head-of-line blocking de TCP. En una conexión de fibra de 500 Mbps, WireGuard consistentemente entrega alrededor de 480 Mbps en nuestros tests. Eso es 96% del throughput baseline. Apenas estás pagando un impuesto por la encriptación.
El establecimiento de conexión es rápido también. Un handshake WireGuard es una sola round trip: el iniciador manda un mensaje encriptado, el responder manda uno de vuelta, y el túnel está vivo. En la implementación de Fexyn en Windows, la secuencia de conexión completa desde "el usuario hace click en conectar" a "tráfico fluyendo por el túnel" promedia cerca de 611 milisegundos. La mayor parte de ese tiempo se gasta seteando el adaptador TUN y configurando rutas, no esperando al protocolo en sí.
Para la mayoría de los usuarios en la mayoría de las redes, WireGuard es la elección correcta. Es rápido, es simple, y ha tenido años de hardening en producción a través de Linux, Windows, macOS, iOS, y Android.
El problema de los 148 bytes
WireGuard tiene una debilidad que ninguna cantidad de ingeniería astuta puede arreglar, porque es una consecuencia directa de la filosofía de diseño del protocolo.
Cada mensaje de iniciación de handshake WireGuard es exactamente 148 bytes de largo. El primer byte es 0x01 (tipo de mensaje 1: iniciación de handshake). Los siguientes tres bytes son 0x00 0x00 0x00 (reservados, siempre cero). Esto es seguido por un sender index de 4 bytes y luego una clave pública efímera Curve25519 no encriptada de 32 bytes.
Esta estructura nunca varía. No puede variar; la especificación del protocolo lo requiere.
Los sistemas de inspección profunda de paquetes explotan esto. La lógica de detección es vergonzosamente simple. Acá lo que nDPI, una librería DPI open-source usada por vendedores de equipamiento de red en todo el mundo, efectivamente chequea:
if (message_type == 1 && packet_length == 148)
→ clasificar como WireGuard
Eso es todo. Una condicional. El handshake de 148 bytes con un 0x01 0x00 0x00 0x00 líder es un fingerprint único que ningún otro protocolo produce. No necesitás machine learning o análisis estadístico. Un estudiante de primer año de networking podría escribir este filtro.
El TSPU de Rusia (Sistemas Técnicos para Contrarrestar Amenazas) viene bloqueando WireGuard con precisión cercana al 100% desde mediados de 2024. No throttling, no degradando. Bloqueando. Los paquetes UDP cargando handshakes WireGuard simplemente desaparecen. El Great Firewall de China hace lo mismo. Irán lo bloquea. Cualquier gobierno corriendo equipamiento DPI moderno puede agregar WireGuard a su blocklist en una tarde.
El proyecto WireGuard está al tanto de esto. No es un bug. El protocolo fue diseñado para velocidad y simplicidad, no para sigilo. Hacer el handshake de longitud variable o agregar padding complicaría el protocolo y violaría el principio core de diseño de complejidad mínima. Estos son trade-offs razonables para el modelo de amenaza al que WireGuard apunta. Sólo significan que WireGuard es la herramienta incorrecta si estás en una red donde alguien está activamente inspeccionando tráfico.
AmneziaWG: un fix parcial
AmneziaWG 2.0 intenta abordar el problema de fingerprinting agregando padding aleatorio a paquetes WireGuard, usando headers dinámicos, e inyectando paquetes basura. Sí hace la detección más difícil. Pero aún está trabajando dentro del framework basado en UDP de WireGuard, lo que significa que los censores pueden aplicar análisis estadístico a la distribución de tamaño de paquete, intervalos de timing, y características de entropía. El tráfico UDP que no matchea con ningún protocolo conocido es sospechoso por defecto en entornos pesadamente censurados.
AmneziaWG es un paso adelante. No es una solución al problema fundamental.
VLESS Reality: ocultarse a plena vista
VLESS toma el enfoque opuesto a WireGuard en casi cada forma. Donde WireGuard es un protocolo VPN construido a propósito con un formato de cable único, VLESS es un protocolo proxy que delega su encriptación enteramente a TLS 1.3. El header VLESS en sí agrega sólo 25 a 50 bytes de overhead, conteniendo un byte de versión, un UUID para autenticación, e información de enrutamiento.
El protocolo sólo tiene sentido dentro de una conexión TLS. Sacá TLS y VLESS no tiene encriptación, no tiene protección de integridad, nada. Esta dependencia de TLS es frecuentemente criticada como debilidad. Es realmente la fuente de la mayor fortaleza de VLESS.
VLESS Reality con Vision flow extiende el protocolo base con un sistema de camuflaje que hace que la conexión sea genuinamente indistinguible del tráfico HTTPS normal. Cuando te conectás a un servidor Fexyn usando Reality+Vision, el servidor realiza un handshake TLS real con un sitio web actual, como www.microsoft.com, y reenvía el certificado legítimo de ese sitio a tu cliente. Tu cliente usa la librería uTLS para producir un mensaje ClientHello que es byte-por-byte idéntico a lo que Chrome o Firefox mandarían.
Si un censor probea al servidor, son reenviados a la microsoft.com real. Certificado real. Contenido real. Headers HTTP reales. No hay simulación involucrada. El servidor funciona como un proxy reverso transparente para conexiones no autenticadas y como un túnel VLESS para las autenticadas.
El resultado es que ningún sistema DPI pasivo puede distinguir una sesión VLESS Reality de alguien navegando el sitio web de Microsoft. El active probing también falla porque el probe recibe respuestas genuinas de un sitio web genuino. La detección requeriría que el censor de algún modo diferencie entre "un usuario visitando microsoft.com" y "un servidor Reality proxeando a microsoft.com," lo que desde una perspectiva de red son la misma cosa.
Esto funciona en Rusia. Funciona en China. Funciona en Irán. No teóricamente. Ahora mismo, en producción, para usuarios reales.
Lo que VLESS resigna
VLESS Reality no es gratis. Resignás cosas para conseguir esa invisibilidad.
El costo más grande es TCP. VLESS corre sobre TCP (vía TLS), lo que significa que hereda el problema de head-of-line blocking de TCP. Si un solo paquete se pierde, cada paquete subsiguiente en ese stream TCP espera la retransmisión. WireGuard evita esto corriendo en UDP. En conexiones con pérdida, el tipo que conseguís en Wi-Fi abarrotado o redes móviles con cobertura irregular, la diferencia es medible. VLESS también es sólo TCP, punto. XHTTP (una opción de transporte más nueva en XRay-core) agrega multiplexing pero no cambia la restricción TCP subyacente. Para gaming o voz en tiempo real, donde la latencia importa más que la confiabilidad, el transporte UDP de WireGuard está mejor adaptado.
El camino de conexión es más complejo también. Una sesión VLESS Reality involucra un handshake TLS 1.3 (1-RTT o 0-RTT), la negociación del protocolo VLESS, y potencialmente un setup de adaptador TUN con enrutamiento tun2socks. Más partes móviles que el handshake de single-roundtrip de WireGuard. Del lado del servidor, Reality mantiene una conexión TLS al destino de camuflaje y gestiona la lógica de proxy para conexiones no autenticadas. Eso cuesta más memoria y CPU por cliente que el procesamiento de paquetes en kernel-space de WireGuard. A escala, la diferencia se suma para operadores de servidores.
Después está la auditabilidad. Las 4,000 líneas de código de WireGuard han sido formalmente verificadas y ampliamente auditadas. XRay-core es un codebase Go grande con significativamente más superficie. El protocolo VLESS core es simple, pero la implementación circundante (Reality, fingerprinting uTLS, múltiples modos de transporte) no ha recibido el mismo nivel de revisión de seguridad independiente.
Estos son costos reales. Son aceptables cuando la alternativa es tener tu conexión bloqueada. No son costos que deberías pagar cuando no tenés que hacerlo.
Frente a frente: los números de rendimiento de Fexyn
Testeamos ambos protocolos en el mismo hardware, mismo servidor, mismas condiciones de red. Windows 11, fibra de 500 Mbps, conectándose a nuestro servidor de Frankfurt. Estos números vienen de benchmarks automatizados, no corridas cherry-picked.
| Métrica | WireGuard | VLESS Reality |
|---|---|---|
| Tiempo de conexión en frío | ~611 ms | ~627 ms |
| Tiempo de reconexión en caliente | N/A | ~42 ms |
| Tiempo de desconexión | ~108 ms | ~100 ms |
| Throughput (baseline 500 Mbps) | ~480 Mbps (96%) | Más bajo (overhead TCP) |
| Transporte | UDP | TCP (TLS 1.3) |
| Rondas de handshake | 1 round trip | 1-RTT TLS + header VLESS |
| Detectable por DPI | Sí, trivialmente | No, con Reality |
| Overhead de protocolo por paquete | ~32 bytes (tag Poly1305 + contador) | 25-50 bytes (VLESS) + record TLS |
Los tiempos de conexión están más cerca de lo que la mayoría de la gente espera. La diferencia de 16 milisegundos entre 611 ms y 627 ms para una conexión en frío no es algo que un usuario percibiría. La mayor parte de ese tiempo en ambos casos es setup de adaptador, configuración de ruta, y verificación, no latencia a nivel protocolo.
VLESS tiene una ventaja interesante en reconexiones en caliente. Como XRay-core puede mantenerse corriendo como proceso persistente entre conexiones, una reconexión (cambiando servidores o recuperándose de un cambio de red) sólo requiere re-establecer la sesión TLS. Eso toma cerca de 42 milisegundos en nuestro testeo. Las reconexiones de WireGuard también son rápidas, pero el ciclo completo de teardown y recreación de adaptador en nuestra implementación de Windows no tiene la misma optimización warm-path.
Donde WireGuard claramente tira para adelante es en throughput. El transporte UDP con procesamiento de paquetes a nivel kernel (o userspace de alto rendimiento) le da a WireGuard una ventaja medible, especialmente en conexiones de alto ancho de banda. El gap se ensancha en redes con pérdida donde el comportamiento de retransmisión de TCP agrega spikes de latencia.
Cuándo usar cuál
Esto es más simple de lo que el resto del artículo podría sugerir.
Usá WireGuard si estás en una red donde el tráfico VPN no está bloqueado o throttleado. Internet hogareño en la mayoría de los países occidentales, redes de oficina que permiten uso de VPN, redes móviles en países sin censura activa. WireGuard te da el mejor throughput, la latencia más baja, y el modelo de conexión más simple. Es el default correcto.
Usá VLESS Reality si estás en una red que bloquea o degrada protocolos VPN. Redes universitarias que bloquean WireGuard. Firewalls corporativos que sólo permiten HTTPS en puerto 443. Wi-Fi público con restricciones basadas en DPI. Y obviamente, en cualquier lugar de Rusia, China, Irán, u otros países con censura activa de internet. VLESS Reality es el único protocolo de producción que hemos testeado que confiablemente pasa por todos estos.
Usá rotación automática si viajás entre ambos entornos o si no estás seguro qué permite tu red. Este es el modo default de Fexyn: probá WireGuard primero por velocidad, caé a VLESS Reality si WireGuard falla, después caé a OpenVPN como último recurso. El cambio pasa automáticamente sin dropear tu protección de kill switch.
Por qué Fexyn envía ambos
La mayoría de los proveedores VPN envían un protocolo y tal vez ofrecen OpenVPN como fallback legacy. NordLynx de NordVPN es WireGuard con una capa NAT (ver Fexyn vs NordVPN para el desglose completo). Lightway de ExpressVPN es un protocolo personalizado que aún es detectable por DPI. Ninguno de los proveedores VPN occidentales mayores envía VLESS Reality porque viene del ecosistema XRay/V2Ray, que es primariamente en idioma chino y requiere familiaridad profunda con un codebase que no tiene especificación formal.
Pensamos que una VPN debería funcionar en todos lados. En tu Wi-Fi de casa donde nada te está bloqueando, sí. También en la red de hotel en Moscú que está corriendo TSPU. En el campus universitario que sólo permite HTTPS. En el Wi-Fi de la cafetería que bloquea UDP enteramente.
Eso requiere múltiples protocolos con propiedades distintas. WireGuard para velocidad cuando nada está en el camino. VLESS Reality para invisibilidad cuando algo lo está. OpenVPN para las raras redes donde ninguno funciona pero el tráfico VPN legacy basado en TLS aún se permite.
El motor de rotación de protocolo de Fexyn los prueba en orden basado en tu setting de modo de conexión. "Velocidad primero" empieza con WireGuard. "Stealth primero" empieza con VLESS Reality. De cualquier modo, terminás conectado. La selección de protocolo es automática, el kill switch se mantiene activo durante la rotación, y el usuario no necesita entender ninguna de las diferencias descritas en este artículo.
Sólo necesitan que su internet funcione. Aun cuando alguien está tratando de asegurarse de que no.
Podés probar ambos protocolos hoy con una suscripción Fexyn.