VLESS
VLESS is a transport protocol from the Xray project. Its defining trait is what it lacks: encryption of its own. The data is encrypted by the layer beneath it — TLS or Reality — while VLESS only handles identifying the user and routing the connection. That is a deliberate omission: VMess, its predecessor, encrypted the payload itself, which meant double encryption — the CPU paid twice while security gained nothing, because TLS was wrapping everything anyway.
In short
VLESS makes sense wherever a solid encryption layer already sits above it — which is nearly always. On its own, without TLS or Reality, it carries data in the clear; that is not a flaw but a condition of use.
Frequently asked
VLESS does not encrypt — does that make it insecure?
Only if used without an encryption layer, which in practice never happens: VLESS is always paired with TLS or Reality, and those provide the encryption. The split of responsibilities mirrors HTTP and HTTPS — plain HTTP encrypts nothing either.
How is VLESS better than VMess?
It is simpler and cheaper on resources. VMess carried its own encryption plus a time binding: client and server clocks had to agree within minutes or the connection failed. VLESS dropped both, so it uses less CPU and does not break when clocks drift.
Does it need separate configuration?
Not in client apps. VLESS parameters arrive inside the subscription link together with the transport settings, and the app parses them itself. This layer is usually never touched by hand.