Trasporto XHTTP per Xray: guida completa alla configurazione e differenze rispetto a HTTP

Introduzione

Il trasporto XHTTP per Xray è rapidamente diventato, tra il 2024 e il 2026, uno dei metodi più efficaci per mimetizzare il traffico come semplice HTTP e superare con successo i moderni DPI. Il motivo è semplice: molte reti continuano a consentire il classico HTTP(S) per traffico legittimo, mentre XHTTP simula questi dialoghi senza l'overhead del framing pesante di HTTP/2 o WebSocket. In questa guida esploreremo cos'è XHTTP nel contesto di Xray, come funziona internamente, le differenze rispetto al trasporto HTTP standard, forniremo schemi di configurazione resistenti al DPI, checklist, suggerimenti per migliorare performance e osservabilità, oltre agli errori più comuni che possono causare disconnessioni nelle reti reali. In sintesi, avrete una metodologia completa per progettare, implementare e mantenere XHTTP nei vostri casi d'uso: dall'accesso domestico fino alla rete aziendale e mobile.

Basi

Cos’è Xray e cos’è un trasporto

Xray-core è un motore proxy ad alte prestazioni che offre un modello flessibile protocollo + trasporto + crittografia. I protocolli di livello applicativo (VLESS, VMess, Trojan, ecc.) definiscono autenticazione e multiplexing delle sessioni, mentre il trasporto (TCP, WebSocket, HTTP/2, gRPC, QUIC, XHTTP) determina come i byte viaggiano in rete e quali segnali di rete possono essere rilevati da DPI e nodi intermedi. La crittografia (TLS/XTLS/REALITY) e l’emulazione del client (uTLS, fingerprint JA3) proteggono i contenuti e camuffano il profilo TLS nei comportamenti di browser reali.

Dove si colloca XHTTP in questa matrice

XHTTP è una modalità di trasporto che simula il comportamento tipico del dialogo HTTP/1.1 classico, permettendo l’uso sia di TLS sia di TCP puro (non serve l’equivalente h2c). L’obiettivo è fornire un profilo il più possibile «ordinario» per i DPI: header, metodi, percorsi, keep-alive, chunked payload, pattern Upgrade — e dopo un handshake legittimo trasformare il flusso in un canale bidirezionale per il traffico proxy vero e proprio. Dall’esterno sembra una richiesta/risposta HTTP lunga con connessione attiva, mentre internamente è una pipeline per il vostro VLESS/VMess.

Perché funziona contro il DPI

• Semantica HTTP/1.1. La maggior parte dei DPI «capisce» e lascia passare header, metodi (GET/POST/OPTIONS), codifiche (chunked) e connessioni keep-alive tipiche di HTTP.
• Framing minimo. A differenza di HTTP/2 e WebSocket, XHTTP non usa frame o opcodes espliciti, mantenendo il flusso come se fosse un corpo POST o un upgrade di connessione. Per molti sistemi di ispezione questo è un pattern «normale».
• Camuffamento flessibile. Header (User-Agent, Accept, Referer), percorsi, host, codici di risposta e anche gli intervalli di trasmissione possono essere personalizzati per assomigliare a backend reali.

Con cosa confrontarlo: trasporto HTTP standard in Xray

Xray dispone di un trasporto HTTP (solitamente HTTP/2 o modalità simili a h2c) focalizzato sul framing e multiplexing dei flussi dentro HTTP/2. Utile, ma lascia tracce evidenti (impronte come ALPN h2, profili HPACK, preludi specifici) e richiede negoziazioni più complesse. XHTTP evita questi segnali forti di HTTP/2 ed è spesso preferibile in reti «strette» che consentono solo un «semplice» HTTP/1.1 su TLS 1.3, mentre HTTP/2/H3 viene sospettato o bloccato.

Approfondimento tecnico

Architettura del flusso XHTTP

1. TLS/connessione TCP. Il client stabilisce una connessione TCP (o TLS). Con TLS si attiva uTLS per mimetizzarsi da browser reale (JA3, SNI, ALPN — tipicamente http/1.1 con opzionale h2 per maggiore realismo).
2. Richiesta HTTP. Il client invia una richiesta HTTP/1.1 plausibile: metodo (spesso POST o GET), percorso (es. /api, /health, /v1/upload), header (Host, User-Agent, Accept, Accept-Language, Content-Type, Connection: keep-alive, TE: trailers, Cache-Control, X-Requested-With, ecc.). Sono possibili due modelli: “POST corposo” oppure “scambio simile a Upgrade”.
3. Risposta server. Il server risponde con 200/204/101 (a seconda del pattern), header server corretti (Server: nginx, Date, Content-Type, Transfer-Encoding: chunked, Connection: keep-alive), poi mantiene aperta la connessione.
4. Tunnel. Dopodiché entrambe le parti scambiano i byte utili del protocollo Xray, nascosti nel corpo o segmenti chunked. Per il DPI appare come connessione HTTP viva e persistente con body/chunk continui.

Differenze chiave tra XHTTP, HTTP/2 e WebSocket

• Nessun framing esplicito a livello browser. H2/H3 vengono riconosciuti tramite ALPN h2/h3, priorità, HPACK/QPACK. WS si identifica con Upgrade: websocket, Sec-WebSocket-Key/Accept. XHTTP usa header «ordinari».
• Meno firme distintive. Il DPI è spesso addestrato a riconoscere WebSocket o profili HPACK insoliti. XHTTP si incanala in uno stack HTTP/1.1 tradizionale e familiare.
• Falsa destinazione flessibile. Può sembrare un downloader, uploader, SSE a lungo termine o un endpoint API con risposte lente.
• Affidabilità in reti «rumorose». La semplice gestione di HTTP/1.1 e chunked funziona spesso senza problemi dietro proxy aziendali e NAT.

Performance e overhead

• Overhead header: contenuto e prevedibile. Su sessioni lunghe l’impatto è minimo.
• RTT: +1 RTT per la richiesta/risposta HTTP oltre TLS. Riducibile da keep-alive e dati anticipati (quando supportato).
• Throughput: comparabile a TCP+TLS. Collo di bottiglia tipico è il proxy/bilanciatore e buffering.

Compatibilità e ALPN

In pratica ALPN «http/1.1» fornisce il profilo più neutrale. Se la rete preferisce h2, potete aggiungere «h2» nella lista, ma il server deve rispondere correttamente, altrimenti si generano errori inutili. Per maggiore realismo, attivate uTLS con profili recenti di Chrome/Firefox.

Sezione pratica 1: Schema minimo VLESS+XHTTP su TLS

Obiettivo

Far girare Xray con protocollo VLESS e trasporto XHTTP sulla porta 443/tcp con certificato valido. Esternamente un sito normale sullo stesso dominio o un placeholder statico; il traffico proxy passa tramite percorso XHTTP.

Passaggi

1. Dominio e DNS. Impostate record A/AAAA sul VPS. Verificate che l’IP non sia in blacklist evidenti.
2. Certificato. Installate certbot o Caddy per TLS automatico. Riducete emissioni di ALPN non necessarie se non usate h2.
3. Xray. Aggiornate all’ultima versione 2026. Controllate che la build supporti il trasporto XHTTP.
4. Configurazione server. Create un inbound VLESS con streamSettings: network: xhttp, security: tls. Impostate header e percorso credibili.
5. Configurazione client. Specificate network: xhttp, serverName e percorso/host uguali al server. Abilitate uTLS.
6. Firewall. Consentite 443/tcp, limitate porte non necessarie. Attivate ottimizzazioni conntrack.
7. Verifica. Usate curl -v https://vostro_dominio/percorso — dovete ottenere un onesto 200/204. Poi testate la connessione con client Xray e controllate le metriche nei log.

Esempio parametri (semplificato)

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

Client: server: vostro_dominio; port: 443; protocol: vless; uuid: stesso; tls: enabled; utls: chrome; alpn: ["http/1.1"]; xhttpSettings: stessi host/path/method/headers.

Checklist per robustezza

• ALPN contiene solo «http/1.1» se la rete sospetta h2/h3.
• Header e metodo appaiono come chiamata API legittima.
• Il percorso esiste e risponde 200/204 senza redirect.
• Il server risponde correttamente con Date, Server e Connection.
• Keep-Alive attivo, idle_timeout non troppo breve.

Sezione pratica 2: XHTTP dietro reverse proxy (Nginx/Caddy)

Quando serve

Se il dominio ospita già sito/applicazione, XHTTP si può nascondere dietro un reverse proxy con elaborazione per percorso/host. Ciò aumenta il realismo e scarica i dettagli TLS/HTTP sul webserver noto.

Schema

1. Il webserver (443/tls) riceve tutto il traffico in ingresso.
2. Il traffico ordinario è gestito dall’applicazione o da contenuti statici.
3. Le richieste verso /api (o percorso nascosto) sono proxy-ate su 127.0.0.1:porta Xray.
4. Xray ascolta una porta locale (es. 127.0.0.1:18085) senza TLS, network: xhttp in chiaro, poiché TLS esterno sta su Nginx/Caddy.

Consigli pratici

• In Nginx assicuratevi che proxy_request_buffering sia disattivato per il percorso XHTTP, altrimenti la bufferizzazione rovina l’interattività.
• Impostate header coerenti con il sito per risposte credibili: Server, Content-Type, Cache-Control.
• Controllate proxy_read_timeout e keepalive_requests — devono permettere connessioni lunghe.

Checklist

• Il sito restituisce correttamente 200/204 sul percorso XHTTP per curl.
• Esclusi errori 301/302/401/403 sul percorso XHTTP.
• Dimensioni di header e corpo non superano i limiti del webserver.

Sezione pratica 3: XHTTP e CDN/edge

Rischi dei CDN

Alcuni CDN fanno buffering aggressivo o riscrivono header; POST di lunga durata possono essere limitati. Se usate CDN per mascheramento, testate il comportamento end-to-end: supporto chunked, nessuna chiusura forzata per inattività, mantenimento di Connection: keep-alive.

Raccomandazioni

• Usate percorsi «corti» e modalità POST realistica con Content-Length iniziale basso e chunked successivo.
• Aumentate timeout di lettura/scrittura su edge e origin.
• Limitate header non standard; evitate nomi esotici.
• Verificate che il CDN non inserisca header propri che alterano le firme.

Sezione pratica 4: Resistenza al DPI e mimetizzazione

uTLS e fingerprint TLS

Attivate emulazioni di browser aggiornati (Chrome, Firefox). Ciò include cipher suite credibili, ordine di estensioni, chiavi ALPN e GREASE. Tenete d’occhio gli aggiornamenti, i fingerprint cambiano ogni trimestre circa.

Profilo HTTP

• Metodo: POST è realistico per upload o long-poll. GET con Transfer-Encoding: chunked è raro ma possibile.
• Header: User-Agent come da browser reale del sistema operativo. Accept, Accept-Language, Accept-Encoding corrispondenti. Evitate coppie contraddittorie.
• Risposte: 200/204 con Date, Content-Type e Server corretti. Per pattern Upgrade: 101 Switching Protocols con campi realistici.
• Intervalli: jitter nel timing dei dati imita il comportamento delle app. Evitate pacchetti rigidi a intervalli regolari costanti.

Porte e routing

• 443/tcp è la scelta naturale. 8443, 444, 7443 sono possibili ma meno credibili.
• IPv6 è spesso meno congestionato. Se la rete supporta IPv6, usate dual-stack.
• Separate i domini: contenuti principali sull’apex, XHTTP su sottodominio con tematizzazione visiva coerente.

Alternative e tecniche complementari

• REALITY: camuffa TLS come sito reale senza certificato per il dominio target. Buona alternativa di riserva.
• gRPC: simile ad API aziendali rumorose, ma con firme più evidenti.
• WebSocket: compatibile con molti bilanciatori, ma riconoscibile per pattern Upgrade.

Sezione pratica 5: Osservabilità, test e metriche

Controllo connessione

• curl -v https://dominio/percorso — verificate codice e header attesi.
• tcpdump/wireshark: controllate ALPN, SNI, dimensioni e intervalli pacchetti.
• Log Xray: handshake riusciti, assenza di early close e timeout.

Test di carico

• Variate RTT e perdita pacchetti (tc netem), osservate il recupero del flusso.
• Misurate latenza P95/P99 per richieste brevi tramite tunnel.
• Confrontate throughput XHTTP vs WS/H2 sulla vostra infrastruttura.

Segnali di degrado

• 301/302 inspiegabili sul percorso XHTTP.
• Connessioni chiuse da CDN/Reverse proxy per idle prima dei timeout.
• Aumento dei TCP RST da middlebox.

Sezione pratica 6: Debug passo a passo della connessione

1. Certificato: verificate catena e date di validità.
2. ALPN: fissate «http/1.1». Se serve h2, assicuratevi che il server lo supporti per la linea XHTTP.
3. Percorso: da client fate traceroute all’IP. Se asimmetrie o blackhole, cambiate percorso/provider.
4. Reverse proxy: disattivate buffering, controllate timeout.
5. Placeholder sito: percorso risponde correttamente con gli header richiesti.
6. uTLS: cambiate profilo browser, verificate fingerprint JA3.
7. Escludete CDN: testate direttamente vs origin, poi reinserite CDN.

Sezione pratica 7: Performance e tuning

• MTU/MSS: nel VPS configurate parametri ottimali per evitare frammentazione in reti mobili. Spesso utile il clamp TCP MSS a 1360–1400 byte per tunnel su TLS.
• Dimensione buffer: disattivate buffering eccessivo su Nginx/Caddy per percorso XHTTP. In Xray aumentate buffer recv/send per RTT elevati.
• Timeout idle: 60–120 secondi per reti poco rumorose, 300+ per canali stabili.
• Realismo header: imitate set di header e ordine come nei siti della vostra legenda di rete.

Errori tipici

• Host/path non corrispondenti tra client e server — handshake avviene ma no dati.
• Conflitti ALPN: client richiede h2, server non supporta — causano RST/ERR_HTTP2_INADEQUATE.
• Buffering reverse proxy: long-poll si interrompono per proxy_request_buffering attivo.
• Header sospetti: mismatch tra Accept-Encoding e User-Agent.
• Risposta vuota 404/405 sul percorso XHTTP — DPI lo classifica come anomalia.
• Header non standard X-* troppo numerosi, aumentano entropia senza bisogno.

Strumenti e risorse

Cosa usare nel 2026

• Xray-core aggiornato con supporto XHTTP e uTLS.
• Reverse proxy: Nginx, Caddy. Caddy facilita TLS automatico e comportamento HTTP/1.1 nativo.
• Analisi profilo di rete: ja3/s_jA3 per TLS, test h2spec/h2c se necessario, tcpdump/wireshark per pcap.
• Test di carico: vegeta, wrk per simulare traffico HTTP, iperf3 via tunnel per throughput.
• Monitoraggio: metriche Xray (se attivate), metriche sistema (conntrack, sockets), log reverse proxy.

Alternativa infrastrutturale

vpn.how offre server VPN personali con IP dedicato. Le località, i protocolli e i prezzi disponibili sono indicati sul sito e nel tuo account. I metodi di pagamento e il totale vengono mostrati al pagamento. Scegli un server

Casi d'uso e risultati

Caso 1: Rete campus con DPI aggressivo

Condizioni: consentito solo HTTPS su 443, HTTP/2 spesso instabile, WebSocket a volte si interrompe. Soluzione: VLESS+XHTTP su 443 con ALPN=http/1.1, percorso /api/metrics, POST+chunked, reverse proxy Caddy. Risultato: successo connessione al 98–99% (prima 70–80% su WS), latenza mediana +8–12 ms rispetto al baseline TLS, throughput 70–85% rispetto a TCP puro con iperf3 — adatto per applicazioni.

Caso 2: Perimetro aziendale con proxy

Condizioni: proxy trasparenti modificano header e bufferizzano il corpo. Soluzione: XHTTP dietro Nginx con proxy_request_buffering off, keepalive_requests=1000, header server corretti. Risultato: sparite interruzioni in sessioni long-lived, connessioni stabili oltre 2 ore senza chiusura forzata.

Caso 3: Operatore mobile con blocchi su QUIC e h2

Condizioni: h3 bloccato, h2 degrade, 443/tcp «pulito». Soluzione: XHTTP con profilo uTLS Chrome, porta 443, UA e Accept-Language realistici, MSS clamp a 1380. Risultato: stabile 10–30 Mbps, nessun RST in punta di carico, accesso riuscito a servizi precedentemente ostacolati da DPI.

FAQ

1. Perché XHTTP è migliore di WebSocket in Xray?

WS si identifica con header Upgrade: websocket e Sec-WebSocket-* che i DPI riconoscono facilmente. XHTTP usa un dialogo HTTP/1.1 ordinario senza campi specifici WS, riducendo il rischio di essere classificati. L’overhead è pari o inferiore.

2. Qual è la differenza tra XHTTP e il trasporto HTTP standard (HTTP/2) in Xray?

HTTP/2 offre multiplexing a livello frame e profili distintivi (ALPN h2, priorità, HPACK). XHTTP è una semplice imitazione HTTP/1.1 dove il flusso utile viaggia come body/chunked senza framing h2 esplicito. Meno visibile e più resistente in molti casi.

3. Si può usare XHTTP senza TLS?

Tecnicamente sì (in chiaro), specialmente dietro reverse proxy su localhost. Su Internet non è consigliato: TLS protegge il contenuto e riduce il rischio di classificazione. Senza TLS il DPI vede interamente richiesta e risposta.

4. XHTTP è compatibile con CDN?

Dipende dal CDN e dalle impostazioni. Serve supporto corretto di chunked, assenza di bufferizzazione aggressiva e chiusure idle forzate. Testate rigorosamente end-to-end nei PoP di destinazione.

5. Quale protocollo scegliere sopra XHTTP: VLESS, VMess o Trojan?

VLESS è considerato «pulito» e flessibile per scenari moderni, VMess è storicamente diffuso, Trojan semplice nel modello. Per il DPI conta più il profilo esterno (TLS/uTLS+XHTTP) e il comportamento HTTP che la semantica interna.

6. Qual è il rapporto tra ECH/REALITY e XHTTP?

ECH cifra il ClientHello e nasconde l’SNI, ma il supporto server/client è parziale. REALITY è un approccio alternativo di mascheramento, utile come back-up. XHTTP convive con loro, ma spesso basta uTLS+TLS1.3+XHTTP.

7. Perché a volte vedo 301/302 sul percorso XHTTP?

Redirect automatici da siti/app (es. verso https o altro host) interferiscono con il percorso XHTTP. Create una location separata senza redirect o logiche auth/CSRF.

8. Come configurare i timeout?

Reverse proxy: proxy_read_timeout da 90 a 600 secondi a seconda del caso. In Xray idle_timeout tra 60 e 300 secondi. Ensure che il livello superiore (CDN/proxy) non chiuda prima di Xray.

9. Come testare il realismo degli header?

Registrate traffico reale da browser verso il vostro sito, identificate header frequenti e ordine. Confrontate con quelli inviati dal client XHTTP, eliminate elementi troppo esotici e scegliete User-Agent, Accept e Language plausibili.

10. Si possono multiplexare più flussi logici in XHTTP?

Sì, lo fa il protocollo di livello superiore (es. VLESS/VMess con Mux). Ma misurate attentamente la latenza: a RTT elevati tanti sottostream in un canale HTTP peggiorano la latenza di coda.

Conclusioni

Il trasporto XHTTP per Xray è uno strumento pratico che «parla» il linguaggio familiare di HTTP/1.1 e minimizza così le firme visibili ai DPI. Il suo punto di forza è la semplicità: header credibili, semantica keep-alive corretta e assenza di segnali espliciti di WebSocket o HTTP/2. In combinazione con TLS 1.3 e uTLS garantisce connessioni stabili dove WS/H2/H3 sollevano sospetti, e il reverse proxy aiuta a integrare organicamente il tunnel in un sito operativo. Partite da uno schema minimo VLESS+XHTTP su 443 con uTLS, aggiungete reverse proxy senza buffering, regolate i timeout e controllate il CDN: avrete un canale affidabile. Ricordatevi dell’osservabilità, header realistici e aggiornamenti regolari dei profili uTLS. Se serve un’alternativa o un IP personale, valutate opzioni infrastrutturali. Infine, automatizzate le implementazioni, tenete a disposizione qualche dominio per cambiare scenario e rivedete trimestralmente i parametri di mimetizzazione per nuovi pattern DPI. Così XHTTP non sarà un espediente temporaneo, ma una parte gestibile della vostra architettura di rete.