VLESS transports: XHTTP vs gRPC vs TCP — what differs and which to use

In a modern client there is always a second setting next to the protocol: the transport. It is usually left at the default, yet in practice it shapes speed and stability as much as the protocol does. Here are the three you meet most often.

Protocol and transport are different things

The protocol (VLESS, for example) decides how the client introduces itself to the server and how the data is encrypted. The transport decides what shape that data takes on the wire. The same protocol can ride on different transports, and from the outside those connections look different even though the inside is identical.

TCP — direct and simplest

Data goes as one stream over an ordinary TCP connection. It is the leanest option: no extra layers, no extra headers, the shortest setup. That is why it is the default almost everywhere.

Its weak spot is predictability. The connection lives long, the stream is continuous, and its behaviour is fairly uniform. There is a purely technical cost too: one TCP connection for everything means a single lost packet holds up the whole queue behind it.

gRPC — over HTTP/2

Data travels inside gRPC calls over HTTP/2. From the outside it looks like a modern web app talking to its server. The practical upsides: the connection is multiplexed, middleboxes and load balancers handle it the way they handle any web traffic, and recovery after a drop is usually gentler.

The price is overhead. HTTP/2 headers and the gRPC wrapper add bytes to every exchange, and setting up the connection takes a little longer. On a fast link you will not notice; on slow mobile data you will.

XHTTP — the connection as HTTP requests

XHTTP is the newer transport of the Xray core. It wraps the connection in ordinary HTTP requests and responses, and paired with REALITY they run inside the same TLS as the cover website. To the network it looks like a browser talking to a site rather than one continuous stream of the same shape.

XHTTP has several modes. In packet-up, uploads go as a series of short requests, and losing one of them does not kill the session: the next request goes out on its own. In stream-up and stream-one, uploads stream inside one long request — faster and closer to TCP in behaviour, while still looking like an HTTP exchange from outside. The service picks the mode and sends it in the subscription.

Which one to use

• Stable home internet and you want top speed — TCP. It has the least overhead.
• Mobile data, frequent hand-overs between cell towers — XHTTP or gRPC: they take drops more gracefully.
• A weak device or a very slow link — TCP: the other two spend a bit more CPU and traffic.
• Not sure — keep what your service offers by default. The transport has to match on client and server, so it cannot be changed on one side alone.

XHTTP at ProxysVPN

Since 24 September 2026 the subscription carries a second United Kingdom server on XHTTP: VLESS + XHTTP + REALITY in stream-one mode. The regular United Kingdom server on TCP stays next to it; use either, both give a British address. Refresh the subscription in your app for the new server to appear.

It is a trial. We are watching how steadily this entry holds on different networks, and if it proves better than TCP we will move other countries to XHTTP too.

• You need a client on a recent Xray core, such as Happ.
• Clients on the sing-box core (Hiddify and similar) do not support XHTTP: the server will not connect there, so use the regular United Kingdom one.

For the difference between the protocols themselves, see VLESS Reality vs Hysteria2.