VLESS with Reality: How Xray Borrows a Real Site's TLS Handshake
Of 543 consumer VPNs in our data, 122 say they do not offer it. Below: the services that rank highest for it.
VLESS is a stateless proxy protocol from the Xray project that identifies a client by UUID and does no encryption of its own; Reality is a modified TLS 1.3 layer around it that presents the handshake and certificate of a genuine third-party site, so no domain of your own is needed. A client with the right x25519 key and shortId reaches the proxy; everyone else, including censor probes, is passed to the real site.
VLESS, the thin layer that leaves encryption to TLS
A VLESS client sends a lightweight header identifying itself by UUID, and the server routes the stream onward. The encryption field in the config is literally "none": confidentiality belongs to the TLS or Reality layer around the protocol. It descends from the V2Ray family, where the older VMess carried built-in encryption, and drops that to avoid encrypting twice. It is not a VPN service in itself: apps run it as a proxy, or in TUN mode that routes the whole device.
How Reality borrows a real website's handshake
The operator picks a target site, a popular resource the server has nothing to do with. The client sends that site's domain in the SNI field, and the server presents a real TLS 1.3 handshake to it; the server's allowed names must match names on the target's genuine certificate. No domain purchase, no certificate issuance.
Authentication rests on a key pair: the server holds an x25519 private key, the client the matching public half (called password in current Xray builds, publicKey earlier; Xray's docs warn against publishing it). The client also sends one of the server's allowed shortIds of up to 16 hex characters, an empty one only if the server lists it. When both check out, the client receives a temporary certificate signed with a temporary authentication key and gets the proxy; a probe without them lands on the real site. A client shown the genuine certificate browses the target like a crawler instead of connecting.
Why censors struggle to block it
| What the censor checks | What Reality shows | What still leaks |
|---|---|---|
| SNI in the handshake | a famous domain | an allowlist that excludes it |
| Certificate | the target's own | nothing, it is genuine |
| Active probe | the real site answers | a server far from the target's network |
| ClientHello fingerprint | a copied Chrome greeting | an outdated uTLS copy |
| TLS-in-TLS pattern | hidden by Vision | Vision not enabled |
| Server IP | a hosting address | the IP itself, once listed |
Blocking the borrowed domain hurts every normal visitor, and the operator owns nothing to blacklist. Per the REALITY project, the scheme drops the server-side TLS fingerprint, keeps forward secrecy and resists certificate-chain attacks, moving to the X25519MLKEM768 exchange automatically when the target supports it.
XTLS Vision and the transports Reality runs on
Route HTTPS through a TLS-tunnelled proxy and one encrypted session ends up nested in another, a shape DPI hunts. The xtls-rprx-vision flow pads the telltale early handshake records and passes the inner encrypted data straight through; per Xray's docs, Reality with Vision can be several times faster. Both ends must set the same flow, or nothing connects. Other protocols inside Reality are possible but advised against, because they re-create the obvious TLS-in-TLS shape. Transports are RAW (plain TCP), XHTTP and gRPC only: WebSocket is out, which rules out hiding behind a CDN that way.
Where the disguise fails
Reality changes the handshake, not the server's IP or hosting network: once the IP lands on a blocklist, no configuration helps, and networks passing only approved IP ranges (reported from mobile networks in some Russian regions) fail a rented VPS before SNI is read. SNI allowlists fail it too unless the borrowed name is listed. A famous domain served from a modest hosting IP far from that brand's network is a mismatch worth flagging, which is why the project recommends a target on the same network or ASN. The uTLS imitation ages with the library, and a Chrome greeting from a device that never runs Chrome stands out. Users in Iran report blocks after heavy shared use, and reports from Russia describe blocks aimed at TLS 1.3 on port 443; treat these as reports, not measurements. Pointing Reality at a site behind a big CDN turns your server into an open relay for that CDN, since failed connections are forwarded there.
VLESS Reality among VPN services
Of 377 services in the VPNRadarLab main ranking, 24 claim VLESS / Reality support, 104 say they do not offer it, and 249 publish nothing either way (undisclosed, not a "no"). The services that run VLESS Reality ranking lists providers, clients and panels such as Xray-core, v2rayN and 3X-UI. Trojan, NaiveProxy, Shadowsocks and Hysteria2 address the same stealth problem differently, and other ways to hide a tunnel are compared in the glossary; the official Reality settings reference documents each field.
VLESS Reality FAQ
Do I need my own domain for Reality?
No, the certificate comes from the target site you picked.
Should the Reality public key stay private?
Yes. Xray treats it like a secret, since the key plus a valid shortId grants access.
Can Reality run behind a CDN?
No. A CDN ends the TLS session itself, and WebSocket transports are not supported.
Which site makes a good Reality target?
A foreign site with TLS 1.3 and HTTP/2, no redirects, ideally in the same network as your server.
VLESS Reality at a glance
VLESS moves traffic and checks identity, Reality disguises it as a visit to a genuine site, Vision masks nested TLS. It survives SNI filters and probes, and loses to IP blocks and allowlists.
Top services: VLESS / Reality
- CitadelVPN8.55
- Xeovo VPN5.05
- StelsVPN4.79
- LightningX VPN4.76
- TorGuard4.61