Tres formas en que Rusia rompe tu servidor Xray, y solo una es un bloqueo

Cada pocas semanas llega el mismo ticket. El VPS de un cliente funcionaba desde Rusia, un día dejó de hacerlo, y ahora la dirección parece muerta desde Moscú mientras responde perfectamente desde cualquier otro sitio. La conclusión se escribe sola: el DPI ha identificado VLESS, el servidor ha entrado en una lista, la IP está quemada.

A veces es exactamente eso. Más a menudo es una de otras dos cosas que desde la silla del cliente se ven idénticas y se arreglan de forma completamente distinta.

Y eso importa, porque el consejo habitual —«cambia el transporte a gRPC»— acierta a medias de una manera que lo hace difícil de rebatir. Ayuda de verdad, por un motivo que conviene entender con precisión. Solo que no ayuda contra el fallo que realmente te cuesta la dirección, y mucha gente recurre a él en lugar de a lo que sí serviría.

Esto es lo que ocurre en realidad, ordenado por el daño que hace.

1. El escaneo: tu servidor responde a una sonda, y la respuesta lo delata

Este es el que sí te cuesta la IP entera.

En mayo de 2026, alguien lanzó un escáner de VPN de estilo ruso contra su propio servidor y publicó el informe. Es el documento más útil sobre este asunto, porque muestra el razonamiento y no solo el veredicto. 7

El escáner no se limita al 443. Recorre todo el rango de puertos, del 1 al 65535, con 500 hilos, y lanza varias sondas distintas contra todo lo que responda: un GET HTTP, un CONNECT, un TLS ClientHello con un SNI deliberadamente inválido y datos binarios en crudo. Después compara las respuestas.

Un servidor web real reacciona de forma distinta ante basura distinta. Un proxy con un fallback estático, no. En el servidor analizado, el puerto 2096 devolvió los mismos 41 bytes, byte a byte, a cada sonda, empezando por la línea de estado HTTP/0.0 307 Temporary Redirect. Ningún nginx, Apache o Caddy real emite una versión HTTP/0.0. Esa única respuesta es casi una confesión.

El informe acumula además varias pistas más suaves:

• Sin cabecera Server:. La pone cualquier servidor web habitual. Su ausencia dice «manejador propio», no «sitio web».
• Un certificado con seis días de validez total. Las autoridades públicas emiten para 30 a 90 días. Cualquier cosa por debajo de unas dos semanas dice «hecho a mano», es decir «banco de pruebas», es decir «proxy».

El escáner puntuó al servidor con 48 sobre 100 y emitió el veredicto OBVIOUSLY-VPN. La consecuencia, en palabras del propio informe, es que las anomalías acumuladas cruzan el umbral del TSPU y «la IP se añade a la lista de reputación y los flujos futuros se descartan o se ralentizan hasta que cambie la firma».

Ese es el mecanismo al que se refiere la gente cuando dice que le han bloqueado la IP. Es real, actúa a nivel de dirección, y lo dispara lo que tu servidor responde cuando le hablan, no el protocolo que estás tunelando.

2. La ráfaga: tres handshakes en cincuenta milisegundos

El segundo mecanismo es de comportamiento y no tiene nada que ver con el sondeo.

Un hilo abierto en Xray-core describe cómo el TSPU lee el TLS ClientHello y lo puntúa según la subred y el sistema autónomo del servidor, el SNI y la huella del navegador. Las huellas de Chrome, Safari e iOS desde un rango sospechoso se retienen; Firefox, Android, OkHttp y Edge pasan. 3

Lo que lo dispara es la intensidad. Tres o más conexiones TLS simultáneas al mismo host en unos 20 a 50 milisegundos las congela todas durante unos 120 segundos. Si el cliente responde rotando su huella en plena congelación, eso pasa a 600 segundos.

Por eso un navegador abriendo una página a través del túnel es mucho peor que una sola descarga. Los navegadores modernos abren seis conexiones a la vez por diseño. Es exactamente la forma que busca el detector.

3. El contador: tu kilobyte número quince

El tercero es más tosco y, a su manera, elegante. El censor observa una conexión TLS hacia un servidor extranjero y la congela en cuanto los datos devueltos pasan de unos 15 a 20 KB, cifra que después se concretó en unos 25 paquetes en cada sentido.

El hilo que lo documenta, abierto el 27 de junio de 2025, es explícito en que esto no es una detección de protocolo: «Da igual si es tráfico HTTPS ‚legítimo' o si alguien lo está imitando». 2

Este es el clásico «funciona unos segundos y se muere». Un handshake y un par de peticiones pequeñas caben en el presupuesto. Una página con imágenes, no.

Cómo distinguirlos con una sola prueba

Los tres se parecen porque el censor congela las conexiones en lugar de resetearlas. Ni RST ni ICMP: el handshake sencillamente no llega a completarse y el cliente se queda ahí hasta que expira, lo que resulta indistinguible de una ruta que va a ninguna parte.

Desde la red afectada, descarga algo pequeño y simple por HTTP desde la misma dirección.

• El HTTP plano funciona y el TLS no: mecanismo 2 o 3. La dirección está bien. En un informe de noviembre de 2025 sobre el bloqueo de REALITY en un operador ruso, quien lo reportó comprobó justo esto y vio que el sitio alojado en la misma IP seguía cargando. 4
• No responde absolutamente nada: mecanismo 1. Estás en la lista de reputación y lo único que ayuda es una dirección nueva.

La distinción vale esos dos minutos, porque cambiar de servidor por el mecanismo 2 o 3 te compra unos quince kilobytes de alivio antes de que la nueva dirección se comporte igual. Eso se interpreta como que la nueva IP se ha quemado al instante. No se ha quemado nada. Simplemente se ha vuelto a gastar el presupuesto.

Dónde ayuda gRPC de verdad y dónde no

Los operadores repiten que gRPC aguanta semanas en conexiones donde el TCP plano se detectaba en días. No es folclore, ni suerte. Es el mecanismo 2, y la razón es mecánica.

gRPC funciona sobre HTTP/2, y la documentación de Xray es explícita sobre lo que eso aporta: «gRPC (HTTP/2) tiene multiplexación integrada. No se recomienda activar mux.cool cuando se usa gRPC y HTTP/2». 5

Multiplexar significa que muchos flujos comparten una sola conexión TCP y, por tanto, un solo handshake TLS. El detector de ráfagas busca tres o más handshakes al mismo host en cincuenta milisegundos. Un navegador sobre TCP plano abre seis conexiones y produce exactamente esa forma. El mismo navegador sobre gRPC produce un handshake con seis flujos HTTP/2 dentro. Ya no queda ráfaga que detectar.

Así que si te pasaste a gRPC y el problema desapareció, es por esto, y no dejes que nadie te convenza de volver atrás.

Lo que no hace es responder a una sonda. La misma página advierte de que «los servicios gRPC están expuestos al sondeo activo» y recomienda poner delante un proxy inverso que separe el tráfico por prefijo de ruta. Un gRPC desnudo escuchando en el 443 le sigue respondiendo al escáner, y el que manda la dirección a la lista de reputación es el mecanismo 1. La multiplexación no hace nada contra eso.

Conviene saber también hacia dónde va esto. El transporte gRPC está marcado como obsoleto: la documentación dice ahora «se recomienda pasar a XHTTP». 5 Es una nota de migración, no un motivo para arrancar algo que funciona. XHTTP, presentado en diciembre de 2024, multiplexa igual mediante XMUX y añade lo que a gRPC le falta: relleno de cabeceras y separación entre flujo ascendente y descendente, de modo que el descendente viaja en peticiones GET independientes, lo que además esquiva los límites de gRPC que imponen algunos CDN. Frente a WebSocket, evita el llamativo ALPN http/1.1. 6

Planifica el cambio. No lo precipites.

Acumúlalos; no son alternativas

El error que hay debajo de casi todas estas discusiones es tratarlo como una única elección: REALITY o gRPC, este transporte o aquel. Los tres mecanismos son independientes, así que las defensas también lo son, y se combinan:

Un servidor con REALITY detrás de nginx sobre un transporte multiplexado responde a los tres. Un servidor que usa solo uno de ellos responde a uno.

Pon un nginx real delante y apunta los fallbacks hacia él. Es el cambio de mayor valor, y es la primera recomendación del propio informe: monta un nginx auténtico con un mapa de páginas de error en condiciones y dirige hacia él los fallbacks de Xray, para que todo lo que no sea un handshake válido reciba HTTP real de software de servidor web real. 7 Eso elimina la línea de estado HTTP/0.0, devuelve la cabecera Server: y hace que las respuestas varíen según la petición, como en cualquier web. Sirve en él un sitio de verdad. La página de bienvenida por defecto de nginx es mejor que un 307 estático, y un sitio real es mejor que ambos.

Usa un certificado real. Let's Encrypt con renovación automática. Un certificado autofirmado de seis días es una pista por sí solo, y quitarlo no cuesta nada.

Cuida el SNI. Tomarlo prestado de Microsoft, Apple o Google llama la atención; de los hosts nacionales con mucho tráfico se dice que son bastante más estables como objetivo del que tomar prestado. El bloqueo es selectivo y no por comodín, y un subdominio recién creado en una dirección limpia suele pasar. 8

Cuida la huella, pero no solo la huella. Se ha informado de que cambiar uTLS de Chrome a Firefox restablece la conexión en operadores donde Chrome queda retenido. 8 Pero la puntuación también pesa la subred y el sistema autónomo, así que una huella perfecta en un rango mal puntuado sigue siendo una conexión mala.

Usa un transporte multiplexado, y déjalo multiplexar. gRPC o XHTTP, con mux.cool desactivado: la documentación dice claramente que no se recomienda activarlo sobre HTTP/2. Si ejecutas gRPC detrás de nginx, eso es grpc_pass con un prefijo de ruta, y con un solo despliegue consigues la defensa frente a la sonda y frente a la ráfaga.

No dejes que nada más en la máquina hable. El escáner recorre los 65535 puertos. Cada servicio que responde es otra oportunidad de sumar una anomalía. Mueve SSH del 22 a un puerto alto y ciérralo con cortafuegos a direcciones conocidas.

Ten una segunda ubicación. No una dirección de repuesto en el mismo rango para rotar, sino un sitio realmente distinto. Cuando el fallo es regional, lo que ayuda es otro camino, no otro número en el mismo camino.

Y cuenta con que esto va a seguir moviéndose

Roskomnadzor bloqueó VLESS a finales de 2025 usando el TSPU, y la mayoría de los desarrolladores respondió publicando configuraciones nuevas en cuestión de días. 1 Ese es el ritmo al que ha quedado esto, y el presupuesto detrás va creciendo: se prevé multiplicar por dos y medio la capacidad del TSPU para 2030, hasta 954 terabits por segundo, por unos 186 millones de dólares, suficiente, según los cálculos del propio ministerio, para analizar todo el tráfico de Runet y aún sobrar margen.

Nada de lo anterior es permanente. Dos cosas sí se generalizan.

No te pillan por lo que tunelas. Te pillan por parecer una máquina que existe para tunelar: por lo que responde, por cómo se conecta y por cuánto envía. Todo lo que haga que el servidor parezca un servidor web corriente que además transporta otro tráfico te compra tiempo.

Y ningún ajuste aislado es la respuesta. La detección está por capas, así que la defensa también tiene que estarlo. Si alguien te dice que un transporte resuelve esto, pregúntale cuál de los tres resuelve.

Fuentes

1. Russia's internet censorship in 2026: VPN crackdowns, mobile shutdowns, Telegram blocks and the state messenger Max, Zona Media, 7 de abril de 2026
2. [Russia] Censor has a new method of blocking, net4people/bbs, abierto el 27 de junio de 2025
3. Russia blocks 2026, XTLS/Xray-core, 2026
4. TCP + Reality gets blocked, XTLS/Xray-core, 23 de noviembre de 2025
5. gRPC transport, documentación de Project X
6. XHTTP, XTLS/Xray-core, diciembre de 2024
7. How Bye Bye VPN Works in Russia, MHSanaei/3x-ui, 6 de mayo de 2026
8. Bypassing Russian GFW, XTLS/Xray-core