What Is VLESS + REALITY? The Protocol, Explained Simply
It borrows a real website's identity instead of faking one. That single idea is why it's fast, why it's hard to block, and why it needs no certificate.
On this page
VLESS + REALITY is a VPN protocol from the open-source Xray-core project that makes your connection look like an ordinary HTTPS visit to a real website. VLESS is the lightweight tunnel that carries your traffic. REALITY is the disguise: your server borrows the genuine TLS 1.3 handshake of a real site, such as a bank's, instead of using a certificate of its own. Anyone who connects without your key is handed that real website. That's why it's hard to detect and block, and why it needs no domain or certificate. Paired with XTLS Vision, it's also one of the fastest protocols available.
This guide explains how it works in plain terms, how it compares with WireGuard, Trojan and Shadowsocks, and what you need to use it.
Key takeaways
- VLESS (2020) carries your traffic with almost no overhead. REALITY (Xray-core 1.8.0, March 2023) disguises it as a real TLS 1.3 website. XTLS Vision (2022) stops already-encrypted traffic from being encrypted twice.
- A REALITY server has no certificate of its own. Connections without the right key are forwarded to the real website it imitates, so a probe sees a genuine site with a genuine certificate.
- It runs on TCP port 443, the same port as every HTTPS website, so it works on networks that block UDP VPNs such as WireGuard.
- Since Xray v25.5.16, REALITY supports the post-quantum hybrid key exchange X25519MLKEM768. From v26.9.9, servers can reject clients that don't offer it.
- It works in Xray-based apps such as Happ, V2Box, Streisand, Hiddify and v2rayNG. Older upstream sing-box apps (1.14 and earlier) can't complete the post-quantum handshake.
What do VLESS, REALITY and Vision each do?
People say "VLESS REALITY" as if it were one thing. It's really three parts, each solving one problem.
| Part | Introduced | Job | What it replaces |
|---|---|---|---|
| VLESS | August 2020 (v2ray-core 4.27.0) | Carries your traffic and checks your ID | VMess, which added its own encryption layer |
| XTLS Vision | October 2022 (Xray-core 1.6.2) | Passes inner TLS through without re-encrypting it, and pads traffic patterns | Plain TLS tunnels that encrypt HTTPS twice |
| REALITY | March 2023 (Xray-core 1.8.0) | Makes the connection look like a real website's TLS 1.3 handshake | Your own domain and certificate (as in Trojan or VLESS over TLS) |
VLESS: the tunnel
VLESS is deliberately minimal. It identifies your account with a UUID and then carries your data. It doesn't add its own encryption, because the layer around it (TLS or REALITY) already encrypts everything. Less work per byte means more speed.
XTLS Vision: no double encryption
Most of what you send is already encrypted: every HTTPS site, every app API, every video stream. A classic VPN encrypts it a second time anyway. Vision recognises TLS 1.3 traffic inside the tunnel and, once the inner handshake is done, forwards the already-encrypted data as it is. On Linux servers it can hand that data straight to the kernel with splice, without copying it. It also pads the start of connections, so the "TLS inside TLS" pattern is harder to spot.
REALITY: the borrowed identity
This is the clever part. Normally a server proving it is www.example.com needs a certificate for that domain. REALITY skips that.
- Your app opens a TLS 1.3 connection to your server and names a real website, say a bank, in the handshake. The handshake looks exactly like Chrome's.
- Hidden inside that handshake is a value only your app can produce, derived from the server's public key and your short ID.
- If the value checks out, the server knows it's you and carries your VLESS tunnel.
- If it doesn't, because a censor, a scanner or a curious network admin is probing the server, it quietly forwards the connection to the real bank. The prober gets the bank's real website and its real certificate.
From the outside, your server behaves like a path to a well-known site. There's no self-made certificate to flag, no fake website to catch out, and no domain of yours to block.
We test this on every server we deploy. When we connect to one without the key, we get the real website it borrows, with that site's own certificate.
Why is VLESS + REALITY hard to block?
Networks block VPNs in three ways. REALITY answers each one.
| How networks block VPNs | Classic VPNs | VLESS + REALITY |
|---|---|---|
| Block by port or protocol (UDP, 1194, 500/4500) | WireGuard, OpenVPN and IKEv2 fail | Uses TCP 443, like every HTTPS site |
| Fingerprint the traffic (deep packet inspection) | OpenVPN identified in over 85% of flows in a 2022 study | Handshake looks like real Chrome TLS 1.3 |
| Probe the server to see what it is | Self-signed or unusual certificates give it away | A probe is handed a real website and certificate |
Contrast this with Shadowsocks and VMess, which try to look like random bytes. A USENIX Security 2023 paper showed how China's Great Firewall has blocked such "fully encrypted" traffic since November 2021, using simple statistical tests. REALITY doesn't try to look random. It looks like the most common thing on the internet: a browser talking TLS 1.3 to a big website.
One honest limit: on a device or network that intercepts and decrypts all TLS, such as a managed company laptop with a corporate root certificate, REALITY can't pass, and neither can any other VPN. Our guide to VPNs on hotel and office Wi-Fi covers what to do there.
Is VLESS + REALITY fast?
Yes. It's among the fastest protocols you can run today, for three reasons: VLESS adds almost nothing, Vision avoids double encryption, and VLESS carries streams rather than raw packets, so it doesn't suffer the "TCP meltdown" that slows OpenVPN over TCP.
What we measured on our own servers (12 November 2026):
- 2.0 Gbit/s on one connection through the full VLESS + REALITY + Vision stack, London to Frankfurt.
- 1.1 CPU-seconds per gigabyte on a single-vCPU server.
- On café Wi-Fi in an interleaved test (10 November 2026), download through the tunnel ran at 182–202 Mbit/s against 183 Mbit/s direct. The Wi-Fi was the limit, not the VPN.
There is one cost. REALITY adds a few milliseconds when a new connection opens, because the server checks the handshake against the real site it borrows. We measured about 10–25 ms of server-side time for this. So we pick each server's borrowed site by measured handshake speed from that server, not by habit. Connections that are already open don't pay it again.
VLESS + REALITY vs WireGuard, Trojan and Shadowsocks
| VLESS + REALITY + Vision | WireGuard | Trojan | Shadowsocks | |
|---|---|---|---|---|
| Transport | TCP 443 | UDP only | TCP 443 | TCP/UDP, any port |
| Looks like | A real website's TLS 1.3 | WireGuard (fixed handshake sizes) | Your own HTTPS site | Random bytes |
| Needs a domain and certificate | No | No | Yes | No |
| Survives UDP blocking | Yes | No | Yes | Partly |
| Active-probe resistance | Hands probes the real site | Silent | Falls back to your web server | Varies by implementation |
| Post-quantum key exchange | Yes (X25519MLKEM768) | Only with add-ons | Depends on TLS stack | No |
On an open home network, WireGuard is just as fast. The difference shows up on restrictive networks. For a broader comparison, see the fastest VPN protocols in 2026. For the wider family of disguised protocols, see what a stealth VPN is.
What do you need to use it?
You need two things: a server running Xray-core with REALITY, and an app that speaks it.
The server side needs a carefully chosen borrowed site. It should support TLS 1.3 and HTTP/2, have a fast handshake from the server's location, and not belong to a giant CDN whose IP ranges are well known. Then come the keys: a public/private key pair and short IDs. Getting these details wrong is the most common reason self-hosted setups are slow or get noticed.
The app side is easy with a provider. You import one subscription link, and the app fills in the server, public key (pbk), short ID (sid), borrowed site (sni), fingerprint (fp=chrome) and flow (xtls-rprx-vision) for every server. Apps that work with REALITY include:
- Happ: iOS, macOS, Android, Windows, Linux, Apple TV.
- V2Box: iOS, macOS, Android.
- Streisand: iOS and macOS.
- Hiddify: Android, iOS, Windows, macOS, Linux. Open source.
- v2rayNG: Android. Open source.
Step-by-step setup for each app is in our subscription link guide.
Is VLESS + REALITY safe and private?
The encryption is standard TLS 1.3, the same as your bank's website, with a hybrid post-quantum key exchange on top. The code is open source and widely reviewed: Xray-core is public on GitHub, with public issues and fixes. As with any VPN, privacy then depends on the provider: what it logs and who runs the servers. Ask any provider what it keeps. SleekDart keeps account details and data used, not the sites you visit.
Frequently asked questions
What is VLESS REALITY in simple terms?
It's a VPN protocol that makes your connection look like a normal visit to a real, popular website. Your server borrows that site's TLS 1.3 handshake instead of using its own certificate. Your app has a secret key that unlocks the tunnel. Anyone without it, such as a censor or a scanner, is simply shown the real website.
Is VLESS a VPN?
VLESS is a proxy protocol, the tunnel part of a VPN. Combined with REALITY for disguise and an app that sends all of your device's traffic through it (TUN mode), it works like a full VPN: every app's traffic goes through the encrypted connection to the server.
Is VLESS + REALITY better than WireGuard?
On open home networks they're equally fast. VLESS + REALITY is better on networks that block UDP or inspect traffic, such as hotels, offices, schools and countries with heavy filtering, because it runs on TCP 443 and looks like real HTTPS. WireGuard is UDP-only and easy to recognise.
Does VLESS REALITY need a domain or certificate?
No. That's one of its main advantages over Trojan or VLESS over TLS. The server borrows the identity of an existing website, so you don't buy a domain, issue a certificate or run a decoy site.
Why won't my sing-box app connect to a REALITY server?
Since Xray v26.9.9, REALITY servers can reject handshakes that lack the post-quantum key share X25519MLKEM768. Upstream sing-box apps up to version 1.14 strip it, so they fail. Use an Xray-based app such as Happ, V2Box, Streisand or v2rayNG, or a recent Hiddify.
Sources
- XTLS/REALITY on GitHub and Xray-core REALITY documentation
- Xray-core v1.8.0 release (REALITY) and v1.6.2 (XTLS Vision)
- v2ray-core v4.27.0 (VLESS)
- Xray-core v25.5.16 (X25519MLKEM768 in REALITY)
- REALITY commit rejecting ClientHellos without X25519MLKEM768 (September 2026)
- VLESS share link format proposal
- Wu et al., "How the Great Firewall of China Detects and Blocks Fully Encrypted Traffic", USENIX Security 2023
- Xue et al., "OpenVPN is Open to VPN Fingerprinting", USENIX Security 2022
- SleekDart server measurements, 10–12 November 2026 (throughput, CPU cost, handshake time, probe test)