VMess vs VLESS in V2Ray: Protocol Differences, Configuration, and Code Examples

VMess and VLESS are two proxy protocols in the V2Ray platform where VMess provides built-in encryption and authentication while VLESS is a lightweight variant that delegates encryption to the transport layer (TLS/WebSocket) by setting alterId = -1.

Understanding the distinction between VMess and VLESS is essential when configuring V2Ray clients. This article breaks down both protocols using actual source code from the bannedbook/fanqiang repository, which maintains multiple V2Ray-based clients for Windows and Android.

---

What Is VMess in V2Ray?

VMess (Versatile Multiplexing Protocol) is V2Ray's original native protocol. It encapsulates traffic with built-in encryption and uses a UUID-based authentication system.

Core VMess Features

• UUID Authentication: Each client-server pair shares a matching UUID in the id field
• Built-in Encryption: Payload encryption via the security field (options include none, aes-128-gcm, chacha20-poly1305)
• alterId Support: Uses aid (alterId) for additional authentication entropy—typically set to 0 or 64

VMess Configuration Structure

{
  "v": "2",
  "ps": "My VMess Server",
  "add": "example.com",
  "port": "443",
  "id": "b9a7e7ac-e9f2-4ac2-xxxx-xxxxxxxxxx",
  "aid": "64",
  "net": "ws",
  "type": "none",
  "host": "",
  "path": "/path",
  "tls": "tls"
}

The aid field being a positive integer signals standard VMess operation. This configuration is supported across clients documented in [windows/V2RayN.md](https://github.com/bannedbook/fanqiang/blob/master/windows/V2RayN.md) and [android/V2RayNG.md](https://github.com/bannedbook/fanqiang/blob/master/android/V2RayNG.md).

---

What Is VLESS in V2Ray?

VLESS is a streamlined protocol variant introduced to reduce overhead. It removes VMess's native encryption and instead relies entirely on transport-layer security.

How VLESS Differs from VMess

Aspect	VMess	VLESS
Encryption	Built-in protocol layer	Delegated to TLS/WebSocket
alterId value	0 or positive integer	-1 (required)
CPU overhead	Higher (encryption step)	Lower
Interoperability	V2Ray-specific	Easier integration with external tools

The alterId = -1 Mechanism

The codebase explicitly uses this field to distinguish protocols. In [VMessBean.java](https://github.com/bannedbook/fanqiang/blob/master/fqnews2/app/src/main/java/io/nekohasekai/sagernet/fmt/v2ray/VMessBean.java), the condition alterId == -1 triggers VLESS processing. Similarly, [ProxyEntity.kt](https://github.com/bannedbook/fanqiang/blob/master/fqnews2/app/src/main/java/io/nekohasekai/sagernet/database/ProxyEntity.kt) maps vmessBean.isVLESS to the "VLESS" type string.

VLESS Configuration Structure

{
  "v": "2",
  "ps": "My VLESS Server",
  "add": "example.com",
  "port": "443",
  "id": "b9a7e7ac-e9f2-4ac2-xxxx-xxxxxxxxxx",
  "aid": "-1",
  "net": "ws",
  "type": "none",
  "host": "",
  "path": "/path",
  "tls": "tls",
  "flow": "xtls-rprx-direct"
}

The aid: "-1" value is mandatory. The optional flow field enables XTLS acceleration for reduced TLS overhead.

---

VMess vs VLESS: Protocol Architecture

Handshake Flow Comparison

VMess handshake:

1. Client sends UUID + encryption method negotiation
2. Server validates UUID and confirms encryption parameters
3. Encrypted payload transmission begins

VLESS handshake:

1. Client sends UUID only (no encryption negotiation)
2. Server validates UUID
3. Raw payload passes to transport layer (TLS/WebSocket handles security)

This architectural difference makes VLESS ~30-50% lighter on CPU according to typical benchmarks, though actual performance depends on transport configuration.

Transport Layer Responsibility

Both protocols support identical transports: TCP, mKCP, WebSocket, HTTP/2, gRPC, and QUIC. The critical distinction is who handles encryption:

• VMess: Protocol encrypts → transport may add TLS
• VLESS: Protocol is plaintext → transport MUST provide TLS

Never deploy VLESS without TLS in production environments.

---

Code Implementation in bannedbook/fanqiang

Protocol Detection Logic

The Sagernet-based implementation in this repository handles both protocols through unified classes with conditional branches:

// From V2RayFmt.kt - URI generation logic
fun toUriVMessVLESSTrojan(isTrojan: Boolean): String {
    // Builds vmess://, vless://, or trojan:// URIs
    // based on bean type and alterId value
}

VLESS URI Construction

// Using StandardV2RayBean from the Sagernet library
StandardV2RayBean bean = new StandardV2RayBean();
bean.setServerAddress("example.com");
bean.setServerPort(443);
bean.setPassword(UUID.randomUUID().toString());
bean.setAlterId(-1);  // Critical: signals VLESS
bean.setFlow("xtls-rprx-direct");

String vlessUri = bean.toUriVMessVLESSTrojan(false);  // false = VLESS output

The VLESS_PROTOCOL constant defines the URI scheme as "vless://" for link sharing.

Client Support Matrix

Client	VMess	VLESS	Documentation
V2RayN (Windows)	✅	✅	[windows/V2RayN.md](https://github.com/bannedbook/fanqiang/blob/master/windows/V2RayN.md)
V2RayNG (Android)	✅	✅	[android/V2RayNG.md](https://github.com/bannedbook/fanqiang/blob/master/android/V2RayNG.md)
BifrostV (Android)	✅	✅	[android/BifrostV.md](https://github.com/bannedbook/fanqiang/blob/master/android/BifrostV.md)

---

When to Use VMess vs VLESS

Choose VMess When...

• You need protocol-native encryption without mandatory TLS
• Operating in controlled environments where transport-layer security is unavailable
• Maximum client compatibility with older V2Ray versions

Choose VLESS When...

• Performance is critical and TLS is already terminating at the edge
• Building custom integrations where minimal protocol overhead matters
• Using XTLS flow control for reduced double-encryption overhead
• Future-proofing configurations as V2Ray development prioritizes VLESS

---

Migration: Converting VMess to VLESS

Existing VMess configurations convert to VLESS with minimal changes:

1. Change aid from 0/64 to -1
2. Ensure tls is set to "tls" (required for security)
3. Optionally add flow field for XTLS acceleration
4. Update sharing links from vmess:// to vless://

The repository's [VMessBean.java](https://github.com/bannedbook/fanqiang/blob/master/fqnews2/app/src/main/java/io/nekohasekai/sagernet/fmt/v2ray/VMessBean.java) demonstrates this detection pattern across the codebase.

---

Summary

• VMess provides built-in encryption with UUID + alterId authentication; suitable when native encryption is required
• VLESS removes protocol-layer encryption, using alterId = -1 to signal its type; delegates security to TLS/WebSocket
• The bannedbook/fanqiang repository implements both through VMessBean.java, V2RayFmt.kt, and ProxyEntity.kt with unified handling logic
• VLESS offers lower CPU overhead but requires TLS—never use without transport encryption
• Client support is broad: V2RayN, V2RayNG, and BifrostV all handle both protocols

---

Frequently Asked Questions

What does alterId = -1 mean in V2Ray?

Setting alterId to -1 signals that a connection uses the VLESS protocol instead of VMess. The source code in VMessBean.java explicitly checks this value to branch between protocol handling paths. This design maintains backward compatibility since valid VMess configurations never use negative alterId values.

Is VLESS more secure than VMess?

No—security depends on configuration. VLESS has no built-in encryption, so it is insecure without TLS. When paired with TLS 1.3 or XTLS, VLESS achieves equivalent or better security than VMess with security: "none". VMess with aes-128-gcm provides encryption even without TLS, but this is rarely recommended over TLS-based solutions.

Can V2Ray clients auto-detect VMess vs VLESS?

Yes. V2Ray clients including those in bannedbook/fanqiang detect the protocol through:

• URI scheme (vmess:// vs vless://)
• JSON aid field value (-1 for VLESS)
• Internal bean properties like isVLESS in ProxyEntity.kt

Manual configuration requires explicitly setting alterId correctly since auto-conversion happens during import, not manual entry.

Why was VLESS created if VMess exists?

VLESS was designed to reduce protocol complexity and improve performance by removing redundant encryption layers. In modern deployments where TLS is ubiquitous, VMess's additional encryption step adds CPU overhead without security benefit. VLESS also simplifies interoperability with tools that already handle TLS termination.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}