Transport XHTTP pour Xray : guide complet de configuration et différences avec HTTP

Introduction

Le transport XHTTP pour Xray est devenu, entre 2024 et 2026, l’une des méthodes les plus efficaces pour camoufler le trafic sous un HTTP classique et ainsi passer sans encombre les DPI modernes. La raison est simple : de nombreux réseaux continuent d’autoriser le HTTP(S) traditionnel pour le trafic légal, et XHTTP reproduit ces échanges sans utiliser le framing lourd d’HTTP/2 ou WebSocket. Dans ce guide, nous expliquerons ce qu’est XHTTP dans le contexte de Xray, son fonctionnement interne, ses différences avec le transport HTTP standard, nous proposerons des schémas résistants aux DPI, des check-lists, des conseils sur la performance et la surveillance, ainsi que les erreurs typiques qui brisent la connexion en conditions réelles. Au final, vous disposerez d’une méthodologie complète pour concevoir, déployer et maintenir XHTTP selon vos scénarios, du simple accès domestique aux réseaux d’entreprise ou mobiles.

Les bases

Qu’est-ce que Xray et un transport

Xray-core est un moteur proxy performant offrant un modèle flexible combinant protocole + transport + chiffrement. Les protocoles applicatifs (VLESS, VMess, Trojan, etc.) gèrent l’authentification et le multiplexage des sessions, tandis que le transport (TCP, WebSocket, HTTP/2, gRPC, QUIC, XHTTP) détermine comment les octets circulent sur le réseau et quels signes sont visibles par les DPI ou intermédiaires. Le chiffrement (TLS/XTLS/REALITY) et l’émulation client (uTLS, empreintes JA3) protègent le contenu et masquent le profil TLS pour ressembler à un vrai navigateur.

Où se place XHTTP dans cette matrice

XHTTP est un mode de transport qui mime le dialogue classique HTTP/1.1 avec la possibilité d’utiliser TLS ou TCP brut (les équivalents h2c ne sont pas nécessaires). Son but est de fournir un profil aussi « normal » que possible face aux DPI : en-têtes, méthodes, chemins, keep-alive, encodage chunked, schémas d’Upgrade — puis après cet échange légitime, il bascule le flux en canal binaire bidirectionnel pour le trafic proxy réel. Vu de l’extérieur, c’est une requête/réponse HTTP prolongée avec une connexion vivante, et de l’intérieur, un pipeline pour votre VLESS/VMess.

Pourquoi ça résiste au DPI

• Sémantique HTTP/1.1. La plupart des DPI « comprennent » et laissent passer les en-têtes HTTP typiques, méthodes (GET/POST/OPTIONS), encodages (chunked), connexions keep-alive.
• Framing minimal. Contrairement à HTTP/2 ou WebSocket, XHTTP n’introduit pas de trames/opcodes explicites, il maintient le flux comme s’il s’agissait du corps d’un POST ou d’une mise à niveau. Pour nombre d’inspecteurs, c’est un comportement « normal ».
• Imitation flexible. Les en-têtes (User-Agent, Accept, Referer), chemins, hôtes, codes de réponse et même les intervalles de transmission peuvent être reproduits fidèlement pour correspondre à des backends réels.

Comparaison avec le transport HTTP classique dans Xray

Xray intègre un transport HTTP (souvent HTTP/2 ou mode h2c) conçu autour du framing et multiplexage des flux au sein d’HTTP/2. C’est pratique, mais cela laisse des empreintes visibles (ALPN h2, profils HPACK et préambules particuliers) et demande une négociation plus complexe. XHTTP évite ces signaux évidents d’HTTP/2, il est souvent préférable dans les réseaux restreints acceptant seulement du HTTP/1.1 simple sur TLS 1.3, là où les segments HTTP/2/H3 sont suspectés ou bloqués.

Immersion profonde

Architecture du flux XHTTP

1. Établissement TCP/TLS. Le client ouvre une connexion TCP (ou TLS). En TLS, uTLS se lance pour imiter un navigateur réel (JA3, SNI, ALPN — habituellement http/1.1, parfois h2 pour plus de réalisme).
2. Requête HTTP. Le client envoie une requête HTTP/1.1 crédible : méthode (souvent POST ou GET), chemin (ex. /api, /health, /v1/upload), en-têtes (Host, User-Agent, Accept, Accept-Language, Content-Type, Connection: keep-alive, TE: trailers, Cache-Control, X-Requested-With, etc.). Deux motifs possibles : « corps POST long » ou « échange type Upgrade ».
3. Réponse serveur. Le serveur renvoie 200/204/101 selon le motif, des en-têtes serveur corrects (Server: nginx, Date, Content-Type, Transfer-Encoding: chunked, Connection: keep-alive), puis garde la connexion ouverte.
4. Tunnel. Ensuite, les deux côtés échangent les octets utiles du protocole Xray, cachés dans le corps et segments chunked. Pour le DPI, c’est une connexion HTTP vivante avec un corps ou des chunks persistants.

Différences clés entre XHTTP vs HTTP/2 et WebSocket

• Pas de framing explicite au niveau navigateur. H2/H3 sont repérables : ALPN h2/h3, priorités, HPACK/QPACK. WS montre des en-têtes Upgrade: websocket, Sec-WebSocket-Key/Accept. XHTTP utilise des en-têtes « classiques ».
• Moins de signatures. Les DPI sont souvent entraînés à détecter WebSocket et profils HPACK atypiques. XHTTP s’insère dans la pile HTTP/1.1 ancienne et connue.
• Leurre flexible. Il peut faire croire à un téléchargeur, un téléverseur, un SSE long ou un endpoint API à réponse lente.
• Robustesse dans les réseaux bruités. Le traitement simple de HTTP/1.1 et chunked fonctionne souvent bien derrière des proxies d’entreprise et NAT.

Performance et overhead

• Surcharge des en-têtes : faible mais prévisible. Sur de longues sessions, l’impact est minime.
• RTT : un RTT additionnel pour la requête/réponse HTTP en plus du TLS, réduit grâce au keep-alive et données anticipées si supportées.
• Débit : comparable à TCP+TLS « nu » ; le goulet d’étranglement est souvent la proxy/balance ou la mise en tampon.

Compatibilité et ALPN

En pratique, ALPN « http/1.1 » offre le profil le plus neutre. Si le réseau préfère h2, on peut ajouter « h2 » à la liste, mais il faut une réponse serveur adaptée, sinon la négociation échouera. Pour plus de crédibilité, activez l’émulation uTLS des versions récentes de Chrome/Firefox.

Partie pratique 1 : schéma minimal VLESS+XHTTP sur TLS

Objectif

Déployer Xray avec le protocole VLESS et transport XHTTP sur le port 443/tcp avec un certificat valide. À l’extérieur, un site classique sur le même domaine ou un placeholder statique ; le trafic proxy transite via un chemin XHTTP.

Étapes

1. Domaine et DNS. Configurez les records A/AAAA vers votre VPS. Vérifiez que votre IP n’est pas dans des listes noires évidentes.
2. Certificat. Installez certbot ou Caddy pour TLS automatique. Limitez les ALPN inutiles si h2 n’est pas utilisé.
3. Xray. Mettez à jour à la version 2026. Assurez-vous que la build supporte le transport XHTTP.
4. Configuration serveur. Créez un inbound VLESS avec streamSettings: network: xhttp, security: tls. Définissez des en-têtes et chemin crédibles.
5. Configuration client. Utilisez aussi network: xhttp, serverName et chemin/hôte identiques au serveur. Activez uTLS.
6. Firewall. Ouvrez 443/tcp, bloquez les ports superflus. Activez les optimisations conntrack.
7. Vérification. Testez avec curl -v https://votre_domaine/chemin — vous devez obtenir un 200/204 honnête. Puis testez la connexion client Xray et analysez les logs.

Exemple de paramètres (version abrégée)

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

Client : server: votre_domaine; port: 443; protocol: vless; uuid: même_UUID; tls: enabled; utls: chrome; alpn: ["http/1.1"]; xhttpSettings: mêmes host/path/method/headers.

Check-list de robustesse

• ALPN contient uniquement « http/1.1 » si le réseau suspecte h2/h3.
• En-têtes et méthode ressemblent à un appel API légitime.
• Le chemin existe sur le site et retourne 200/204 sans redirections.
• Le serveur répond correctement à Date, Server et Connection.
• Keep-Alive est actif, idle_timeout pas trop court.

Partie pratique 2 : XHTTP derrière un reverse proxy (Nginx/Caddy)

Quand l’utiliser

Lorsque le domaine héberge déjà un site ou une application, il est pratique de cacher XHTTP derrière un reverse proxy avec routage par chemin/hôte. Cela renforce le réalisme et décharge TLS/HTTP sur un serveur web connu.

Schéma

1. Le serveur web (443/TLS) reçoit tout le trafic entrant.
2. Le trafic habituel est servi par l’application ou du contenu statique.
3. Les requêtes vers /api (ou chemin secret) sont proxyfiées vers 127.0.0.1:port Xray.
4. Xray écoute un port local (ex. 127.0.0.1:18085) sans TLS propre, network: xhttp en clair, car TLS externe est géré par Nginx/Caddy.

Mise en pratique

• Sur Nginx, désactivez proxy_request_buffering pour le chemin XHTTP, sinon la mise en tampon casse l’interactivité.
• Configurez les en-têtes adaptés à votre site pour que la réponse paraisse naturelle : Server, Content-Type, Cache-Control.
• Surveillez proxy_read_timeout et keepalive_requests — ils doivent autoriser des connexions longues.

Check-list

• Le site retourne bien 200/204 sur le chemin XHTTP avec curl.
• Pas d’erreurs 301/302/401/403 sur ce chemin.
• Tailles des en-têtes et corps respectent les limites du serveur web.

Partie pratique 3 : XHTTP et CDN/edge

Risques liés au CDN

Certains CDN tamponnent ou réécrivent agressivement les en-têtes ; les POST longue durée sont parfois restreints. Pour masquer derrière un CDN, testez le comportement de bout en bout : prise en charge du chunked, absence de coupure forcée pour inactivité, maintien de Connection: keep-alive.

Recommandations

• Utilisez un chemin « court » et une méthode POST réaliste avec un Content-Length faible au départ puis passage en chunked.
• Adaptez les timeouts de lecture/écriture sur edge et origin.
• Limitez les en-têtes non standard ; évitez les noms exotiques.
• Vérifiez que le CDN n’ajoute pas d’en-têtes modifiant la signature.

Partie pratique 4 : résistance au DPI et camouflage

uTLS et empreintes TLS

Activez la simulation d’un navigateur récent (Chrome, Firefox). Cela inclut les suites de chiffrement plausibles, l’ordre des extensions, les clés ALPN et GREASE. Restez à jour car les empreintes changent trimestriellement.

Profil HTTP

• Méthode : POST crédible pour upload/long-poll. GET est possible avec Transfer-Encoding: chunked mais plus rare.
• En-têtes : User-Agent comme le navigateur réel de votre OS. Accept, Accept-Language, Accept-Encoding en phase avec le UA. Évitez les paires contradictoires.
• Réponses : 200/204 avec Date, Content-Type, Server corrects. En mode Upgrade, 101 Switching Protocols avec champs réalistes.
• Intervalles : le jitter d’envoi imite le comportement applicatif. Ne faites pas des paquets strictement réguliers toutes les N millisecondes.

Ports et routage

• 443/tcp est le choix naturel. 8443, 444, 7443 sont possibles mais moins crédibles.
• IPv6 est souvent moins encombré. Si le réseau le supporte, utilisez le dual-stack.
• Séparez les domaines : contenu principal à l’apex, XHTTP sur sous-domaine avec une légende visuelle commune.

Alternatives et techniques complémentaires

• REALITY : masque le TLS en simulant un site réel sans certificat pour le domaine cible. Bon second circuit de secours.
• gRPC : ressemble à un API d’entreprise, mais ses signatures sont plus visibles.
• WebSocket : compatible avec de nombreux load balancers, mais présente un schéma d’Upgrade évident.

Partie pratique 5 : observabilité, tests, métriques

Vérification de la connexion

• curl -v https://domaine/chemin — assurez-vous du code et des en-têtes attendus.
• tcpdump/wireshark : analysez ALPN, SNI, taille et intervalles des paquets.
• Logs Xray : connexions réussies, absence de fermetures prématurées et timeouts.

Tests de charge

• Variez RTT et pertes (tc netem) et suivez la récupération du flux.
• Mesurez latences P95/P99 pour des requêtes courtes via le tunnel.
• Comparez le débit XHTTP avec WS/H2 sur votre infrastructure.

Signaux de dégradation

• Incompréhensibles 301/302 sur le chemin XHTTP.
• Fermeture des connexions CDN/proxy inverses à l’inactivité avant vos timeouts.
• Augmentation des TCP RST depuis les middleboxes.

Partie pratique 6 : dépannage pas à pas de la connexion

1. Certificat : vérifiez la chaîne et les dates.
2. ALPN : fixez « http/1.1 ». Si h2 est nécessaire, assurez-vous que le serveur le gère pour la ligne XHTTP.
3. Routage : traceroute depuis le client vers l’IP. En cas d’asymétries ou de pertes, changez de route/fournisseur.
4. Reverse proxy : désactivez la mise en tampon, vérifiez les timeout.
5. Placeholder du site : le chemin retourne une réponse honnête avec bons en-têtes.
6. uTLS : changez le profil navigateur, contrôlez JA3.
7. Éliminez le CDN : testez en direct sur origin, puis réintroduisez le CDN.

Partie pratique 7 : performance et réglages

• MTU/MSS : sur le VPS, fixez des paramètres optimaux pour éviter la fragmentation en mobile. Le clamp TCP MSS à 1360–1400 octets sur tunnel TLS aide souvent.
• Taille des buffers : sur Nginx/Caddy, désactivez la mise en tampon superflue pour le chemin XHTTP. Dans Xray, augmentez les buffers recv/send pour RTT élevés.
• Timeouts d’inactivité : 60–120 secondes pour réseaux peu bruyants, plus de 300 pour connexions stables.
• Réalisme des en-têtes : imitez l’ordre et le set des entêtes des sites de votre légende technique.

Erreurs typiques

• Host/path non alignés entre client et serveur — handshake OK mais pas de données.
• Conflit ALPN : client demande h2, serveur ne supporte pas — RST et ERR_HTTP2_INADEQUATE.
• Mise en tampon du reverse proxy : les connexions long-poll rupturées à cause de proxy_request_buffering activé.
• En-têtes suspects : discordance Accept-Encoding vs User-Agent.
• Réponse vide 404/405 sur chemin XHTTP — DPI identifie une anomalie.
• En-têtes X-* excessifs : inutile, augmente l’entropie du profil.

Outils et ressources

Ce qu’il faut utiliser en 2026

• Xray-core à jour avec support XHTTP et uTLS.
• Reverse proxy : Nginx, Caddy. Caddy facilite TLS automatique et HTTP/1.1 natif.
• Analyse du profil réseau : ja3/s_jA3 pour TLS, h2spec/h2c en test, tcpdump/wireshark pour pcap.
• Tests de charge : vegeta, wrk pour simuler fond HTTP, iperf3 via tunnel pour débit.
• Monitoring : métriques Xray (si activées), métriques système (conntrack, sockets), logs reverse proxy.

Alternative infrastructurelle

vpn.how propose des serveurs VPN personnels avec une adresse IP dédiée. Les emplacements, protocoles et tarifs disponibles figurent sur le site et dans votre compte. Les moyens de paiement et le montant final sont affichés lors du paiement. Choisir un serveur

Cas pratiques et résultats

Cas 1 : réseau de campus avec DPI agressif

Conditions : seul HTTPS sur 443 autorisé, HTTP/2 souvent instable, WebSocket coupé par moments. Solution : VLESS+XHTTP sur 443 avec ALPN=http/1.1, chemin /api/metrics, POST+chunked, reverse proxy Caddy. Résultat : réussite de connexion à 98–99 % (contre 70–80 % sur WS), latence médiane +8–12 ms par rapport au baseline TLS, débit 70–85 % du TCP pur via iperf3 — acceptable pour applications.

Cas 2 : périmètre entreprise avec proxy

Conditions : proxies transparents réécrivent en-têtes et tamponnent les corps. Solution : XHTTP derrière Nginx avec proxy_request_buffering off, keepalive_requests=1000, en-têtes serveur corrects. Résultat : disparitions des coupures de sessions longues, maintien des connexions plus de 2 heures sans fermeture forcée.

Cas 3 : opérateur mobile avec restrictions sur QUIC et h2

Conditions : h3 bloqué, h2 dégradé, 443/tcp propre. Solution : XHTTP avec profil uTLS Chrome, port 443, UA et Accept-Language réalistes, clamp MSS à 1380. Résultat : débits stables 10–30 Mbit/s, absence de RST en pointe, accès réussi à services auparavant bloqués par DPI.

FAQ

1. Pourquoi XHTTP est-il mieux que WebSocket dans Xray ?

WS se trahit par les en-têtes Upgrade: websocket et Sec-WebSocket-*. Les DPI connaissent souvent ces signatures. XHTTP utilise un dialogue HTTP/1.1 classique sans champs spécifiques à WS, ce qui réduit le risque de classification. En plus, la surcharge est inférieure ou comparable.

2. Quelles différences entre XHTTP et le transport HTTP standard (HTTP/2) dans Xray ?

HTTP/2 multiplexe au niveau des trames et a un profil marqué (ALPN h2, priorités, HPACK). XHTTP imite HTTP/1.1 simple où le flux utile passe comme corps/chunks, sans framing h2 évident. C’est plus discret et souvent plus résistant.

3. Peut-on utiliser XHTTP sans TLS ?

Techniquement oui (clearnet), surtout derrière un reverse proxy en localhost. Sur Internet, c’est déconseillé : TLS cache le contenu et réduit le risque de classification. Sans TLS, DPI voit toute la requête/réponse.

4. XHTTP est-il compatible avec les CDN ?

Ça dépend du CDN et de sa configuration. Il faut un bon support du chunked, pas de mise en tampon agressive, ni de coupure pour inactivité. Testez toujours en bout en bout à chaque Point of Presence.

5. Quel protocole choisir sur XHTTP — VLESS, VMess ou Trojan ?

VLESS est réputé « propre » et flexible pour les scénarios modernes, VMess a une large diffusion historique, Trojan est simple. Pour le DPI, l’essentiel est le profil externe (TLS/uTLS+XHTTP) et le comportement HTTP, moins la sémantique interne.

6. Que dire de ECH/REALITY avec XHTTP ?

ECH chiffre le ClientHello et masque le SNI, mais son support reste fragmentaire. REALITY est une autre méthode de camouflage, efficace comme circuit de secours. XHTTP coexiste bien avec eux, mais souvent uTLS+TLS1.3+XHTTP suffit.

7. Pourquoi ai-je parfois des 301/302 sur le chemin XHTTP ?

Les redirections automatiques du site ou de l’app (ex. vers https ou autre hôte) impactent le chemin XHTTP. Créez une location dédiée sans redirection ni logique auth/CSRF.

8. Comment configurer les timeouts ?

Reverse proxy : proxy_read_timeout de 90 à 600 s selon usage. Dans Xray, idle_timeout entre 60 et 300 s. Assurez-vous que le niveau supérieur (CDN/proxy) ne coupe pas avant Xray.

9. Comment tester le réalisme des en-têtes ?

Capturez le trafic réel du navigateur vers votre site, collectez les en-têtes fréquents et leur ordre. Comparez avec ceux envoyés par le client XHTTP, éliminez l’exotisme, ajustez User-Agent/Accept/Language crédibles.

10. Peut-on multiplexeur plusieurs flux logiques dans XHTTP ?

Oui, via le protocole supérieur (par ex. VLESS/VMess avec Mux). Mais attention aux latences : avec un RTT élevé, trop de sous-flux dans un seul canal HTTP dégrade la latence finale.

Conclusion

Le transport XHTTP pour Xray est un outil pratique parlant le langage familier du HTTP/1.1 pour les réseaux, minimisant ainsi les signatures visibles par DPI. Sa force réside dans la simplicité : en-têtes crédibles, sémantique keep-alive correcte, absence d’indicateurs clairs de WebSocket ou HTTP/2. Associé à TLS 1.3 et uTLS, il assure une connexion stable là où WS/H2/H3 suscitent la défiance, et le reverse proxy facilite l’intégration naturelle du tunnel dans un site fonctionnel. Commencez par un schéma minimal VLESS+XHTTP sur 443 avec uTLS, puis ajoutez un reverse proxy sans mise en tampon, ajustez les timeouts et vérifiez le CDN — vous obtiendrez un canal fiable. Pensez à la surveillance, à des en-têtes réalistes, et à actualiser régulièrement les profils uTLS. En cas de besoin de secours ou IP personnelle, considérez les alternatives infrastructurelles. Ensuite, automatisez les déploiements, conservez plusieurs domaines pour changer de légendes, et réévaluez trimestriellement les paramètres de camouflage face aux nouvelles formes de DPI. Ainsi, XHTTP deviendra pour vous un atout durable et maîtrisé dans votre architecture réseau.