Reality is not a VPN protocol. It is an authentication and camouflage layer that makes VPN connections look like legitimate HTTPS traffic. Developed by XTLS (the team behind Xray-core), Reality represents the most sophisticated approach to GFW evasion currently available. Here is how it works at a technical level.

The Problem Reality Solves

Traditional VPN protocols (OpenVPN, WireGuard, Shadowsocks) encrypt traffic but do not disguise it. The encrypted traffic has distinctive patterns -- packet sizes, timing, handshake sequences -- that deep packet inspection can identify. Even "stealth" protocols that add obfuscation layers still differ from legitimate HTTPS in detectable ways.

Trojan-Go took the next step by mimicking HTTPS, but it uses its own TLS certificates. The GFW can detect that the certificate is self-signed or does not match the claimed domain, especially during active probing.

Reality solves both problems: it mimics HTTPS traffic AND uses the real target website's TLS certificate.

How TLS Mimicry Works

Step 1: Client Hello Spoofing

When your VPN client connects, it sends a TLS Client Hello message that is identical to what a real Chrome browser would send when connecting to microsoft.com. The uTLS library replicates exact browser fingerprints, including:

  • Cipher suite ordering
  • TLS extensions and their order
  • Supported groups and key shares
  • ALPN protocols
  • Signature algorithms

DPI systems that fingerprint TLS Client Hello messages see a genuine Chrome-to-Microsoft connection.

Step 2: Server Name Indication

The SNI field in the Client Hello contains "microsoft.com" (or whatever target domain is configured). This is the unencrypted domain name that DPI systems can read. Since it shows a legitimate domain, the connection appears normal.

Step 3: Authentication via Session ID

Here is where Reality gets clever. The client authenticates itself to the server using data embedded in the TLS session ID field. The session ID contains an ECDH shared secret derived from the client's private key and the server's public key. This authentication is invisible to external observers because the session ID field is opaque in the TLS specification -- it can contain any data.

Step 4: Server Certificate Forwarding

The Reality server does not use its own TLS certificate. Instead, it initiates a real TLS connection to the target website (microsoft.com) and forwards that site's real certificate to the client. The client sees Microsoft's genuine certificate, and so does any DPI system inspecting the connection.

Step 5: Anti-Probe Forwarding

If a connection arrives that does not carry valid authentication (like a GFW active probe), the Reality server transparently proxies the entire connection to the real target website. The probe receives an authentic HTTPS response from microsoft.com. There is no way for the probe to distinguish the Reality server from a legitimate reverse proxy to Microsoft.

Why This Is Difficult to Detect

To detect Reality, the GFW would need to:

  1. Distinguish Reality's Client Hello from a real Chrome Client Hello (identical by design)
  2. Detect that the session ID contains authentication data (session IDs are opaque by specification)
  3. Determine that the server certificate was forwarded rather than served directly (the certificate chain is identical)
  4. Identify statistical differences in traffic patterns (Vision flow control normalizes these)

Each of these is either architecturally impossible or requires deep behavioral analysis that has not been demonstrated at scale.

Comparison with Other Stealth Approaches

  • Shadowsocks: Encrypted traffic with no mimicry. Detectable via entropy analysis and traffic patterns.
  • Trojan: Mimics HTTPS but uses custom certificates. Detectable via certificate validation during probing.
  • V2Ray WebSocket: Wraps traffic in WebSocket, but the WebSocket endpoint behavior differs from real web services.
  • Reality: Mimics HTTPS with real certificates, real SNI, real probe responses. Indistinguishable from legitimate traffic.

Technical note: Reality requires careful server configuration. The target domain (SNI) must resolve to an IP on the same ISP/hosting provider as the VPN server. The target must support TLS 1.3 and have a short TLS handshake. microsoft.com, apple.com, and similar large CDN-backed domains work well. KookVPN handles all this configuration automatically -- see how it works.

Related Articles