V2Ray Protocol Evolution: Technical Architecture and Security Considerations from VMess to VLESS

Introduction

V2Ray, the core component of Project V, has undergone a significant protocol evolution from VMess to VLESS. While VMess provides built-in encryption and authentication, it suffers from metadata exposure and performance overhead. VLESS, as a lightweight alternative, aims to simplify the handshake process and reduce redundant encryption while maintaining a baseline of security.

VMess Protocol Architecture

VMess employs a timestamp-based authentication mechanism, where the client and server share a UUID as the identity identifier. Its encryption process includes:

• Request Encryption: Payload is encrypted using AES-128-CFB or ChaCha20-Poly1305, with additional one-time authentication data.
• Response Encryption: The server returns encrypted data using dynamic ports or random offsets to complicate traffic analysis.
• Metadata Protection: The request header contains the target address, port, and encryption algorithm identifier, but lacks length padding, potentially leaking traffic patterns.

VMess requires 2 round-trip times (RTT) for handshake, and the encryption algorithm negotiation adds latency. Moreover, its replay protection relies on timestamps, making it vulnerable to time synchronization attacks.

VLESS Protocol Design

VLESS aims to eliminate redundant encryption layers in VMess. Its core design principles include:

• No Built-in Encryption: VLESS does not encrypt the payload by default, relying on the transport layer (e.g., TLS) for confidentiality.
• Simplified Handshake: The client sends a fixed-format request header containing the UUID and instruction; the server validates and establishes the connection in 1 RTT.
• Minimal Metadata: The request header includes only essential fields (e.g., target address) and supports padding to obfuscate traffic length.

VLESS authentication uses HMAC based on UUID, without timestamps, reducing time synchronization dependency. However, since the payload is not encrypted, traffic content is fully exposed if TLS is not used.

Security Comparison and Considerations

| Feature | VMess | VLESS | |---------|-------|-------| | Encryption | Built-in (AES/ChaCha20) | None, relies on TLS | | Handshake RTT | 2 | 1 | | Metadata Protection | Partial (no padding) | Supports padding | | Replay Protection | Timestamp + nonce | No built-in mechanism | | Performance Overhead | Higher (encryption) | Lower (no encryption) |

VLESS offers clear performance advantages, but its security heavily depends on TLS configuration. If TLS is misconfigured (e.g., weak cipher suites or missing certificate validation), VLESS may be more vulnerable than VMess. Additionally, VLESS lacks built-in replay protection, which could be mitigated through application-layer mechanisms or TLS session resumption.

Evolution Trends and Recommendations

The evolution from VMess to VLESS reflects a shift toward the "least privilege" principle: delegating encryption responsibilities to the transport layer to reduce protocol complexity. For high-security scenarios, it is recommended to use VLESS + TLS 1.3 + mTLS with padding enabled. For environments requiring traffic obfuscation, VMess with obfuscation modes or WebSocket transport may be considered.

Conclusion

VLESS outperforms VMess in efficiency and simplicity, but its security is contingent on the external transport layer. Users should choose based on their threat model: if built-in encryption is required and performance overhead is acceptable, VMess remains viable; if efficiency is prioritized and TLS is correctly configured, VLESS is the better choice.