What is VLESS?

A VLESS session begins with the client sending a small header: a version byte, the UUID that identifies the account, an optional add-on field, the command (connect over TCP, connect over UDP), and the destination address and port. The server checks the UUID against its list, opens the requested connection, and from that point simply copies bytes in both directions.

There is no per-message framing, no obfuscation layer, no timestamp handshake, no key exchange inside the protocol. The overhead per connection is a handful of bytes, and the CPU cost of the protocol itself is close to nothing. Everything expensive is happening in the TLS layer underneath, which every modern processor has hardware acceleration for.

This is why VLESS is described as a transport rather than a tunnel in the way WireGuard is a tunnel. WireGuard builds a network interface and routes packets. VLESS proxies streams: an application asks for a destination, the client wraps that request, and the server makes the connection. Whether your whole device goes through it depends on the client software you use, not on the protocol.

Older protocols in this family bundled their own cryptography. That created two problems. The first is that home-grown cryptography inside a censorship-resistant protocol is a bad bet: it is written by fewer people, reviewed by fewer people, and when it is wrong nobody finds out for years. The second problem is worse for the actual purpose. Custom encryption produces custom-looking traffic, and traffic that looks like nothing else on the internet is easy to single out even when it cannot be read.

VLESS takes the opposite position. It does the identification and the addressing, then gets out of the way and lets TLS provide confidentiality and integrity. TLS is the most analysed protocol on the internet, it is implemented by libraries that thousands of people audit, and, most usefully here, it is what almost every other connection leaving your device also looks like.

The practical consequence: a VLESS endpoint without TLS in front of it is genuinely insecure and should never be used. If you are handed a vless:// link where the security parameter is none, that link sends your account UUID and your destination addresses in the clear. Every configuration we issue uses TLS.

VMess came first, from the same project. It carries its own encryption, and it authenticates using a hash built from the account UUID and the current time. That time dependency is the source of the classic VMess failure: a client whose clock is more than a minute or two off the server simply cannot connect, with no useful error to explain why.

VMess also has a distinctive shape. Because it does its own framing and its own crypto, the resulting byte stream has properties that a filtering system can learn. Several national filtering systems demonstrated exactly that, and VMess deployments started wrapping themselves in TLS to survive, at which point the protocol was paying for encryption twice.

VLESS is essentially VMess with those two things removed: no built-in cryptography and no timestamp authentication. The result is lighter on the CPU, immune to clock skew, and, once TLS is doing the outer layer, considerably harder to fingerprint. If you are choosing today, there is no strong argument left for VMess.

Shadowsocks is an encrypted SOCKS proxy. Its traffic is designed to look like random bytes with no recognisable header at all. That worked well for years, but "a stream of high-entropy bytes on a port, with no TLS handshake in front of it" is itself a signature, and modern filtering systems have learned to look for exactly that pattern and to actively probe the servers that produce it.

Trojan took the other route: rather than looking like nothing, look like something extremely common. A Trojan server presents a real TLS certificate and, if a probe connects without the right password, serves an ordinary web page. To a scanner it is a web server. The weakness is that it needs a genuine domain and certificate, and the sites it is standing in for are usually low-traffic sites nobody visits.

VLESS over TLS sits in the same family as Trojan, and REALITY pushes it further along the same idea. The difference is that VLESS is a transport rather than a complete server design, so it can be carried over plain TLS, over WebSocket behind a CDN, over gRPC, or over REALITY, and you pick the one that suits the network you are on. That flexibility is the actual reason it has become the default in this ecosystem.

CDN fronting means your VLESS connection is not made to a server sitting alone on its own address. It is made to a content delivery network edge, over WebSocket or gRPC inside an ordinary HTTPS request, and the CDN forwards it onward. To anyone watching the network, you connected to an IP address that also serves thousands of unrelated websites, using a hostname and a certificate that belong to that CDN. Blocking that address means blocking a large slice of the ordinary web with it, which is a cost most networks will not pay.

REALITY attacks the problem from the certificate side instead. A REALITY server borrows the TLS handshake of a real, popular, unrelated website. When a censorship system actively probes your server, which is now a routine technique rather than a theoretical one, the probe receives the genuine handshake and the genuine certificate of that real site. The probe concludes it has found a mirror of a well-known service, because from the outside that is exactly what it saw.

Neither technique is magic and neither is permanent. Both are answers to a specific detection method, and detection methods change. What they buy you is that blocking your connection requires collateral damage the network operator may not want, rather than a rule that costs them nothing.

Filtering systems work in layers. The cheapest layer is a list of blocked addresses and hostnames. The next layer looks at the shape of the traffic: the handshake bytes, the packet size distribution, the timing. The most expensive layer connects to your server itself and tries to make it reveal what it is.

VLESS over TLS gives the first layer very little, because a CDN address cannot be added to a blocklist cheaply. It gives the second layer very little, because what is on the wire is a TLS session whose handshake fingerprint can be made to match a common browser, and the VLESS header itself only appears after that session is established, encrypted. REALITY answers the third layer directly by handing the prober a real site.

What still works against it: a network that permits only a whitelist of destinations, a network that blocks TLS to anything outside its own resolver and proxy, and traffic analysis over a long period, which does not need to read anything to notice that one connection carried a suspicious amount of data for a long time. VLESS is a strong answer to pattern matching. It is not an answer to a network that only lets you reach five approved addresses.

It is not anonymity. A VLESS connection moves the visible endpoint of your traffic from your own network to the server. Your local network and your access provider no longer see where you are going; the server does. That is a transfer of trust, not a removal of it. Our network keeps no logs, meaning source addresses and connection timestamps are not stored and the servers run from RAM so a reboot leaves nothing behind, but you should evaluate that claim the way you would evaluate anyone making it.

It is not Tor. Tor routes through three independent relays run by different people so that no single one knows both who you are and where you are going. VLESS is one hop to one operator. Tor is far slower and far stronger against that specific threat. If your risk model requires that nobody in the path can correlate both ends, a VPN of any protocol is the wrong tool.

It is also not a guarantee. A network can block a protocol, a country can block a CDN, and an endpoint that worked yesterday can stop today. Anyone promising that VLESS will always work in a named country is guessing. What is true is narrower and still useful: VLESS is built to look like ordinary encrypted web traffic, and it is what to try when plainer protocols fail.

Ours runs from four locations - Singapore, Tokyo, Los Angeles and Berlin - because CDN-fronted endpoints are maintained individually rather than spun up in bulk, and a short list that is looked after beats a long one that is not. VLESS access is included with every plan on /vpn/, alongside WireGuard and OpenVPN on servers in dozens of countries, and there is a live board at /vpn/status/ if you want to see the endpoints before deciding.