You bought a key. The message says \u201cVLESS\u201d. Then comes a string that looks like a Wi-Fi password invented by an angry person.<\/p>\n
VLESS is in the message. What exactly is it, why isn’t it a \u201cregular VPN,\u201d where do you put it, and will it stop working next week? There are plenty of questions, while clear answers are surprisingly hard to find.<\/p>\n
Let\u2019s do this properly.<\/p>\n
If you have no time, here is the short version: VLESS is not a VPN in the usual sense. It is a transport protocol from the Xray project: lightweight, fast, and designed to make the traffic less distinctive to a provider observing it. Now let\u2019s go step by step.<\/p>\n
I should be transparent from the start: I have a vested interest here. I work for a service that sells VLESS. So if it sounds like I am praising it, you may not be imagining things. I will still cover where it loses, because it does have obvious weak points and pretending otherwise only makes you angry later.<\/p>\n
First there was Shadowsocks. It was almost ridiculously simple, worked for years, and I still remember it fondly because it did one job and did it well. Then people learned to identify it. It did not happen overnight \u2014 it kept going for years with obfuscation plugins bolted on, like extensions added to an old house until nobody knows what the original building looked like.<\/p>\n
Then V2Ray appeared. This was no longer a single protocol but a whole platform \u2014 a toolkit for combining transports and protocols in different ways. VMess lived inside it, with its own encryption, authentication and, importantly, a time check. VMess worked, and it worked for a long time. Without one problem, it would probably still be everywhere.<\/p>\n
Later, part of the team split off and created Xray. I will skip the project-history drama; open source projects tend to produce enough of that on their own. What matters here is simple: VLESS appeared in Xray.<\/p>\n
And they made it, deliberately, poorer than its predecessor. They removed encryption. They removed the time check. They kept the bare minimum.<\/p>\n
Sounds like a downgrade?<\/p>\n
I thought exactly that until I ran into the consequences. More precisely, until I stopped running into the old problems and initially blamed it on luck. Only later did I understand why.<\/p>\n
The key thing to understand is this: VLESS does not encrypt anything itself.<\/p>\n
Everyone reacts the same way: \u201cSo my traffic goes out in the clear?\u201d No. Encryption has not disappeared; it moved one layer down, into TLS. The same TLS protecting your bank tab, your email and virtually all modern HTTPS. It has been scrutinized for decades and does its job rather better than a custom encryption layer inside a VPN protocol.<\/p>\n
Compare that with the old approach. VMess encrypted the payload itself, then the whole thing was wrapped in TLS, which encrypted it again. Encryption inside encryption. It worked, but you paid for it with CPU time on both ends. On a modern PC you barely notice; on an older Android phone, especially while it is sitting in your pocket and heating up, you can. The security gain from the second layer is close to zero: you are encrypting something that is already encrypted.<\/p>\n
The second reason is less obvious and once cost me more than one evening. Remember VMess time synchronization? The server and client needed reasonably synchronized clocks. A few minutes of drift and the connection simply failed, often without a useful error. The user checks the key, reinstalls the app, contacts support, and support asks about the clock. In VLESS that mechanism is gone. One whole category of mysterious failures disappears.<\/p>\n
By the way, the most common reason people say \u201cVLESS does not work\u201d has nothing to do with the protocol: the config was copied incompletely and the end of the long line was cut off when copied from a messenger. More on that at the end.<\/p>\n
So: VLESS handles identity and routing. TLS handles privacy and encryption. Separate responsibilities, each layer doing its own job.<\/p>\n
VLESS authentication is deliberately simple, and I mean that as a compliment. There is a UUID \u2014 an identifier such as A subscription is a different thing. A single key is one Now it gets a little more technical, but I\u2019ll keep it diagram-free.<\/p>\n Imagine opening an HTTPS site. The browser encrypts the request in TLS, and then that already encrypted stream is wrapped in a VPN tunnel that also uses TLS. TLS inside TLS. The problem is not only performance. The construction has a recognizable fingerprint: packet sizes, timing and the relationship between what you send and what comes back. Traffic-analysis systems learned to recognize these patterns.<\/p>\n XTLS is an attempt to avoid that second pass for data that is already encrypted, forwarding it almost as-is and changing only what is necessary. The current implementation is called XTLS-Vision and also reduces characteristic patterns in the first packets, which are among the easiest parts of a connection to identify.<\/p>\n Here is an analogy that works reasonably well. A package is already sealed in a box. A normal VPN puts that box inside another box and tapes it up; its shape and weight make the extra layer obvious. XTLS puts a new address label on the original box and sends it on.<\/p>\n If you read the article for one section, this is it.<\/p>\n The classic TLS setup requires a domain and a certificate. You configure the server and get a tunnel that looks like a normal HTTPS site from the outside. It looks convincing at first. But look closer: the domain may be brand new, have virtually no normal traffic, and if a browser connects to it, there may be no real site behind it. That is where active probing comes in: a system detects something suspicious, connects to the same address and checks what answers.<\/p>\n Reality takes a different approach. It does not pretend to be a site. It uses a real one<\/em>.<\/p>\n The mechanism is straightforward in concept: during the handshake, the server uses the certificate chain of a real third-party site \u2014 a large, live and normally reachable site unrelated to your server. To an observer, the connection looks like a visit to that site. If someone actively checks the address, they can receive a normal working resource because the connection is actually forwarded to the real site. There is no custom domain and no custom certificate that says \u201cthis is a VPN node.\u201d<\/p>\n That creates an important requirement that guides often mention far too casually: choose the cover site carefully. It should be popular, reachable and reasonably consistent with the server\u2019s geography. Using an obscure site that nobody in the target network normally visits can itself become a signal. A provider should account for this and change cover sites when necessary.<\/p>\n Does Reality work perfectly forever? No. I do not know anyone sensible who claims that. The arms race continues. But the point of Reality is precisely to make active probing and passive traffic analysis harder by using a genuine TLS\/HTTP endpoint.<\/p>\n The question \u201cwhich is better?\u201d is not quite right because these tools solve different problems. But since everyone compares them, let\u2019s compare them.<\/p>\n7a1b2c3d-4e5f-6789-abcd-ef0123456789<\/code>. The server knows a list of UUIDs, the client presents one, and if it matches, access is granted. No usernames, passwords or email recovery. The important consequence is easy to miss: your UUID is your password<\/strong>. Send it to a friend in a chat and you have shared access. Post a config screenshot without hiding it and someone else can use your plan.<\/p>\nvless:\/\/...<\/code> URL describing one specific server. It works, but it is rigid: if the server changes or the protocol configuration is updated, your key can become useless. A subscription URL lets the client fetch the current list of nodes, so when we move infrastructure on our side, new entries simply appear in your app. When networks and addresses are regularly blocked in batches, a subscription is not just convenient \u2014 it is practical.<\/p>\nXTLS: how to stop encrypting the same thing twice<\/h2>\n
Reality \u2014 this is where the important part begins<\/h2>\n
VLESS vs WireGuard and OpenVPN: an honest comparison<\/h2>\n