Shadowsocks y Xray: cuando bloquean la VPN

Trabajo a menudo con VPN. No como tema teórico, sino de forma muy práctica: conectar sedes, dar acceso a clientes a la red corporativa, mantener servidores accesibles, configurar firewalls, renovar certificados, estabilizar túneles IPsec, depurar clientes SSL VPN y entender por qué una ubicación deja de pasar de repente.

Normalmente eso es trabajo de red sólido y aburrido. Así debería ser.

Pero hay casos en los que una VPN técnicamente correcta ya no basta. Con clientes de países con internet muy regulado, por ejemplo China o Rusia, se ven una y otra vez situaciones en las que protocolos VPN clásicos se bloquean, se degradan o se detectan de forma dirigida. Como trabajo en Dubái con una base de clientes muy internacional, no es un tema abstracto. La pregunta operativa no es qué clima político hay detrás, sino cómo mantener acceso legítimo a la propia infraestructura cuando la conexión se filtra en el camino.

Ahí aparecen términos como Shadowsocks, ShadowsocksR, V2Ray, Xray-core, VLESS, Trojan, REALITY o XHTTP. Al principio parece una mezcla confusa de proyectos, forks y abreviaturas. Y, sinceramente, en parte lo es.

Por qué surgió Shadowsocks

Shadowsocks no viene del mundo clásico de las VPN empresariales. No nació porque alguien quisiera una solución site-to-site más bonita ni porque IPsec fuera demasiado complicado. Su origen fue mucho más directo: en 2012, un desarrollador con el seudónimo clowwindy quería una forma ligera de salir de una red fuertemente filtrada hacia internet abierto.

Eso explica mucho de su diseño. Shadowsocks debía ser ligero, rápido y práctico: no un cliente VPN pesado, no un gran gateway, no una suite de acceso remoto con identidad, cumplimiento e informes. La idea era un proxy SOCKS5 local que cifra el tráfico y lo envía a un servidor fuera del bloqueo.

La necesidad no era “más funciones de seguridad empresarial”, sino “necesito una salida funcional desde una red que filtra ciertos protocolos y destinos”. Por eso Shadowsocks sigue siendo interesante y también fácil de malinterpretar. Es muy útil como bloque de transporte fino, pero no es automáticamente una VPN corporativa completa.

En 2015 la historia se volvió más política: clowwindy escribió en GitHub que la policía lo había visitado y que tenía que dejar de trabajar en el proyecto. Después, el desarrollo continuó mediante forks y otras implementaciones. Muchas herramientas de este tipo nacen de un dolor técnico concreto y acaban dentro de una carrera más amplia entre usuarios, desarrolladores e infraestructuras de filtrado.

Por qué una VPN llama la atención

Cuando se habla de VPN, muchos piensan primero en cifrado. Eso es correcto, pero solo es una parte.

Un censor, proveedor o gran firewall nacional no siempre necesita leer el contenido de una conexión cifrada para interferir con ella. A menudo basta con reconocer el envoltorio. IPsec, SSL VPN, WireGuard u OpenVPN tienen rasgos típicos: puertos, tamaños de paquetes, patrones de handshake, comportamiento de certificados, temporización, uso de UDP, reintentos, errores o direcciones IP de servidor conocidas.

La analogía útil no es la carta, sino el sobre. La carta está cifrada, pero el sobre tiene cierto tamaño, color y sello, y siempre viene del mismo remitente. Quien clasifica sobres no necesita leer el texto para decir: este tipo de sobre ya lo conozco, va a control especial.

Con el tráfico de red ocurre algo parecido. Deep Packet Inspection y Traffic Classification no miran solo puertos; analizan patrones. En TLS pueden destacar fingerprints del Client Hello, SNI, cadenas de certificados o ALPN. En protocolos completamente cifrados, incluso la apariencia aleatoria de los primeros paquetes puede ser una señal. Investigaciones sobre la Great Firewall mostraron que importan las longitudes de paquetes, la entropía y caracteres ASCII imprimibles en paquetes tempranos.

Ese es el punto incómodo: que “todo parezca aleatorio” no lo hace automáticamente discreto. A veces eso mismo resulta sospechoso.

Qué muestra la investigación

Desde mi experiencia, lo importante no es simplemente que los sistemas de censura “detecten VPN”. Eso ya se sabía de forma general. Lo interesante es lo poco espectacular que pueden ser técnicamente muchos comienzos de detección.

Un buen punto de entrada es un trabajo de medición de GFW Report presentado en 2020 en la ACM Internet Measurement Conference. GFW Report no es un producto ni un fabricante, sino un proyecto de investigación y medición sobre la Great Firewall. IMC es simplemente la conferencia donde se publicó el trabajo.

El punto clave: no se trataba de un ataque mágico de descifrado. La Great Firewall combinaba observación pasiva y pruebas activas. Primero, ciertas conexiones parecían sospechosas por longitud y entropía del primer paquete de datos. Luego venían probes activos: el censor se conecta al servidor sospechoso, reproduce paquetes antiguos o modificados y observa si la otra parte responde como un servidor Shadowsocks.

Para administradores esto muestra dos capas distintas de defensa:

• El tráfico no debe destacar demasiado en observación pasiva.
• El servidor no debe comportarse como un proxy ante pruebas activas.

En 2023 el panorama se volvió aún más incómodo. Otro estudio de GFW mostró que el tráfico completamente cifrado puede bloquearse con heurísticas simples. Si el primer payload TCP no parece TLS, HTTP ni texto imprimible, sino un bloque aleatorio, eso ya puede ser una señal. Por eso “lo más aleatorio posible” no siempre es el mejor objetivo de camuflaje.

En 2024, la investigación sobre handshakes TLS encapsulados añadió otro punto: aunque el túnel exterior esté cifrado y bien disfrazado, un handshake TLS interior puede aparecer como patrón dentro de una pila de protocolos anidada. Esto afecta a setups donde HTTPS normal pasa por otro túnel proxy cifrado. El padding aleatorio ayuda poco; el multiplexing de streams parece más prometedor, pero tampoco resuelve todo si al final solo se ve un flujo de aplicación.

También hay investigaciones recientes sobre timing y RTTs cross-layer. La parte incómoda es estructural: un proxy desplaza sesiones de transporte y aplicación entre sí. Esas diferencias temporales pueden medirse aunque el cliente esté cerca o lejos del proxy. No se arregla simplemente con otro header.

La consecuencia es sobria: no decide la etiqueta del protocolo, sino el comportamiento completo del setup.

Shadowsocks no es una VPN clásica

Shadowsocks se mete a menudo en el mismo saco que VPN. En el uso diario se entiende, pero técnicamente no es exacto.

Shadowsocks es un proxy cifrado, inspirado de forma laxa en SOCKS5. Localmente corre un cliente que ofrece un proxy a las aplicaciones. Ese cliente cifra el tráfico y lo envía a un servidor Shadowsocks remoto. El servidor descifra la petición, conecta con el destino real y devuelve la respuesta por el camino cifrado.

Es más ligero que una VPN completa. Shadowsocks no mete automáticamente todo el sistema operativo en un túnel. Es una herramienta para enviar tráfico seleccionado por otro camino. Con ciertos clientes, sistemas y componentes adicionales se puede construir algo muy parecido a una VPN, pero la idea base sigue siendo proxy, no site-to-site VPN.

Para administradores esto corrige expectativas:

• Shadowsocks no sustituye un IPsec site-to-site bien diseñado.
• Shadowsocks no protege mágicamente contra toda detección.
• Shadowsocks sí es útil cuando se necesita un proxy cifrado, rápido y simple desde una red restrictiva.

Técnicamente, Shadowsocks ha evolucionado. Las configuraciones antiguas con stream ciphers ya no deberían ser la referencia. Los despliegues modernos pertenecen al mundo AEAD, y Shadowsocks 2022 va más allá: usa una base simétrica precompartida, derivación basada en BLAKE3, protección contra replay y correcciones frente a ediciones anteriores. La limitación importante: según la especificación, Shadowsocks 2022 no ofrece Forward Secrecy. Si una clave se compromete, rotarla correctamente no es opcional.

Con shadowsocks-rust existe una implementación moderna que también puede ejecutarse con Docker. En el servidor corre, por ejemplo, ssserver; en el cliente, sslocal. Entre ambos no basta cualquier contraseña: hacen falta secretos bien generados, un puerto alcanzable, cifrados actuales y una decisión clara sobre TCP, UDP o ambos.

Por qué Xray-core es otra categoría

Xray-core no es simplemente “Shadowsocks, pero más nuevo”. Es más bien un framework para escenarios de proxy y túneles.

Xray puede combinar protocolos inbound y outbound como VLESS, VMess, Trojan, Shadowsocks, WireGuard, Hysteria, SOCKS y HTTP. Encima se colocan transports como RAW, WebSocket, gRPC, XHTTP o Hysteria, combinados con TLS, REALITY o XTLS Vision. VMess aparece todavía en muchos setups antiguos, pero para despliegues nuevos es más bien legacy; en Xray actual suele estar VLESS en el centro.

Shadowsocks es el destornillador rápido. Xray es la caja de herramientas. Permite setups simples, pero también diseños donde un cliente SOCKS o TUN local acepta tráfico, lo envía con VLESS y REALITY a un servidor y allí sale a internet por un outbound freedom.

VLESS debe entenderse bien: no es el camuflaje en sí, sino un protocolo proxy ligero con autenticación basada en UUID. La confidencialidad y el camuflaje real vienen de la capa de transporte y seguridad inferior, por ejemplo TLS, REALITY o XTLS Vision.

REALITY es más interesante porque no hace simplemente “otro TLS”. Hacia fuera, el servidor toma prestado el handshake TLS de una web HTTPS real y ajena. Para un observador no parece un certificado proxy casero, sino un certificado real de una web real. Solo un cliente autorizado reconoce, mediante el material de claves configurado, que habla con su propio servidor Xray.

Esto apunta sobre todo a la capa de fingerprint TLS del servidor y a los active probes. uTLS ayuda en el lado del cliente imitando Client Hellos de navegadores. Aun así, Xray no es una capa de invisibilidad: timing, tamaños de paquetes, ALPN, comportamiento del servidor y patrones TLS anidados pueden seguir dando señales. XTLS Vision y XHTTP son piezas interesantes, pero no una garantía completa. Un poco de padding ayuda poco si el patrón básico del tráfico anidado sigue visible.

Además, enfoques basados en UDP como Hysteria o QUIC pueden rendir muy bien, pero en redes restrictivas se degradan, bloquean o tratan peor que TCP/443 saliente. Por eso Xray exige más disciplina operativa que Shadowsocks: fijar versiones, probar cambios, leer release notes y no copiar cada recomendación nueva de un foro.

La confusión de forks y nombres

Al investigar, se llega rápido a posts antiguos, forks de GitHub y clientes medio mantenidos. Es una consecuencia de la historia de estas herramientas.

Shadowsocks es a la vez protocolo y ecosistema con varias implementaciones. shadowsocks-rust es hoy una elección lógica para un servidor moderno. Implementaciones antiguas como shadowsocks-libev siguen siendo conocidas, pero según el estado del proyecto se consideran más legacy o centradas en bugfixes.

ShadowsocksR fue un fork con ideas adicionales de obfuscation y protocolo. SSR aparece en muchas guías antiguas. Hoy tendría cuidado con él. No porque toda instalación antigua sea mala, sino porque hay que comprobar muy bien cliente, servidor, criptografía, actualizaciones y comunidad.

Xray-core viene del entorno V2Ray, pero se ha desarrollado por separado. Por eso es peligroso aplicar tutoriales antiguos de V2Ray a Xray sin revisar. Algunos conceptos se parecen, pero configuración, funciones y recomendaciones han cambiado.

V2Fly, el proyecto comunitario actual alrededor de V2Ray, sigue siendo relevante y más conservador. Xray-core avanza con más agresividad en funciones como REALITY, XTLS Vision o XHTTP. También existe sing-box como plataforma universal moderna que reúne muchos de estos protocolos. Aquí me centro en Xray, pero en un lab también miraría sing-box, porque muchos clientes y setups móviles terminan ahí.

Mi consejo práctico:

• Para setups nuevos simples: probar Shadowsocks con una implementación actual.
• Para redes más difíciles: probar Xray-core con un diseño limpio y actual.
• Para guías antiguas de SSR o V2Ray: revisar primero estado del proyecto y seguridad.
• Para escenarios productivos de clientes: no copiar un setup de un blog sin entenderlo.

Qué se necesita en ambos lados

Un setup mínimo siempre tiene dos lados.

En el lado remoto se necesita un servidor fuera de la red restrictiva: un VPS pequeño, un servidor propio en un centro de datos o infraestructura controlada en una región alcanzable desde la sede del cliente. Debe estar endurecido, parcheado, monitorizado y documentado. Levantar una instancia barata y olvidarla crea riesgo a largo plazo.

En el lado cliente se necesita un programa adecuado. Con Shadowsocks suele ser un cliente SOCKS local o una app que configura el proxy del sistema. Con Xray puede ser un cliente basado en Xray, modo TUN, un router o una app que importe perfiles.

Entre ambos hacen falta:

• un propósito claramente definido
• autenticación limpia
• versiones actuales
• resolución DNS controlada
• logging sin datos innecesarios de clientes
• monitorización de alcance
• un plan para rotar servidores, puertos y secretos
• una revisión legal y contractual de si el uso está permitido

El último punto no es decorativo. En algunos países, usar estas herramientas puede ser problemático legalmente. En empresa también hay que distinguir si se da acceso a sistemas propios, se opera una red de cliente o se proporciona internet general a empleados.

DNS se subestima mucho. Si el navegador o sistema sigue resolviendo dominios por el proveedor local, el túnel solo ayuda a medias. El contenido quizá pase por el proxy, pero la consulta DNS revela el destino. En setups SOCKS, HTTP proxy y TUN hay que comprobar por separado que DNS vaya por el camino correcto, que IPv6 esté tratado y qué ocurre al caer el túnel.

El logging también es delicado. Para troubleshooting se quiere saber si el túnel vive; para privacidad se quiere guardar lo mínimo. Un buen setup registra estados técnicos, latencia, errores y volúmenes, no listas completas de conexiones con dominios destino. Logs de debug, TLS keylogs o access logs sin enmascarar no deben quedar permanentemente en producción.

El monitoring tampoco puede limitarse a “el contenedor corre”. Importa si un camino real de prueba funciona por el túnel, si DNS se enruta correctamente, si regiones destino se bloquean de repente y si un nodo visto desde el país afectado se comporta distinto que desde mi oficina.

Cómo lo clasificaría operativamente

Para mí, Shadowsocks o Xray no sustituyen arquitectura de firewall, Zero Trust, MFA ni segmentación limpia. Son herramientas de transporte para casos especiales.

Un enfoque empresarial razonable sería:

1. Probar primero si SSL VPN, IPsec o WireGuard funcionan de forma estable.
2. Si se bloquean, medir bien: DNS, puerto, protocolo, IP del servidor, fingerprint TLS, throttling UDP.
3. Probar entonces un transporte alternativo como Shadowsocks o Xray-core.
4. Usar el túnel solo para destinos necesarios, no abrir toda la red del cliente.
5. Filtrar en servidor qué servicios internos son accesibles.
6. Monitorizar para no enterarse por el cliente de que el camino volvió a bloquearse.
7. Tener plan de fallback: segundo exit, otro proveedor, otra región, otro protocolo.
8. Separar secretos y perfiles por sede o usuario.
9. Diseñar logs y métricas para operar sin crear rastros innecesarios.

En sedes es tentador considerar “ya vuelve a funcionar” como éxito. Lo entiendo. Pero después hay que ordenar. Si no, un workaround temporal se convierte en una ruta productiva invisible que nadie documentó.

Por qué los bloqueos se adaptan

Con estas herramientas nunca hay que olvidar que la otra parte adapta continuamente la detección.

Si muchas personas usan el mismo Docker Compose, el mismo puerto, el mismo fingerprint TLS, la misma estrategia de dominios y el mismo proveedor VPS, el patrón acaba siendo visible. Entonces no se bloquea “Xray” o “Shadowsocks” en abstracto, sino un patrón concreto: handshakes, tamaños de paquetes, rangos IP, clientes típicos, fallbacks mal configurados o respuestas de error llamativas.

Por eso el camuflaje no es solo una función del tool. El camuflaje es operación: mismas herramientas, otros dominios, otros proveedores, otros perfiles y otros patrones de tráfico pueden verse muy distintos en la práctica.

También por eso soy prudente con ciertas afirmaciones de proyectos o comunidades. Si una herramienta dice que no es detectable, es una afirmación del proyecto. Si un paper muestra que un rasgo se detectó en una red real, eso tiene otro peso. En la práctica hacen falta ambas cosas: innovación de los proyectos y sobriedad de la investigación.

Mi valoración

Shadowsocks tiene sentido cuando se necesita un proxy cifrado fino, rápido y relativamente simple. Es bueno para primeras pruebas, accesos temporales y entornos sin detección extremadamente agresiva.

Xray-core tiene sentido cuando la red es más difícil, cuando se necesitan varias variantes de transporte o cuando se quiere trabajar conscientemente con VLESS, REALITY, WebSocket, gRPC o XHTTP. Pero hay que entender más. Xray perdona menos porque su flexibilidad permite más errores.

En entornos de clientes no vendería ninguno como “reemplazo de VPN”. Lo describiría como un camino de transporte alternativo para accesos legítimos. Suena menos espectacular, pero es más honesto.

La diferencia más importante no es Shadowsocks contra Xray. Es si entiendo qué problema estoy resolviendo. Si es acceso remoto normal, uso VPN normal. Si el problema es detección estatal o de proveedor, hay que hablar de reconocibilidad, fingerprints y estrategia operativa. Y si no puedo explicarlo bien, no debería operarlo para clientes.

Conclusión

Shadowsocks y Xray-core son herramientas de un mundo en el que las conexiones de red no solo “funcionan” o “no funcionan”. A veces se clasifican, se degradan, se prueban activamente o se bloquean. Quien atiende clientes internacionales se encuentra tarde o temprano con esta realidad.

El tema me parece interesante porque vuelve la red muy concreta: cifrado, patrones, fingerprints, routing, DNS, operación, ley, responsabilidad y la idea de que un túnel funcional no es automáticamente un buen diseño.

Mi próximo paso está claro: quiero reproducir Shadowsocks y Xray-core en un pequeño lab. No para saltarme censura a ciegas, sino para entender mejor por qué las VPN clásicas a veces llaman la atención y qué alternativas pueden operarse de forma técnicamente seria.

Hasta la próxima,
Joe

FAQ