How VLESS Reality makes VPN traffic invisible to censors

Every VPN protocol has a fingerprint. WireGuard's handshake initiation is always exactly 148 bytes with a fixed structure. OpenVPN's control channel has timing patterns that are obvious under analysis. Even Shadowsocks, designed specifically for censorship resistance, produces traffic with measurably high entropy that DPI systems can flag as "not normal HTTPS."

Encryption protects content. It does nothing to hide the fact that you're using a VPN.

VLESS Reality, released in Xray-core v1.8.0 in early 2023, takes a completely different approach. Instead of encrypting traffic and hoping censors can't identify the wrapper, it makes VPN connections look identical to ordinary HTTPS browsing. Not similar. Identical. The TLS certificate your connection presents is real, issued by a real certificate authority, for a real website.

Here's how that works, why it's hard to block, and what you give up to get it.

The detection problem

A deep packet inspection system doesn't need to decrypt your traffic to know what protocol you're running. It just needs to recognize patterns.

WireGuard is the easiest example. The handshake initiation message starts with a 1-byte type field, 3 bytes of reserved zeros, a 4-byte sender index, then a 32-byte unencrypted ephemeral key. This structure never changes. Russia's TSPU (Technical Systems for Countering Threats) can detect WireGuard with near-100% accuracy by matching this pattern on the first packet.

OpenVPN is slightly harder to detect but not by much. Its TLS handshake has distinctive timing and its control channel uses a recognizable framing format. China's Great Firewall has been blocking it reliably for years.

The harder problem is entropy analysis. Fully encrypted traffic (random bytes with no recognizable structure) actually looks suspicious. Normal HTTPS traffic has a specific statistical profile: a TLS handshake with predictable certificate chains, followed by encrypted application data with characteristic record sizes. A Shadowsocks connection is a stream of high-entropy bytes from the first packet. To a statistical classifier, that difference is obvious.

This is the fundamental challenge. Encryption makes your data unreadable, but the traffic itself still has a shape. Censors don't need to read your data. They just need to recognize that shape.

Why traditional obfuscation fails

Before Reality existed, the censorship-resistance community tried several traffic-obfuscation approaches to this problem.

obfs4 wraps traffic in a layer designed to look like random noise. It worked for a while. Then China and Iran deployed classifiers that flag high-entropy streams that don't match any known protocol. If traffic doesn't look like HTTP, HTTPS, DNS, or another common protocol, it gets blocked or throttled. Random noise is actually quite distinctive when everything around it is structured.

Shadowsocks had the same entropy problem. AEAD variants improved things, but the fundamental issue remained: the traffic doesn't look like anything legitimate. Chinese DPI systems began blocking Shadowsocks connections by detecting the absence of a standard TLS handshake combined with high-entropy payloads.

Domain fronting (sending traffic to one domain via a CDN that routes it to another) worked well until Google, Amazon, and Cloudflare all shut it down between 2018 and 2020. It relied on CDN providers tolerating the practice. They stopped.

Trojan was an improvement. It mimics HTTPS by actually performing a TLS handshake and serving a real website to unauthorized connections. But Trojan uses a self-configured TLS certificate, which means the certificate chain is different from what a real website would present. An active prober that compares your server's certificate against known certificate transparency logs can spot the discrepancy.

The pattern across all these tools: they try to approximate normal traffic without actually being normal traffic. Given enough analysis, the approximation always breaks down.

RPRX (the creator of the XTLS project) summarized the problem clearly: SNI whitelist censorship had made all TLS-based circumvention tools before Reality unavailable in certain areas overnight. If a censor decides to only allow connections to known, legitimate TLS servers, any tool using its own certificate is dead.

How Reality actually works

Reality doesn't approximate a TLS handshake. It performs a real one.

Here's the connection flow, step by step:

Step 1: Client sends ClientHello. Your client initiates a TLS 1.3 handshake. The Server Name Indication (SNI) field contains the hostname of a real, popular website, like www.microsoft.com. The client uses the uTLS library to copy the exact TLS fingerprint of a real browser (Chrome 120, Firefox, Safari, whatever you configure). The ClientHello is byte-for-byte identical to what that browser would send.

Step 2: Server receives the ClientHello. The Reality server checks for a pre-shared shortId and validates the client using X25519 key agreement. This authentication happens within fields that are opaque to any observer, hidden in the TLS handshake's key share extension.

Step 3: Server contacts the real camouflage site. The Reality server opens its own TLS connection to the actual www.microsoft.com (or whatever domain you've configured as the camouflage target). It performs a legitimate TLS handshake with Microsoft's servers.

Step 4: Server forwards the real certificate. The certificate chain that Microsoft returns gets forwarded back to your client. This is a real certificate, signed by a real CA, for a real domain. There's nothing to detect because there's nothing fake.

Step 5: Authenticated clients get tunneled. If the client passed the shortId and X25519 authentication in step 2, the server establishes the VLESS tunnel. VPN traffic flows inside what looks like a normal HTTPS session with microsoft.com.

Step 6: Unauthenticated connections get forwarded. If someone (a censor's active prober, a researcher, anyone) connects without valid credentials, the server transparently proxies their connection to the real microsoft.com. They see real content. Real headers. Real behavior. There's nothing to distinguish the server from a legitimate reverse proxy.

This is the key difference from every previous approach. The certificate is real. The website behind it is real. The TLS fingerprint matches a real browser. There is no detectable lie in the entire chain.

Active probing resistance

Censors don't just analyze traffic passively. They actively probe suspicious servers.

China's Great Firewall has been doing this since at least 2012. When it detects a connection that might be a proxy, it replays the client's handshake or sends its own probe to the server. If the server responds in a way that differs from a legitimate service, it gets blocked.

This is how Trojan servers eventually get detected. A prober connects, doesn't authenticate, and the server returns a generic web page. But the TLS certificate doesn't match what certificate transparency logs say that domain should have. Or the HTTP response headers are subtly different from a real deployment of that web server software. Small inconsistencies, but enough.

Reality defeats active probing completely. When a prober connects to a Reality server without valid credentials, they get forwarded to the real camouflage site. The response isn't a simulation. It IS microsoft.com, served through a transparent proxy. Same certificate. Same headers. Same behavior. Same content.

A censor would need to distinguish between "a user visiting microsoft.com" and "a Reality server proxying to microsoft.com." From the outside, these are identical. The TLS session looks the same. The HTTP responses are the same. The IP address is the only thing that's different, and an IP address hosting a reverse proxy to microsoft.com isn't inherently suspicious.

Vision flow and TLS-in-TLS

There's a subtler detection vector that Reality also addresses. When you run a VPN inside a TLS tunnel, the encrypted VPN traffic contains its own TLS handshakes (every HTTPS website you visit generates one). This creates a TLS-in-TLS pattern: TLS records containing what are clearly more TLS records, visible through traffic analysis even though the content is encrypted.

The XTLS Vision flow (xtls-rprx-vision) eliminates this. Instead of double-encrypting TLS traffic, Vision detects when the inner payload is already TLS-protected and passes it through with minimal wrapping. The outer TLS layer handles authentication and framing; the inner TLS data flows without redundant encryption.

A USENIX paper confirmed that Vision achieved its design goals. The traffic pattern of a VLESS+Vision connection is statistically indistinguishable from a direct HTTPS connection to the camouflage site.

This matters because traffic analysis (looking at packet sizes, timing, and patterns without decrypting anything) is the most plausible remaining attack against Reality. Vision closes that gap.

What makes it hard to block

To block VLESS Reality, a censor would need to do one of the following:

Block the camouflage domain entirely. If Reality is configured to impersonate microsoft.com, the censor would need to block microsoft.com. Or google.com. Or whatever other domain operators choose. Blocking major cloud and productivity services has enormous economic costs. China has accepted that cost for some services, but even China hasn't blocked microsoft.com.

Detect the X25519 authentication in the TLS handshake. This information is carried in the key share extension, which is encrypted in TLS 1.3. Without breaking the TLS handshake itself, the authentication is invisible.

Identify Reality servers by IP reputation. This is actually the most effective approach censors have found so far. Russia's TSPU has started flagging VPS IP addresses that receive connections matching certain behavioral patterns: connections from residential IPs to VPS IPs that also proxy to well-known sites. This isn't detecting Reality itself. It's detecting the infrastructure patterns around it. The detection rate for properly configured VLESS Reality is still below 5% based on community reports from February 2026.

Traffic timing analysis. VPN traffic has different timing characteristics than normal web browsing. A user streaming video through Reality generates sustained, high-throughput flows that don't match typical HTTPS browsing patterns to microsoft.com. This is a real weakness, though it requires sophisticated analysis and produces many false positives.

Iran has been investigating Reality blocking (discussed in GitHub issue #3269 on the Xray-core repository). So far, no reliable detection method has been deployed. Russia's approach of IP reputation scoring is the most successful, but it catches a small fraction of connections and requires constant manual tuning.

The tradeoffs

We run VLESS Reality in production at Fexyn, alongside WireGuard and OpenVPN. We're not going to pretend it's a free lunch. There are real costs.

Latency. A Reality connection adds roughly 100ms of latency compared to WireGuard. The extra TLS handshake with the camouflage site, the X25519 authentication, and the proxying layer all take time. For general browsing, this is barely noticeable. For gaming or real-time voice, you'll feel it.

TCP overhead. VLESS Reality runs over TCP. WireGuard runs over UDP. TCP has head-of-line blocking: if one packet is lost, everything behind it waits. On lossy networks (mobile connections, congested Wi-Fi), this means periodic stalls that UDP-based protocols avoid. The XHTTP transport mode helps by multiplexing, but the fundamental TCP limitation remains.

Configuration complexity. WireGuard needs a key pair and an endpoint. Reality needs a camouflage domain, a shortId, an X25519 key pair, a uTLS fingerprint selection, a transport configuration, and careful testing to make sure the camouflage site works correctly. We handle this automatically in Fexyn (the client receives a complete configuration from our API), but self-hosters have more to manage.

Debugging difficulty. When a WireGuard connection fails, the failure modes are straightforward: wrong key, wrong endpoint, port blocked. When a Reality connection fails, it could be the camouflage domain, the shortId, the key pair, the uTLS fingerprint, the transport layer, the camouflage site being unreachable from the server, or half a dozen other things. We've spent significant debugging time on Reality connections that turned out to be camouflage domain issues.

Not all camouflage domains work equally well. The camouflage site needs to support TLS 1.3, have a certificate that chains to a trusted CA, and be reachable from your server. Some domains work perfectly. Others have quirks that cause subtle failures. We've tested extensively and settled on a set of reliable camouflage targets, but this required real trial-and-error work.

Real-world detection rates

Based on community reporting and our own testing:

Country	WireGuard	OpenVPN	VLESS Reality
Russia (TSPU)	Blocked instantly	Blocked/throttled	~95% success
China (GFW)	Blocked	Blocked	Works, periodic IP blocks
Iran	Blocked	Intermittent	Works, under active research
Turkmenistan	Blocked	Blocked	Limited data, reported working

The ~5% failure rate in Russia comes primarily from IP reputation scoring, not protocol detection. Using residential-looking IP ranges or cloud providers that aren't on blacklists brings the success rate close to 100%.

In China, the main threat is IP-based blocking rather than protocol detection. The GFW maintains lists of known VPS IP ranges and periodically blocks them. Reality connections from clean IPs work consistently.

When to use it

If you're in a country without active censorship, WireGuard is the better choice. It's faster, simpler, and uses UDP. There's no reason to accept Reality's tradeoffs if nobody is trying to block your connection.

If you're in or traveling to a country with active DPI (Russia, China, Iran, UAE, many others), VLESS Reality with the Vision flow is the protocol that actually works. WireGuard will be blocked before you finish the handshake.

Fexyn supports both, with automatic protocol rotation that switches to VLESS Reality when WireGuard is blocked. You get WireGuard's speed when it's available and Reality's censorship resistance when you need it.

If you want to understand more about the VLESS protocol itself (separate from the Reality transport), we wrote a detailed breakdown of VLESS that covers the protocol's architecture and how it compares to alternatives.

Try Fexyn free for 7 days — Stealth (VLESS Reality with Vision flow) is included on every plan. Activists and movement organisers may want the VPN for activists page for the threat-model framing.