VLESS Protocol Technical Analysis: Design Philosophy of Encryption-Free Proxies and Anti-Censorship in Practice

1. Design Philosophy of VLESS

VLESS (V2Ray Less Encryption) is a transport protocol within the V2Ray project, whose core design philosophy is "encryption-free proxy." Unlike traditional TLS/HTTPS proxies, VLESS does not provide transport-layer encryption by default, shifting the encryption responsibility to upper-layer applications or external tunnels (such as XTLS). This design aims to reduce handshake latency and CPU overhead, making it particularly suitable for performance-sensitive scenarios.

1.1 Advantages and Risks of No Encryption

• Advantages: Handshake requires only 1-RTT (or even 0-RTT), significantly reducing latency; no encryption computation, low CPU usage; minimal protocol header, reducing bandwidth waste.
• Risks: Plaintext transmission may be sniffed or tampered with by middlemen, so VLESS is typically used with TLS or XTLS, or deployed in trusted private networks.

1.2 Comparison with VMess

VMess is V2Ray's encrypted protocol, with built-in authentication and encryption, but has higher handshake latency (2-RTT). VLESS achieves faster connection establishment by removing the encryption layer but relies on external encryption mechanisms to ensure security.

2. Technical Architecture and Core Features

VLESS is based on TCP or mKCP (an improved version of KCP) transport, supporting various flow control and camouflage methods.

2.1 Protocol Header Structure

VLESS request header contains only version number, user ID (UUID), encryption method (usually none), and target address. The response header is even simpler, containing only protocol version and status code. This minimalist design makes protocol parsing extremely fast.

2.2 Traffic Camouflage and Obfuscation

• TLS Camouflage: VLESS is often combined with TLS to disguise proxy traffic as HTTPS traffic, bypassing Deep Packet Inspection (DPI).
• WebSocket + CDN: VLESS traffic is transmitted over WebSocket and routed through a CDN (e.g., Cloudflare), leveraging CDN's IP whitelist and traffic distribution to hide the real server.
• mKCP: A reliable UDP protocol based on KCP, optimizing transmission efficiency in packet loss environments, but may be subject to QoS throttling.

3. Anti-Censorship Deployment in Practice

3.1 Basic Deployment Scheme

1. VLESS + TLS + WebSocket + CDN: This is the most popular anti-censorship combination. The client encapsulates VLESS traffic in WebSocket, then encrypts it with TLS, and finally forwards it through CDN to the server. The CDN's IP pool makes blocking much harder.
2. VLESS + XTLS: XTLS (eXtended TLS) is an enhanced version of VLESS that uses TLS session reuse and direct stream proxy to further reduce handshake count and CPU overhead.

3.2 Performance Optimization Tips

• Use BBR or Hybla congestion control algorithms to optimize TCP performance.
• Enable Mux multiplexing to reduce connection establishment times.
• Choose CDN nodes with lower latency (e.g., Cloudflare's preferred IPs).

3.3 Precautions

• VLESS itself does not provide encryption; always pair it with TLS or XTLS, otherwise traffic may be identified.
• Regularly change UUID and port to avoid long-term tracking with the same identifier.
• In highly censored environments, consider secondary camouflage with Trojan or Shadowsocks traffic characteristics.

4. Conclusion

VLESS achieves extreme performance through its encryption-free design, but security depends on external encryption layers. In anti-censorship practice, the VLESS+TLS+CDN combination is currently one of the most effective solutions. With the maturation of XTLS, VLESS is expected to provide stronger security guarantees while maintaining low latency.