Transporte XHTTP para Xray: guía completa de configuración y diferencias con HTTP

Introducción

El transporte XHTTP para Xray se ha convertido rápidamente entre 2024 y 2026 en una de las formas más prácticas de disfrazar el tráfico como HTTP común y superar de forma fiable los DPI modernos. La razón es sencilla: muchas redes siguen permitiendo HTTP(S) clásico para tráfico legítimo, y XHTTP imita su diálogo sin el pesado framing de HTTP/2 o WebSocket. En esta guía explicaremos qué es XHTTP en el contexto de Xray, cómo funciona internamente, en qué se diferencia del transporte HTTP estándar, proporcionaremos esquemas resistentes a DPI, listas de chequeo, consejos de rendimiento y monitoreo, además de los errores comunes que rompen la conexión en redes reales. Al final, obtendrás una metodología sistemática para diseñar, desplegar y mantener XHTTP según tus escenarios: desde acceso doméstico hasta perímetros corporativos y redes móviles.

Fundamentos

Qué es Xray y transporte

Xray-core es un motor proxy de alto rendimiento que ofrece un modelo flexible de protocolo + transporte + cifrado. Los protocolos a nivel de aplicación (VLESS, VMess, Trojan, etc.) definen autenticación y multiplexación de sesiones, mientras que el transporte (TCP, WebSocket, HTTP/2, gRPC, QUIC, XHTTP) especifica cómo viajan los bytes por la red y qué señales de red detecta el DPI y nodos intermedios. El cifrado (TLS/XTLS/REALITY) e imitación de cliente (uTLS, huellas JA3) esconden el contenido y disfrazan el perfil TLS imitando el comportamiento de navegadores reales.

Dónde encaja XHTTP en esta matriz

XHTTP es un modo de transporte que simula el comportamiento clásico del diálogo HTTP/1.1, pudiendo usar tanto TLS como TCP puro (sin necesidad de análogos h2c). Su objetivo es ofrecer un perfil lo más “común” posible para DPI: encabezados, métodos, rutas, keep-alive, transferencia por fragmentos, patrones Upgrade, y tras un saludo legítimo transformar el flujo en un canal bidireccional de bytes para el tráfico proxy real. Desde fuera parece una petición/respuesta HTTP prolongada con conexión viva, y por dentro funciona como un conducto para tu VLESS/VMess.

Por qué funciona contra DPI

• Semántica HTTP/1.1. La mayoría de DPI “entienden” y permiten los encabezados, métodos (GET/POST/OPTIONS), codificaciones (chunked) y conexiones keep-alive típicas de HTTP.
• Framing mínimo. A diferencia de HTTP/2 y WebSocket, XHTTP no utiliza frames/opcodes explícitos y mantiene el flujo como si fuera cuerpo de POST o actualización de conexión. Para muchos inspectores, este es un patrón “normal”.
• Imitación flexible. Se pueden simular encabezados (User-Agent, Accept, Referer), rutas, hosts, códigos de respuesta e incluso intervalos de transferencia para imitar backend reales.

Comparación: transporte HTTP común en Xray

Xray incluye un transporte HTTP (a menudo HTTP/2 o modos similares a h2c), enfocado en framing y multiplexación interna de flujos en HTTP/2. Esto es conveniente pero deja huellas claras (fingerprints) como ALPN h2, perfiles HPACK específicos y prólogos, además de requerir un acuerdo más complejo. XHTTP evita señales evidentes de HTTP/2, siendo a menudo preferible en redes “restringidas” que sólo permiten HTTP/1.1 simple sobre TLS 1.3, y donde los segmentos HTTP/2/H3 son sospechosos o bloqueados.

Profundización

Arquitectura del flujo XHTTP

1. TCP/TLS handshake. El cliente establece conexión TCP (o TLS). Si es TLS, activa uTLS para imitar un navegador real (JA3, SNI, ALPN — normalmente http/1.1 más opcionalmente h2 para más realismo).
2. Petición HTTP. Envía una petición HTTP/1.1 creíble: método (suele ser POST o GET), ruta (ej. /api, /health, /v1/upload), encabezados (Host, User-Agent, Accept, Accept-Language, Content-Type, Connection: keep-alive, TE: trailers, Cache-Control, X-Requested-With, etc.). Hay dos patrones: “POST con cuerpo largo” o intercambio tipo “Upgrade”.
3. Respuesta del servidor. Responde con 200/204/101 (según patrón), encabezados correctos (Server: nginx, Date, Content-Type, Transfer-Encoding: chunked, Connection: keep-alive), y mantiene la conexión abierta.
4. Túnel. A partir de aquí ambas partes intercambian bytes útiles del protocolo Xray dentro del cuerpo/segmentos chunked. Para DPI, parece una conexión HTTP viva con cuerpo/fragmentos continuos.

Diferencias clave de XHTTP respecto a HTTP/2 y WebSocket

• Sin framing explícito a nivel navegador. H2/H3 se detectan por ALPN h2/h3, prioridades y HPACK/QPACK. WS revela Upgrade: websocket, Sec-WebSocket-Key/Accept. XHTTP usa encabezados “normales”.
• Menos firmas. DPI está entrenado para detectar WebSocket y perfiles HPACK atípicos. XHTTP encaja en el stack clásico HTTP/1.1 conocido.
• Objetivo falso flexible. Puede parecer un descargador, subidor, SSE largo o endpoint API con respuestas lentas.
• Fiabilidad en redes “ruidosas”. El manejo sencillo de HTTP/1.1 y chunked suele funcionar bien tras proxies corporativos y NAT.

Rendimiento y costes asociados

• Overhead de encabezados: pequeño y predecible. En sesiones largas, el impacto es casi nulo.
• RTT: añade una RTT extra por petición/respuesta HTTP sobre TLS. Se mitiga con keep-alive y datos tempranos (si está soportado).
• Ancho de banda: comparable a TCP+TLS plano; el cuello de botella suele ser el proxy/load balancer y buffering.

Compatibilidad y ALPN

En la práctica, ALPN “http/1.1” da el perfil más neutro. Si la red prefiere h2, se puede añadir “h2” a la lista, pero el servidor debe responder correctamente, o generará fallos innecesarios. Para un realismo superior, activa la imitación uTLS de Chrome o Firefox actual.

Sección práctica 1: esquema mínimo VLESS+XHTTP sobre TLS

Objetivo

Levantar Xray con protocolo VLESS y transporte XHTTP en el puerto 443/tcp con un certificado válido. Desde fuera, un sitio web común en el mismo dominio o un placeholder estático; el tráfico proxy pasa por la ruta XHTTP.

Pasos

1. Dominio y DNS. Configura A/AAAA al VPS. Asegúrate que tu IP no esté en listas negras evidentes.
2. Certificado. Instala certbot o Caddy para TLS automático. Minimiza ALPN extras si no utilizas h2.
3. Xray. Actualiza a la versión vigente para 2026. Confirma que el build soporte transporte XHTTP.
4. Configuración servidor. Crea inbound VLESS con streamSettings: network: xhttp, security: tls. Define encabezados creíbles y ruta.
5. Configuración cliente. Define network: xhttp, serverName y ruta/host igual que en servidor. Activa uTLS.
6. Firewall. Permite 443/tcp, bloquea puertos innecesarios. Activa optimizaciones conntrack.
7. Verificación. Usa curl -v https://tu_dominio/ruta — deberías recibir 200/204 honesto. Luego prueba conexión con cliente Xray y revisa métricas en logs.

Ejemplo abreviado de parámetros

Servidor: protocol: vless; clients: UUID; decryption: none; streamSettings: network: xhttp; security: tls; tlsSettings: serverName: tu_dominio; alpn: ["http/1.1"]; xhttpSettings: host: ["tu_dominio"], path: "/api", method: "POST", headers: {"User-Agent": ["Mozilla/5.0"], "Accept": ["*/*"], "Connection": ["keep-alive"]}, idle_timeout: 60-120s.

Cliente: server: tu_dominio; port: 443; protocol: vless; uuid: mismo UUID; tls: enabled; utls: chrome; alpn: ["http/1.1"]; xhttpSettings: mismos host/path/method/headers.

Lista de chequeo de resistencia

• ALPN solo contiene «http/1.1» si la red sospecha de h2/h3.
• Encabezados y método parecen una llamada API legítima.
• La ruta existe en el sitio y devuelve 200/204 sin redirecciones.
• El servidor responde correctamente Date, Server y Connection.
• Keep-Alive activo, idle_timeout no demasiado corto.

Sección práctica 2: XHTTP detrás de proxy inverso (Nginx/Caddy)

Cuándo usarlo

Si ya tienes un sitio o aplicación en el dominio, es conveniente esconder XHTTP detrás de un reverse proxy con enrutamiento por ruta/host. Esto aporta realismo y descarga la parte TLS/HTTP a un servidor web conocido.

Esquema

1. El servidor web (443/tls) recibe todo el tráfico entrante.
2. El tráfico normal se atiende con app/estática.
3. Las peticiones a /api (o ruta oculta) se proxifican a 127.0.0.1:puerto Xray.
4. Xray escucha en puerto local (e.g. 127.0.0.1:18085) sin TLS propio, network: xhttp en modo cleartext, porque TLS externo está en Nginx/Caddy.

Práctica

• En Nginx asegúrate que proxy_request_buffering está off para la ruta XHTTP, para preservar la interactividad.
• Configura encabezados típicos de tu sitio para que la respuesta del servidor se vea natural: Server, Content-Type, Cache-Control.
• Controla timeout proxy_read_timeout y keepalive_requests para permitir conexiones largas.

Lista de chequeo

• El sitio devuelve correctamente 200/204 en ruta XHTTP cuando usas curl.
• No hay errores 301/302/401/403 en la ruta XHTTP.
• Tamaño de encabezados y cuerpo no exceden límites del servidor web.

Sección práctica 3: XHTTP y CDN/edge

Riesgos con CDN

Algunos CDN hacen buffering agresivo o reescriben encabezados; POSTs de larga duración pueden limitarse. Si usas CDN para camuflar, prueba el comportamiento de extremo a extremo: soporte chunked, no cierre forzado por inactividad, mantén Connection: keep-alive.

Recomendaciones

• Usa rutas “cortas” y métodos POST realistas con Content-Length pequeño al inicio y luego chunked.
• Escala los timeouts de lectura/escritura en edge y origin.
• Limita encabezados personalizados; evita nombres exóticos.
• Verifica que CDN no inyecte encabezados que alteren la firma.

Sección práctica 4: Resistencia a DPI y camuflaje

uTLS y huellas TLS

Activa la imitación de navegador actualizado (Chrome, Firefox). Esto significa suites de cifrado credibles, orden correcto de extensiones, claves ALPN y GREASE. Mantente actualizado: cada trimestre cambian las huellas de navegación.

Perfil HTTP

• Método: POST es realista para subida/polling largo. GET es aceptable con Transfer-Encoding: chunked, pero menos frecuente.
• Encabezados: User-Agent realista para tu sistema operativo. Accept, Accept-Language y Accept-Encoding coherentes con UA. Evita pares contradictorios.
• Respuestas: 200/204 con Date, Content-Type, Server adecuados. Para patrón Upgrade, 101 Switching Protocols con campos creíbles.
• Intervalos: jitter en la entrega emula el comportamiento de apps reales. Evita lotes estrictamente equitativos cada N ms.

Puertos y enrutamiento

• 443/tcp es la opción natural. 8443, 444, 7443 son posibles pero menos creíbles.
• IPv6 suele estar menos saturado. Si la red soporta v6, usa dual-stack.
• Separa dominios: contenido principal en apex, XHTTP en subdominio con leyenda visual común.

Alternativas y técnicas complementarias

• REALITY: camufla TLS como sitio real sin certificado para dominio destino. Un buen fallback.
• gRPC: parecido a APIs corporativas, pero con firmas más visibles.
• WebSocket: compatible con muchos balanceadores, pero con Upgrade pattern claro.

Sección práctica 5: Monitoreo, pruebas y métricas

Verificación de conexión

• curl -v https://dominio/ruta — confirma código y encabezados esperados.
• tcpdump/wireshark: revisa ALPN, SNI, tamaño e intervalos de paquetes.
• Logs Xray: revisa saludos exitosos, ausencia de cierres prematuros y timeouts.

Pruebas de carga

• Varía RTT y pérdidas (tc netem) y monitorea recuperación de flujo.
• Mide latencias P95/P99 en peticiones cortas por túnel.
• Compara throughput XHTTP frente a WS/H2 en tu infraestructura.

Señales de degradación

• Redirecciones inexplicables 301/302 en ruta XHTTP.
• Cierres prematuros en CDN/Reverse proxy por inactividad antes de tus timeouts.
• Incremento de TCP RST desde middlebox.

Sección práctica 6: Depuración paso a paso de conexión

1. Certificado: revisa cadena y fechas.
2. ALPN: fija «http/1.1». Si necesitas h2, asegúrate que servidor lo soporte para línea XHTTP.
3. Ruta: desde cliente haz traceroute al IP. Cambia ruta/proveedor si hay asimetrías o “huecos negros”.
4. Proxy inverso: desactiva buffering, ajusta timeouts.
5. Placeholder web: la ruta responde honestamente con encabezados correctos.
6. uTLS: cambia perfil de navegador, comprueba JA3.
7. Evita CDN: prueba conexión directa a origin, luego vuelve a CDN.

Sección práctica 7: Rendimiento y ajustes

• MTU/MSS: configura valores óptimos en VPS para evitar fragmentación en redes móviles. A menudo ayuda TCP MSS clamping entre 1360–1400 bytes para túneles sobre TLS.
• Tamaño de buffers: en Nginx/Caddy desactiva buffering innecesario para ruta XHTTP. En Xray aumenta buffers recv/send para altos RTT.
• Timeouts de inactividad: 60–120 segundos en redes poco ruidosas, 300+ para canales estables.
• Realismo de encabezados: imita conjuntos y orden de encabezados típicos de sitios que forman tu leyenda.

Errores típicos

• Host/path no coordinados entre cliente y servidor — handshake ocurre pero no pasa tráfico.
• Conflicto ALPN: cliente pide h2, servidor no soporta — hay RST y ERR_HTTP2_INADEQUATE.
• Buffering en proxy inverso: conexiones long-poll se cortan por proxy_request_buffering activado.
• Encabezados sospechosos: incompatibilidad en Accept-Encoding y User-Agent.
• Respuesta vacía con 404/405 en ruta XHTTP — DPI empieza a clasificarlo como anomalía.
• Demasiados encabezados personalizados X-* — innecesarios y aumentan entropía del perfil.

Herramientas y recursos

Qué usar en 2026

• Xray-core actualizado con soporte XHTTP y uTLS.
• Proxy inverso: Nginx, Caddy. Caddy simplifica TLS automático y configuración HTTP/1.1 nativa.
• Análisis de perfiles de red: ja3/s_jA3 para TLS, pruebas h2spec/h2c si se necesita, tcpdump/wireshark para pcap.
• Pruebas de carga: vegeta, wrk para simular HTTP en segundo plano, iperf3 para throughput de túnel.
• Monitoreo: métricas Xray (si activadas), métricas del sistema (conntrack, sockets), logs de proxy inverso.

Alternativa infraestructural

vpn.how ofrece servidores VPN personales con una IP dedicada. Las ubicaciones, los protocolos y los precios disponibles se muestran en el sitio y en tu cuenta. Los métodos de pago y el importe final aparecen al pagar. Elegir un servidor

Casos y resultados

Caso 1: Red universitaria con DPI agresivo

Condiciones: solo HTTPS en 443, HTTP/2 inestable, WebSocket intermitente. Solución: VLESS+XHTTP en 443 con ALPN=http/1.1, ruta /api/metrics, POST+chunked, proxy inverso con Caddy. Resultado: éxito de conexión 98–99% (antes 70–80% con WS), latencia media +8–12 ms sobre baseline TLS, throughput 70–85% de TCP puro en iperf3 — aceptable para aplicaciones.

Caso 2: Perímetro corporativo con proxy

Condiciones: proxies transparentes reescriben encabezados y hacen buffering. Solución: XHTTP tras Nginx con proxy_request_buffering off, keepalive_requests=1000, encabezados servidor correctos. Resultado: desaparecen cortes en sesiones largas, conexiones mantenidas más de 2 horas sin cierre forzado por inactividad.

Caso 3: Operador móvil con bloqueos a QUIC y h2

Condiciones: h3 bloqueado, h2 degradado, 443/tcp limpio. Solución: XHTTP con perfil uTLS Chrome, puerto 443, UA y Accept-Language realistas, clamp MSS 1380. Resultado: 10–30 Mbps estables, ausencia de RST en picos de carga, acceso exitoso a servicios antes impedidos por DPI.

FAQ

1. ¿Por qué XHTTP es mejor que WebSocket en Xray?

WS se delata con encabezados Upgrade: websocket y campos Sec-WebSocket-*. DPI reconoce esas firmas frecuentemente. XHTTP usa diálogo HTTP/1.1 común sin campos específicos de WS, reduciendo el riesgo de ser clasificado. Además, el overhead es menor o similar.

2. ¿En qué se diferencia XHTTP del transporte HTTP estándar (HTTP/2) en Xray?

HTTP/2 multiplica flujos mediante frames y tiene un perfil claro (ALPN h2, prioridades, HPACK). XHTTP es una imitación simple de HTTP/1.1 donde el flujo útil viaja como un cuerpo POST/chunks, sin framing evidente h2. Esto lo hace menos visible y a menudo más resistente.

3. ¿Se puede usar XHTTP sin TLS?

Técnicamente sí (en claro), especialmente detrás de un proxy reverso en localhost. En Internet no se recomienda: TLS oculta contenido y reduce riesgo de identificación. Sin TLS, DPI ve toda la petición/respuesta.

4. ¿XHTTP es compatible con CDN?

Depende del CDN y su configuración. Se requiere soporte correcto de chunked, no buffering agresivo ni cierres anticipados. Prueba end-to-end en puntos de presencia objetivo.

5. ¿Qué protocolo elegir sobre XHTTP: VLESS, VMess o Trojan?

VLESS es limpio y flexible para escenarios modernos, VMess es histórico y popular, Trojan es simple. Para DPI, más importante es el perfil externo (TLS/uTLS+XHTTP) y comportamiento HTTP que la semántica interna.

6. ¿Qué pasa con ECH/REALITY y XHTTP?

ECH cifra ClientHello y oculta SNI, pero su soporte en servidores/clientes es parcial. REALITY es otra técnica de camuflaje que funciona bien como fallback. XHTTP convive con ellos, aunque suele ser suficiente uTLS+TLS1.3+XHTTP.

7. ¿Por qué a veces veo redirecciones 301/302 en la ruta XHTTP?

Redirecciones automáticas del sitio o app (ej. a https o a otro host) afectan la ruta XHTTP. Crea una location separada sin redirecciones y sin lógica auth/CSRF.

8. ¿Cómo configurar timeouts?

En proxy inverso, proxy_read_timeout de 90 a 600 s según perfil. En Xray, idle_timeout entre 60 y 300 s. Asegúrate que niveles superiores (CDN/proxy) no cierren antes que Xray.

9. ¿Cómo probar realismo de encabezados?

Captura tráfico real del navegador hacia tu sitio, analiza encabezados frecuentes y su orden. Contrástalo con lo que envía cliente XHTTP, elimina “excentricidades” y ajusta User-Agent/Accept/Idioma para que sean creíbles.

10. ¿Se pueden multiplexar varios flujos lógicos en XHTTP?

Sí, lo hace el protocolo de nivel superior (ej. VLESS/VMess vía Mux). Pero mide bien la latencia: con RTT alto, muchos subflujos en un solo canal HTTP empeoran la latencia final.

Conclusión

El transporte XHTTP para Xray es una herramienta práctica que “habla” el lenguaje conocido y habitual de HTTP/1.1 en la red, minimizando las firmas visibles para DPI. Su fortaleza está en la simplicidad: encabezados creíbles, semántica keep-alive correcta y ausencia de señales claras de WebSocket o HTTP/2. Combinado con TLS 1.3 y uTLS, ofrece conexión estable donde WS/H2/H3 ya levantan sospechas, y el reverse proxy facilita integrar el túnel de forma orgánica en un sitio web real. Comienza con un esquema mínimo VLESS+XHTTP en 443 con uTLS, añade reverse proxy sin buffering, ajusta timeouts y prueba CDN — lograrás un canal confiable. Ten en cuenta el monitoreo, encabezados realistas y actualizaciones periódicas de perfiles uTLS. Si necesitas respaldo o IP personal, considera alternativas infraestructurales. Luego, automatiza despliegues, mantén un par de dominios para rotar leyendas y revisa trimestralmente los parámetros para ajustarlos a nuevos patrones DPI. Así, XHTTP será para ti no un truco puntual, sino una parte gestionada de tu arquitectura de red.