What is VLESS: how the protocol works and what REALITY and XTLS do
A plain-language guide to VLESS: the layers in a connection, where encryption comes from, what REALITY and XTLS Vision do, and how to read a profile.
Updated:
VLESS is a lightweight protocol for moving data between a client and an Xray server. It identifies the user and carries traffic, but it does not describe the entire connection by itself. A working VLESS profile also includes a transport, a channel-protection method, and several supporting parameters.
In short: think of VLESS as the rules used by an app and a server to talk to each other. TLS or REALITY protects that conversation while it crosses the network, while XTLS Vision can optimize the handling of traffic that is already encrypted.
VLESS in plain English
When you open a website through a compatible client, the app receives traffic from your device, packages the request according to VLESS, and sends it to an Xray server. The server checks the user identifier, extracts the request, and opens a connection to the destination.
A simplified flow looks like this:
- A browser or app creates a normal network request.
- The Xray client receives it through a system VPN/TUN interface or a local proxy.
- The client adds VLESS metadata and the user identifier.
- The connection travels over the selected transport with TLS, REALITY, or another matching protection method.
- The Xray server checks access and forwards the request to the destination.
- The response returns over the same connection.
VLESS is described as stateless. Unlike VMess, it does not require the client and server clocks to remain synchronized within a small time window.
Protocol, transport, and protection are separate layers
Most profile names become easier to understand when the connection is split into layers.
| Layer | Examples | What it controls |
|---|---|---|
| Local client mode | VPN/TUN, system proxy | Which apps on the device send traffic to the client |
| Proxy protocol | VLESS | Request format, user identification, and communication with the Xray server |
| Transport | RAW, XHTTP, gRPC, WebSocket | How the data stream moves between client and server |
| Transport protection | TLS, REALITY | Channel encryption, server verification, and connection characteristics |
| Flow control | XTLS Vision | Optimized handling for some kinds of traffic |
That is why “VLESS over XHTTP” and “VLESS + REALITY + Vision” describe combinations of settings, not competing standalone protocols.
How VLESS identifies a user
In a conventional profile, access is tied to an id, usually represented as a UUID. The client sends it in the protocol metadata, and the server compares it with its list of authorized users.
A UUID should not be treated as information that is safe to publish. Anyone who obtains a working connection link or configuration may be able to use the access contained in it. Handle a profile like a password:
- do not post the link in public chats or forums;
- do not paste it into random “profile checker” websites;
- remove the profile from an old device before giving the device away;
- reissue access if the link becomes public.
Does VLESS encrypt traffic?
It depends on the complete configuration.
Historically, most profiles used encryption=none: VLESS did not encrypt the payload at the protocol layer, so a public connection required TLS or REALITY around it. Current Xray versions also offer optional VLESS Encryption, but both endpoints must support matching parameters generated correctly for Xray.
The practical rule is simple: do not judge a profile by the word VLESS alone. Check the full set of parameters. A profile with security=none only makes sense on a trusted private network or with separately configured VLESS Encryption. A typical public server uses security=tls or security=reality.
What is REALITY?
REALITY is an Xray transport-protection mechanism based on a modified TLS-like handshake. It verifies the server and produces a connection whose external characteristics are closer to ordinary web traffic.
REALITY is a separate layer rather than part of the VLESS name. A REALITY profile commonly contains:
security=reality— the selected protection mode;sniorserverName— a name used while establishing the connection;fporfingerprint— the TLS client fingerprint profile;pbk— a public server parameter, calledpasswordin newer Xray documentation;sidorshortId— a short identifier agreed with the server.
Do not change these values at random. The client and server need compatible settings.
What does XTLS Vision do?
xtls-rprx-vision is a flow-control mode. It reduces unnecessary processing in compatible VLESS and transport combinations, especially when the payload already contains TLS 1.3 traffic.
It often appears in a link as flow=xtls-rprx-vision. Vision is not a separate app or a standalone VPN protocol. If a service provides the profile, import it as a whole: removing flow or replacing the transport can make the configuration incompatible with the server.
What is inside a vless:// link?
A typical link includes the server address, port, user identifier, and parameters after the ? character:
vless://UUID@server.example:443?type=raw&security=reality&flow=xtls-rprx-vision&sni=example.com&fp=chrome&pbk=...&sid=...#ProfileThis is an example format, not a working configuration.
| Parameter | Meaning |
|---|---|
UUID |
User access identifier |
server.example |
Server domain or IP address |
443 |
Connection port |
type |
Transport such as RAW, XHTTP, gRPC, or WebSocket |
security |
TLS, REALITY, or another agreed mode |
flow |
Flow-control mode when required |
sni |
Server name used by TLS or REALITY |
fp |
TLS client fingerprint |
pbk, sid |
REALITY verification parameters |
#Profile |
Display name after URL encoding |
Field names may differ between a compact link and a JSON configuration. The client converts the link into core settings during import.
How VLESS differs from a VPN tunnel
VLESS is a proxy protocol, while WireGuard and OpenVPN create network tunnels. A mobile VLESS client can still display the system VPN icon because it uses the operating system’s VPN API to collect app traffic before passing it to Xray.
The client’s system-level “VPN mode” and the protocol used to reach the server are not the same thing. See the VLESS, VMess, Trojan, Shadowsocks, WireGuard, and OpenVPN comparison for the practical differences.
Strengths of VLESS
- A simple identification model without clock-synchronization requirements.
- Compatibility with several Xray transports.
- TLS or REALITY can be used as a separate protection layer.
- XTLS Vision support in compatible configurations.
- A broad selection of desktop and mobile clients.
Limitations and common mistakes
- The protocol name does not guarantee service quality. Speed depends on routing, server load, the provider, the transport, and configuration.
- Not every client supports every new parameter. An old app may import a link but still fail to connect.
- Configuration parts are not interchangeable. The transport and protection settings must match on both endpoints.
- VLESS does not make a user anonymous automatically. A service still processes technical data required to operate, while websites see the exit server and can recognize users through cookies or accounts.
- A profile cannot repair a poor route. If packet loss is high, test another location or network, or contact support.
When VLESS is a sensible choice
VLESS is practical when your service provides a ready profile, the server is configured correctly, and your platform has an actively maintained compatible client. Most users do not need to edit every field manually; importing the supplied link and keeping the app updated is safer.
For NetGuard setup, choose your device: Windows, macOS, Linux, Android, iPhone and iPad, or Android TV.
Frequently asked questions
Are VLESS and Xray the same thing?
No. Xray-core is a networking core that supports VLESS and other protocols. A graphical client manages the core, imports profiles, and routes device traffic.
Is REALITY required for VLESS?
No. VLESS can work with TLS, REALITY, and other compatible configurations. The server settings determine which one is required.
Can one link be opened in any client?
Only when the client supports every parameter in the profile: protocol, transport, protection, and flow mode. REALITY, XHTTP, and XTLS Vision support are especially important to check.
Should I edit an imported profile?
Usually not. If it fails, update the client, import a fresh link, and test the network first. Do not change SNI, fingerprint, public key, or short ID without information from the service.