VLESS + Reality + XTLS Vision — How Modern Anti-Censorship Protocols Work

Background: Why Previous Approaches Failed

The Problem With Encryption Alone

Early circumvention tools (Shadowsocks, early V2Ray) focused on encrypting payload content. This failed because the GFW's DPI doesn't need to read your data — it identifies proxy protocols by their handshake structure, timing, and behavioral fingerprint.

Encrypting the payload while keeping a recognizable handshake is like painting your house a different color while the blueprint is publicly known.

The Problem With Mimicking HTTPS

Second-generation tools tried to disguise VPN traffic as HTTPS. This partially worked until the GFW deployed active probing. When the GFW probes a server pretending to be HTTPS:

1. It sends a valid TLS ClientHello to the server
2. The server, running VPN software, responds with a TLS certificate
3. The GFW checks: is this certificate from a real, well-known domain? Does the server behave like a real HTTPS server when accessed with a browser?
4. A VPN server pretending to be HTTPS fails step 4 — it only handles VPN clients, not real browser requests

The GFW developed a behavioral test: does the server serve actual HTTPS content to non-VPN probes?

Enter VLESS

VLESS is a protocol from the Xray-core project. It strips away the session state and encryption overhead of its predecessor (VMess) and focuses on one thing: being a minimal, efficient transport proxy with no identifiable footprint.

VLESS has no native encryption — it relies entirely on the underlying transport (TLS) for security. This is a deliberate design choice: let TLS do encryption (which the GFW cannot break), keep the VLESS overhead minimal.

A VLESS packet structure:

[1 byte]  Protocol version
[16 bytes] User UUID
[1 byte]  Additional info length
[N bytes] Additional info (e.g., flow control type)
[1 byte]  Command (TCP connect = 0x01)
[2 bytes] Target port
[1 byte]  Target address type
[N bytes] Target address
[payload...]

Compared to VMess, VLESS removes the timestamp-based encryption, the command header HMAC, and the response header — reducing detectable structure. The UUID is authenticated by the TLS channel, not by in-protocol cryptography.

The Reality Protocol: Borrowing Someone Else's TLS Identity

Reality is the key innovation that makes modern circumvention robust against active probing. It was designed specifically to defeat the GFW's probe-and-detect system.

The Core Idea

Rather than creating a TLS certificate for your VPN server, Reality borrows the TLS fingerprint from a real, major website. The server presents that website's public certificate as if it were its own.

How is this possible? TLS certificate authentication only requires that the server can prove ownership of the private key corresponding to the certificate's public key. Reality uses a different authentication mechanism: the Xray UUID acts as the authentication credential, and the TLS layer is purely for traffic camouflage.

How Reality Works Step by Step

Server setup:

1. Choose a "server name" to impersonate — e.g., www.microsoft.com
2. Generate an X25519 key pair (Reality-specific)
3. Configure Xray with this key pair and the target server name

Client connection:

1. Client sends TLS ClientHello with SNI = "www.microsoft.com"
   - The ClientHello fingerprint matches real browser behavior (uTLS)
2. Server receives the ClientHello
3. Server checks if the client presents a valid Reality token (derived from shared secret)
4. If valid: server continues with Reality TLS handshake
   → Server uses www.microsoft.com's certificate (obtained live from the real server)
5. If invalid (e.g., GFW probe): server falls through to forwarding the connection 
   → The real www.microsoft.com handles the probe
   → Probe gets a legitimate HTTPS response from Microsoft's CDN
   → GFW cannot distinguish this from a real connection to Microsoft

The critical innovation: when the GFW probes the server, the real Microsoft server responds. The VPN server acts as a transparent proxy for non-authenticated connections.

GFW Probe:                    Legitimate Vexonik Client:
    │                                    │
    ▼                                    ▼
TLS ClientHello              TLS ClientHello
(no Reality token)           (with Reality token embedded)
    │                                    │
    ▼                                    ▼
VPN Server                    VPN Server
    │                                    │
    ▼ (no token = proxy forward)         ▼ (valid token = VPN)
Real Microsoft Server          VLESS Proxy Session
    │
    ▼
Legitimate HTTPS Response
    │
    ▼
GFW: "This is a real Microsoft server. Not a proxy."

The TLS Fingerprint

Even a perfect certificate is useless if the TLS ClientHello looks different from a real browser. The GFW tracks JA3 fingerprints — a hash of specific TLS ClientHello fields that identifies the client software.

Every TLS library has a unique fingerprint. OpenSSL looks different from BoringSSL (Chrome) looks different from NSS (Firefox).

uTLS (the "u" stands for "μ" — micro) solves this by allowing a Go TLS client to mimic the exact ClientHello of specific browser versions:

import utls "github.com/refraction-networking/utls"
 
conn, err := utls.Dial("tcp", serverAddr, &utls.Config{
    ServerName: "www.microsoft.com",
})
 
// Impersonate Chrome 120's exact TLS fingerprint
err = conn.ApplyPreset(&utls.HelloChrome_120)

The resulting ClientHello is indistinguishable from Chrome 120 at the network level — same cipher suites, same extensions, same order, same GREASE values.

XTLS Vision: Eliminating Double Encryption

Standard TLS-over-TLS has a problem: the inner TLS (the actual HTTPS traffic you're accessing) is wrapped in another TLS layer (the VPN tunnel). This double encryption has a recognizable pattern — the packet sizes and entropy differ from normal single-layer HTTPS.

XTLS Vision solves this by a technique called TLS-in-TLS splice:

1. Client and server establish the outer TLS (Reality) tunnel
2. Client connects to, say, https://github.com
3. When the inner TLS handshake completes, XTLS Vision directly passes the inner TLS data through the outer tunnel without re-encrypting

Standard VLESS + TLS:
[Outer TLS envelope] [Inner HTTPS data (encrypted again)]
→ Double encryption → abnormal entropy profile → detectable

XTLS Vision:
[Outer TLS envelope] [Inner HTTPS data (passed through directly)]
→ The traffic looks identical to a TLS proxy serving real HTTPS
→ Same entropy, same packet sizes as normal HTTPS

The result: network traffic that is cryptographically indistinguishable from a legitimate HTTPS reverse proxy serving real HTTPS content.

Xray Configuration

A production-grade VLESS + Reality + XTLS Vision server config:

{
  "inbounds": [{
    "listen": "0.0.0.0",
    "port": 443,
    "protocol": "vless",
    "settings": {
      "clients": [{
        "id": "YOUR-UUID-HERE",
        "flow": "xtls-rprx-vision"
      }],
      "decryption": "none",
      "fallbacks": [{
        "dest": "8080"
      }]
    },
    "streamSettings": {
      "network": "tcp",
      "security": "reality",
      "realitySettings": {
        "show": false,
        "dest": "www.microsoft.com:443",
        "serverNames": ["www.microsoft.com", "microsoft.com"],
        "privateKey": "YOUR-PRIVATE-KEY",
        "shortIds": ["YOUR-SHORT-ID"]
      }
    }
  }],
  "outbounds": [{
    "protocol": "freedom",
    "settings": { "domainStrategy": "UseIPv4" }
  }]
}

The fallbacks.dest: 8080 means unauthenticated connections (probes) hit a local nginx instance that forwards to the real Microsoft server.

Nginx fallback:

server {
    listen 8080;
    server_name _;
    
    location / {
        proxy_pass https://www.microsoft.com;
        proxy_ssl_server_name on;
        proxy_set_header Host www.microsoft.com;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Why This Approach Is Difficult to Block

The GFW cannot block this traffic without:

1. Blocking port 443 to all foreign servers — impossible without crippling international business
2. Blocking specifically www.microsoft.com — politically untenable
3. Developing new detection methods that can distinguish uTLS-impersonated Chrome from real Chrome — computationally intensive, arms-race dynamics

The Reality + XTLS approach essentially weaponizes the GFW's own constraints: it cannot block traffic to major international companies.

Limitations and Current State

No technique is permanent. The GFW is continuously updated. Known limitations:

• Timing attacks: If the GFW observes that a connection to "Microsoft" never sends any legitimate Microsoft-shaped HTTP/2 requests, it may flag it over time
• IP reputation: Even with Reality, a datacenter IP with only VPN connections is eventually correlated and blocked
• Server identity correlation: If thousands of users connect to the same "Microsoft" endpoint from China simultaneously, statistical analysis can identify it

Current best practices for production:

• Rotate server IPs regularly (2-4 week rotation)
• Run multiple nodes with different server names
• Mix legitimate-looking traffic with VPN traffic where possible
• Monitor new GFW papers and security research for emerging detection techniques

The arms race between censorship and circumvention continues. The current state of the art (Reality + XTLS Vision) has held up for longer than previous generations — but it requires staying technically current.