What Is VLESS?

Definition#

VLESS is a stateless, lightweight proxy protocol that carries requests between an Xray client and server. Its own documentation describes it in one line: a protocol with no state and no encryption of its own, whose entire job is to move an address, a port and a payload from one end to the other.

What problem it solves#

Server state. The protocol it was built to replace, VMess, keeps per-session state and generates per-request randomness on the server. That costs memory, costs CPU under load, and makes adding or removing users awkward. VLESS’s design note is explicit that the earlier “response authentication” mechanism was dropped in favour of a leading protocol-version byte, which removed the need to generate pseudo-random numbers entirely. A stateless server validates a UUID and forwards.

A protocol that encrypts, then wraps its own encryption in TLS, produces a recognisable structure: TLS inside TLS. Because the layers are visible to anyone reading the byte stream, this is not a weakness that better parameters fix. The Xray project’s own guidance warns about it: pairing REALITY with proxy protocols other than XTLS produces clear TLS-in-TLS characteristics that have already been targeted.

VLESS removes the inner layer instead of trying to disguise it.

How it works, at the depth that matters#

A request is a compact, fixed-layout frame:

1 byte    protocol version
16 bytes  UUID
1 byte    length of the addons section
M bytes   addons, protobuf-encoded, optional
1 byte    command
2 bytes   port
1 byte    address type
S bytes   address
X bytes   request data

The response has the same shape in miniature: a protocol version, an optional addons section, and the response data.

Three properties follow from that design.

It is a protocol with no cryptography. Everything security-relevant is delegated to the transport carrying it. Used over plain TCP with nothing else, VLESS is an unencrypted forwarding format. That is the design rather than a flaw, and it is why VLESS is always described together with a transport.

The server holds no session table. Adding a user means adding a UUID; removing one means removing it. The project’s documentation notes that this lets a server handle very large numbers of users with fast verification, and that changes take effect immediately.

Versioning happens at the front. The first byte is a version, so the framing can evolve without a separate negotiation, and a server can support more than one version at once.

XTLS Vision is the common pairing: VLESS is commonly paired with a flow-control mode called XTLS Vision. It is optional, and it is a performance feature: the project’s documentation describes it as avoiding redundant copying of already-encrypted data, with the largest gains on TLS transports.

What it explicitly does not do#

• No encryption. On its own it protects nothing.
• No obfuscation. It does not try to look like anything. It aims to look like nothing at all, which is a different strategy.
• No certificate handling, no key exchange, no replay protection. All of that belongs to the transport.
• No anonymity. The exit server still sees the origin, and the destination still sees the exit.
• No standalone use. VLESS without a secure transport is not a VPN, however the configuration file is written.

How a censor sees it#

On its own: nothing to see. A bare VLESS stream is a small, regular, unencrypted framing format with a stable header. Anyone can see what it is, which is why nobody uses it that way.

Inside a TLS transport: TLS. If VLESS runs inside ordinary TLS, what a censor sees is a TLS session. Whether that session is distinguishable depends on the transport rather than on VLESS, and on the specific weakness the project warns about, where a proxied protocol inside TLS leaves a nested structure behind.

Inside REALITY: the real site’s handshake. This is the pairing REALITY was designed for. Because VLESS contributes no encryption of its own, the transport’s characteristics are the whole of what is visible, and REALITY makes those characteristics those of a genuine site.

When it fits#

Good fit: you are running Xray on both ends; you want a proxy core with minimal server state; you have chosen a transport that handles security, and the pairing is the design, not a workaround.

Poor fit: you want a single self-contained protocol that secures the connection on its own; you want a protocol that resists detection by itself; you prefer fewer moving parts than an Xray deployment provides.

Related#

• What Is REALITY? — the transport VLESS is normally paired with
• What Is a VPN Protocol? — how a protocol with no cryptography fits into the set
• What Is WireGuard? — the opposite approach: all the cryptography, and no proxy core
• What Is Hysteria2? — the QUIC option: encryption from the transport, plus its own congestion control

Last reviewed October 30, 2026. This article was revised after publication. Corrections and additions are welcome.