VLESS + REALITY in simple terms
VLESS is a lightweight transport from the Xray team. It does not encrypt anything by itself and relies on external TLS. REALITY is a camouflage layer on top of VLESS that makes your connection look like a normal TLS handshake to someone else’s popular site, such as a major CDN or a cloud provider portal.
The “VLESS + REALITY” combination is the main modern answer to TSPU. From the DPI point of view, your client appears to have opened HTTPS to microsoft.com or yandex.ru: the certificate is real, the domain is live, and it is extremely hard to distinguish this from a regular browser. That is why people “talk about it a lot” — for bypassing deep inspection, it is currently one of the most effective options.
Below we will look at what each part does in this combination and why REALITY is fundamentally different from ordinary TLS camouflage such as Trojan or Shadowsocks-over-TLS.
In brief
- VLESS is a transport proxy protocol on the Xray core, without its own encryption.
- From the outside, VLESS is usually wrapped in TLS — hence combinations such as VLESS+TLS, VLESS+XTLS, and VLESS+REALITY.
- REALITY performs a TLS handshake with a real third-party site and presents its certificate to the client.
- For DPI, this looks like legitimate HTTPS to a popular domain — there is no signature.
- No self-signed certificates: forgery is not needed, the certificate is real.
- The weak point is that you need the “right” external domain to camouflage as.
How the VLESS + REALITY combination works
To avoid confusion, let’s separate three layers: transport, encryption, and camouflage.
What VLESS does
VLESS is simply a “wrapper” for your traffic. It takes outgoing packets, marks them with a user identifier (UUID), and sends them to the server. There is no cryptography inside. That is why VLESS almost always runs together with external TLS. Details are in the xray-core repository.
What REALITY does
REALITY replaces a regular TLS server with a clever proxy server. When the client connects, the REALITY server at that same moment connects to an external “cover” — a real site (target). It obtains the real TLS certificate from that site and continues the handshake with the client as if it were that site.
If the client is a real browser belonging to a random person, the REALITY server silently completes the connection to that same site and returns ordinary content. If the client knows the secret (a short key), REALITY switches the connection into proxy mode and passes traffic through VLESS.
Why this is hard to block
DPI on TSPU can try to distinguish “real” TLS from “proxy TLS” by small details: the ClientHello set, response time, certificate length. REALITY bypasses almost all classic indicators because it returns a real certificate from a real site and passes through real traffic from “extra” clients. Active probing (“let’s connect to this IP ourselves and see what it returns”) gets back the legitimate cover site.
How REALITY differs from TLS plugins
Older schemes such as Trojan or Shadowsocks+TLS required your own domain and your own certificate, for example through Let's Encrypt. DPI gradually learned to detect these combinations by behavior. REALITY does not have its “own” domain at all — it uses someone else’s real domain, so it makes no sense for the filter to block the target domain without affecting real users.
How to understand what exactly broke in VLESS+REALITY
| Symptom | Possible cause | What to check |
|---|---|---|
| The client says “handshake failure” | Incorrect public key or sid | Compare the config with the server config |
| There is a connection, but sites do not open | Routing on the client | Check that traffic goes to outbound, not to direct |
| It suddenly stopped working after a year of stability | The TLS fingerprint of the cover site changed | Change the target to a current popular domain |
| Works on Wi-Fi, does not work on LTE | The operator is filtering this specific IP | Change the server IP, check the blocking separately |
| The server connects, but there is a timeout on all sites | The client’s DNS goes outside the tunnel | Enable fakeip / proxy DNS in the client |
| The client shows reconnect flashing every 30 seconds | SNI is not working / sid mismatch | Recheck the browser fingerprint in outbound |
How to check right now
To understand whether DPI or your specific server is at fault, you need measurements from probes in different networks. Freedom Checker monitors availability by operator and region without advertising specific services — this makes it possible to separate a local problem from a systemic one.
If VLESS+REALITY does not respond only on one operator while it works on others, the issue is almost certainly filtering of this specific IP or port. If the protocol does not work anywhere, look for an error in the config or change the target.
Failure or blocking?
A VLESS+REALITY failure usually looks like the same outage for different users of one server: the VPS itself went down, the port is overloaded, or traffic ran out. Restarting the server fixes the problem.
Blocking appears differently — it works on some operators and not on others, and the same operator behaves differently in different regions. This is a typical pattern: TSPU has learned to filter by IP or by the behavior of a specific server. Most often, either changing the IP or changing the target domain to a “safer” one helps.
What to pay attention to
- The target must be a real, working popular site, not your own domain.
- On the client, be sure to specify the same uTLS fingerprint as in the server config, for example chrome.
- sid (short id) matters — the server uses it to distinguish a proxy client from a random guest.
- If you change the VPS, REALITY is not tied to a specific port; you can keep 443.
- REALITY is incompatible with old v2ray clients without xtls — you need Xray or sing-box.
- Do not show your config publicly: the unique sid + key are the access credential.
- A “backup” entry point on another IP with another target usually saves you on bad days.
Conclusion
The VLESS+REALITY combination is not a “magic VPN,” but a neat engineering idea: it stopped inventing its own camouflage and began using real third-party TLS. That is why it holds up better than most classic protocols.
If you already have a config, keep a spare one with another target and another IP. If you are only choosing what to run your VPN on, it makes sense to start with this combination.