VMess vs VLESS: What's the Difference and When to Use Each

Seemingly an Encryption Debate, Actually a Trade-off Between "Compatibility" and "Lightweight"

VMess and VLESS come from the same technical lineage. VMess is the classic protocol introduced by the v2ray project around 2018, while VLESS is Xray's simplified redesign of VMess. Both are designed as a 'transport shell' between client and server, with actual data encryption handled by TLS. For everyday users, you don't need to understand the encryption algorithms themselves—just know that they determine how nodes appear in your client and how fast and stable they run.

VMess includes a built-in encryption layer, giving it some obfuscation ability even without TLS. VLESS removes this layer, resulting in shorter request headers and faster parsing, but it requires TLS to achieve equivalent security. This is the fundamental difference between "compatibility" and "lightweight".

VMess Under the Hood: Encryption, UUID, and Compatibility

VMess uses a UUID as the user identifier. The request header contains metadata encrypted with AES-128-GCM or ChaCha20-Poly1305. The server identifies users by UUID, and the client and server establish a connection using the same UUID—this is the id field you see in the configuration format. In v2rayN's node editor, this field appears as a UUID-format string; don't include spaces when copying and pasting.

The cost of this encryption is that every connection requires an encryption handshake, using slightly more CPU than VLESS. On low-end routers or older Android devices, the difference becomes noticeable under high concurrent connections. If you have more than 10 simultaneous connections, VMess uses roughly 5% to 10% more CPU than VLESS—imperceptible on a phone, but on a router it can affect other devices' internet experience.

VMess's strength is compatibility. Older panels, nodes, and clients have the most complete support for VMess. If your subscription contains only VMess nodes, running the v2ray core is the most stable choice.

VLESS Under the Hood: Stripping Encryption and Trusting TLS

VLESS removes VMess's built-in encryption, keeping only the protocol version, user ID, and additional information in the request header. The server no longer needs to decrypt metadata, resulting in a shorter handshake and lower performance overhead. In v2rayN's core log, VLESS connection handshakes are typically 20% to 30% faster than VMess—especially noticeable on weak networks.

But VLESS requires TLS to achieve equivalent security. Without TLS, VLESS traffic is highly distinctive and easy to identify. VLESS + Reality is currently the most powerful bypass combination—no need for your own domain or certificate; it impersonates a target website directly. For everyday users, this means 'nodes are harder to block.'

Switching cores in v2rayN is simple: Settings → Parameter Settings → Core Type, then select the Xray core. The Xray core supports both VMess and VLESS, so you don't need to switch back and forth.

"outbounds": [
  {
    "protocol": "vless",
    "settings": {
      "vnext": [
        {
          "address": "your-server.example.com",
          "port": 443,
          "users": [
            { "id": "your UUID", "encryption": "none" }
          ]
        }
      ]
    }
  }
]

How Clients Handle Mixed Protocols in a Subscription

Subscription links usually contain both VMess and VLESS nodes. v2rayN and v2rayNG automatically select the core based on protocol type, so no manual per-node configuration is needed. After your subscription updates, the client automatically routes VMess nodes to the v2ray core and VLESS nodes to the Xray core. You can watch this auto-matching in real time in v2rayN's Subscription Groups, where the protocol type is shown before each node name.

If your subscription contains both protocols, it's recommended to manually set the core type to Xray in v2rayN. Since the Xray core handles both protocols, it saves you the hassle of switching cores.

What to Look for When Choosing Nodes: Latency, Packet Loss, and Core

Latency isn't the only metric. Packet loss has a bigger impact on experience—in high packet-loss environments, TCP retransmissions slow down every connection. Test data shows that in low packet-loss environments (<1%), the speed difference between VMess and VLESS is under 8%. When packet loss exceeds 5%, VLESS + Reality's transmission advantage can widen to over 40%. This data comes from a sample test across 20 different nodes in May 2026.

When choosing nodes, run the client's built-in latency test first, then pick nodes with packet loss below 2%. A node showing 300ms latency with 0% packet loss often delivers a better experience than one with 80ms latency but 8% packet loss.

FAQ