V2Ray vs XRAY: 2026 Comparison for Censorship Bypass

**V2Ray:** - Original project by v2fly team - Supports: VMess, VLESS, Trojan, Shadowsocks protocols - Transports: TCP, WebSocket, HTTP/2, gRPC, QUIC - The standard configuration for China bypass: VLESS+TLS+WebSocket on port 443 **XRAY:** - Fork of V2Ray, maintained by XTLS team - Performance improvements: XTLS protocol reduces double-TLS overhead - Adds: Reality transport (most important new feature), Vision flow control - XRAY binaries are often 2-3x faster than V2Ray for XTLS/Reality workloads - Same configuration format as V2Ray (mostly compatible) **Key practical difference:** V2Ray's VLESS+TLS uses a real TLS certificate but a custom protocol - sophisticated DPI can fingerprint the TLS ClientHello and identify it as V2Ray. XRAY's Reality transport borrows the exact TLS ClientHello fingerprint from a real server (microsoft.com, cloudflare.com, etc.). The fingerprint is indistinguishable from a real visit to that site because it IS that fingerprint. GFW cannot block it without blocking the real site.

Reality is XRAY's most important contribution to censorship bypass. Technical details: Reality "steals" the TLS fingerprint from a legitimate website (the "dest" in your config). When the GFW's active probing system connects to your XRAY server, it receives a TLS response with the fingerprint of, say, www.microsoft.com. The GFW probe believes it is talking to Microsoft's infrastructure and passes. When your legitimate XRAY client connects, it presents the agreed private key (publicKey/privateKey pair in config). The server recognizes the actual XRAY connection and processes it. The probe does not have this key, so it gets the "cover" response. This provides two protections: passive DPI (traffic analysis) and active probing (common in China). Standard V2Ray handles passive DPI but is more vulnerable to active probing. Setup on XRAY server: ```bash # Generate Reality keys: xray x25519 # Output example: # Private key: abc123privatekey # Public key: xyz789publickey ``` Use these in the Reality config alongside the dest server (the site whose fingerprint you borrow).

Benchmark data from Anubiz Host Romania VPS: **V2Ray VLESS+WebSocket+TLS:** - Throughput: 200-300 Mbps (double TLS overhead: one from V2Ray, one from website TLS) - CPU: moderate-high - Latency overhead: 8-15ms **XRAY XTLS (Vision flow):** - Throughput: 400-600 Mbps (XTLS eliminates inner TLS layer, passes through outer TLS) - CPU: lower than V2Ray WebSocket+TLS - Latency overhead: 3-7ms **XRAY Reality:** - Throughput: 300-500 Mbps - CPU: moderate - Latency overhead: 5-10ms **XRAY Reality + XTLS Vision:** - Throughput: 500-800 Mbps - CPU: lowest - Latency overhead: 3-6ms XRAY significantly outperforms V2Ray for both throughput and CPU efficiency. For users with fast connections (100+ Mbps), this difference is meaningful. For typical home connections (10-50 Mbps), both provide sufficient throughput.

**For new installations:** Use XRAY. It is more actively maintained, has Reality, is faster, and has identical (or better) feature coverage compared to V2Ray. **Existing V2Ray installations:** Migrate to XRAY. The configuration format is compatible with minor adjustments. The migration is straightforward. **For China:** XRAY Reality is the current gold standard. Shadowsocks with v2ray-plugin (WebSocket+TLS) is a viable alternative if Reality configuration is too complex. **For Iran:** XRAY Reality or V2Ray+VLESS+WebSocket+TLS both work. Iran's DPI is less sophisticated than China's; V2Ray+WebSocket+TLS has worked reliably for years. **For Russia:** WireGuard on 443 UDP or Shadowsocks+obfs are more commonly used and well-supported. XRAY Reality also works. **Client software:** - Windows: v2rayN (supports both V2Ray and XRAY) - Android: v2rayNG - iOS: Shadowrocket (supports Reality), Quantumult X - Linux: XRAY command-line + configuration file