Where VLESS came from
VLESS is the direct descendant of VMess, the original protocol built for V2Ray — an anti-censorship proxy platform that grew out of the same community that produced Shadowsocks. VMess worked well, but it carried baggage: every request needed timestamps, authentication codes, and per-connection encryption metadata, which made it heavier than it needed to be and, in some cases, gave passive observers a recognizable pattern to fingerprint.
Around 2020, developers in the Project X community (the maintainers behind Xray-core, a V2Ray-compatible fork) proposed a stripped-down alternative. The idea was simple: if the transport layer — TLS — already provides encryption, authentication, and integrity checking, why duplicate that work inside the proxy protocol itself? The result was VLESS: "V" for the V2Ray lineage, "LESS" because it does less.
How it actually works
VLESS is a stateless protocol. It doesn't manage sessions, doesn't time-stamp requests, and doesn't encrypt its own payload — it assumes that job belongs to whatever transport carries it, almost always TLS 1.3. A VLESS packet is close to the minimum: a UUID that acts as the user's identity, a command, and the destination address. Everything else is delegated.
This minimalism has a direct payoff: less CPU overhead, smaller packets, and — critically — traffic that, once wrapped in ordinary TLS, is very difficult to distinguish from an everyday HTTPS connection to any website. That's the property that matters most in places with aggressive deep packet inspection: the goal isn't just to encrypt traffic, it's to make the traffic boring.
VLESS + XTLS
VLESS is most often paired with XTLS, a transport extension also from the Xray-core project. Standard TLS proxying re-encrypts data that's already encrypted by the inner protocol, wasting CPU cycles on redundant work. XTLS's "Vision" flow control can detect when inner traffic is already encrypted and skip the redundant re-encryption step for that portion of the stream, which is part of why VLESS-over-XTLS setups tend to benchmark faster than comparable OpenVPN or Shadowsocks configurations under load.
Because VLESS carries no encryption of its own, all of its detectable characteristics come from the outer TLS layer — the same layer that carries traffic to Google, your bank, or any HTTPS site. That makes protocol-level fingerprinting significantly harder than with protocols that have a distinctive handshake of their own.
VLESS vs. VMess
| Property | VMess | VLESS |
|---|---|---|
| Built-in encryption | Yes | No — relies on TLS |
| Session state | Timestamp-based | Stateless |
| Overhead | Higher | Lower |
| Typical pairing | TLS or none | TLS / XTLS |
| Fingerprint risk | Moderate | Low, when paired with TLS |
Where you'll encounter it
VLESS ships as a core protocol in Xray-core and V2Ray-based clients, and it's become one of the default recommendations in guides for accessing the internet from heavily filtered networks. It's rarely used raw — almost every real deployment wraps it in TLS and often adds a CDN or reverse proxy in front of the server, so the connection a censor sees is indistinguishable from ordinary encrypted web traffic to a large cloud provider.
MiTiVPN's obfuscation layer draws directly on this lineage: a stateless inner protocol, wrapped in standards-compliant TLS, so a connection has nothing distinctive to flag before it ever leaves your device.