Hello everyone.
Today we are adding a new transport to VLESS, Trojan and VMess: XHTTP.
Every proxy protocol needs to move bytes between you and the server, and how it moves them matters more than people expect. WebSocket and gRPC are fine transports, but they have a tell: they are not how ordinary web traffic flows. They hold a connection open in a way that stands out, and they don’t pass through a CDN the way a normal page load does.
XHTTP is built around a different idea: carry the tunnel inside ordinary HTTP requests, so the traffic is indistinguishable from someone browsing a website — and, crucially, can be fronted by a CDN.
How It Works
XHTTP splits the two directions across HTTP requests:
- Download — the server responds with one long-lived response, streaming data back to you.
- Upload — your data goes out as a series of HTTP requests, in one of three modes.
The three modes control the upload:
packet-up— the upload is a series of numbered POSTs. The most compatible choice, and the one CDNs handle best.stream-up— one long-lived POST carries the upload, on a separate request from the download.stream-one— a single request carries both directions. Fast, but it needs the server and every middlebox in between to support full-duplex HTTP.
The HTTP version is chosen for you from context: HTTP/1.1 without TLS, HTTP/2 with TLS, HTTP/3 when you ask for h3 over ALPN. (REALITY always uses HTTP/2.)
Why CDNs Matter
The headline feature is that XHTTP can run through a CDN. Your connection terminates at a CDN edge — a Cloudflare, a fronting service — which forwards to your proxy server. To the outside world, you’re talking to a CDN. This changes what a censor sees, and it lets you spread your traffic across a service that is essentially unblockable.
XHTTP even splits the two directions across servers: the download can come from one address (a CDN edge) while the upload goes directly to the server. Both still reach the same server behind the scenes, so the session stays intact.
Fitting In Without Standing Out
Two more pieces make XHTTP blend in:
- Padding. Every request carries padding whose length the server validates, so request sizes don’t correlate with what’s inside.
- XMUX. With HTTP/2, XMUX pools the underlying connections so several tunnels share one — which looks like a normal browser session with many in-flight requests, rather than one connection per tunnel.
1 | VLESS = vless, 1.2.3.4, 443, uuid=uuid, tls=true, xhttp=true, xhttp-mode=packet-up, xhttp-path=/yourpath, sni=example.com |
What This Means
XHTTP is the most flexible transport we’ve shipped. On a strict network, it’s another arrow in the quiver alongside WebSocket, gRPC and REALITY — and for anyone fronting their server behind a CDN, it’s the natural choice, because it’s the transport that actually fits a CDN.
XHTTP is available on iOS and macOS for VLESS, Trojan and VMess. Full details — modes, XMUX, split download, padding — are in the Chute Manual.
Thanks.
Chute Devs