VLESS XHTTP

VLESS XHTTP is the third mode that Colitu Adaptive Connect tries on Android and iOS, and one of the TCP modes ranked by connect time on Windows and Linux. It uses the same VLESS protocol and the same Reality camouflage as VLESS Reality, but changes how the data travels: instead of one long-lived raw stream, the traffic is carried as HTTP requests and responses.

#What it is

XHTTP is a transport of Project X (Xray), the open-source toolkit that also provides VLESS and Reality. It grew out of Xray's earlier SplitHTTP transport. The idea is to carry a proxy session using ordinary HTTP semantics, with the upload and download directions able to travel in separate HTTP requests. In other setups this lets XHTTP pass through anything that understands HTTP; in Colitu it runs directly over Reality, so the outer layer is the same camouflaged TLS 1.3 connection as in VLESS Reality.

#How it works

1. Reality handshake. The app opens a TCP connection and performs a Reality TLS 1.3 handshake: browser-like fingerprint, hidden X25519 authentication, and probes relayed to the real target website. The XHTTP mode has its own Reality key pair, separate from VLESS Reality.
2. Secret path. Inside the TLS session the app speaks HTTP to a random path on the server that only the app knows. The tunnel does not answer on any other path.
3. Download direction. Data from the server arrives as the body of an HTTP response, streamed to the app.
4. Upload direction. Depending on the mode, data from the app is sent as a series of separate POST requests (packet-up), streamed in one request body (stream-up), or shares a single request with the download (stream-one). Colitu sets the mode to "auto" and lets Xray choose.
5. VLESS inside. The VLESS request with the device's user ID and the destination travels inside this HTTP exchange, just as it would inside a raw stream.

#Why Colitu uses it

Some networks terminate or degrade TCP connections that stay open a long time, or that move a lot of data as one opaque stream, which is the typical shape of a VPN tunnel. Splitting the session into HTTP requests changes that shape into something that behaves like HTTP traffic. This is the case XHTTP was built for, and it gives Adaptive Connect a Reality-based option when plain VLESS Reality connects but then stalls or gets cut.

#Where it is strong

• Networks that cut long TCP connections: traffic is spread across HTTP requests instead of one endless stream.
• DPI-filtered networks: it inherits Reality's camouflage, browser-like fingerprint and protection against active probing.
• Networks that block UDP: like the other TCP modes, it does not depend on UDP.

#Limitations and when it is not the best choice

• More overhead. HTTP framing and separate requests add overhead and a little latency. On a clean network, VLESS Reality with Vision is leaner.
• No Vision. XTLS Vision needs a raw TCP stream, which XHTTP does not provide, so Vision's handling of the "TLS inside TLS" pattern is not available in this mode.
• TCP on lossy links. On mobile data or poor Wi-Fi with heavy loss it slows down like any TCP protocol; Hysteria2 is usually faster there.
• Same Reality limits. The SNI names a third-party site while the IP address belongs to a different network; filters that compare the two, or block by IP address, can still act.
• A younger transport. XHTTP is newer than the other modes and is still evolving in Xray.

#How Adaptive Connect uses it

On Android and iOS, VLESS XHTTP comes third: after Hysteria2 and VLESS Reality, before Trojan and Shadowsocks 2022. It is reached when UDP is unusable and plain Reality either fails to connect or does not pass the traffic check. On Windows and Linux it is ranked with the other TCP modes by measured connect time. If XHTTP also carries nothing, the app pushes it back and moves to the next mode.

#Security and encryption

• Encryption: the outer layer is a Reality TLS 1.3 session with X25519 key exchange, protected with TLS 1.3 AEAD ciphers.
• Server authentication: the handshake must prove knowledge of the private key behind the XHTTP mode's Reality public key; otherwise the app does not accept the server.
• Client authentication: the Reality authentication block, the secret HTTP path and the VLESS user ID, which is part of each device's own credentials.
• Key handling: keys, short IDs, path and target are delivered to the app in encrypted form and never published.
• No access logs: see the security page.

#Sources

• Project X (Xray) documentation
• REALITY on GitHub
• RFC 8446: TLS 1.3

#Try it

VLESS XHTTP is built into every Colitu app and steps in by itself when long connections keep dropping. Download Colitu or see the server locations.