VMess vs VLESS: Four Differences Regular Users Should Know

Authentication: same UUID, but VMess adds an alterId

Both protocols identify users with a UUID. The server hard-codes a UUID in the clients array, and the id in the client config must match it character for character — one character off and authentication fails. On this point alone, VMess and VLESS are no different.

The difference comes from the alterId field that early VMess versions added. It derives a set of temporary identifiers from the UUID and, together with a timestamp, resists replay attacks; the old default was 64. The cost is that the client and server clocks must stay within 90 seconds of each other, so system clock drift or cross-time-zone use often breaks the connection.

V2Ray v4.35, released in January 2022, marked alterId as deprecated, and v5 removed the field entirely. In v2rayN 6.x, a newly created VMess node now defaults to alterId 0, uses AEAD authentication, and no longer checks timestamps. As long as both ends use 0, this difference is effectively gone.

VLESS never had alterId by design: replay protection is left to the transport layer, the server keeps no session state, and the protocol header is shorter. So the first point boils down to one sentence: in current versions both are equally simple, and only legacy nodes with a non-zero alterId call for extra attention to clock sync.

Transport dependency: VLESS adds no second encryption layer

The VMess protocol has its own encryption layer. Even without TLS, VMess traffic is encrypted, and the security field in the config accepts auto, aes-128-gcm, chacha20-poly1305, or none. That lets it run over plain TCP or pair with transports such as mKCP that don't depend on TLS.

VLESS is the opposite: the protocol itself only authenticates and forwards, encrypting not a single byte, and the config always reads "encryption": "none", leaving the payload in plaintext for the transport layer. VLESS over plain TCP is unencrypted traffic, so a real deployment must wrap it in TLS, XTLS, or REALITY.

{
  "outbounds": [{
    "protocol": "vless",
    "settings": {
      "vnext": [{
        "address": "node.example.com",
        "port": 443,
        "users": [{
          "id": "b831381d-6324-4d53-ad4f-8cda48b30811",
          "encryption": "none",
          "flow": "xtls-rprx-vision"
        }]
      }]
    },
    "streamSettings": {
      "network": "tcp",
      "security": "reality"
    }
  }] // VLESS outbound: encryption handled by the REALITY transport layer
}

There are three common VLESS deployment combinations:

• VLESS + TCP + TLS: port 443, the simplest setup, requires your own domain and certificate
• VLESS + XTLS Vision + REALITY: supported by the Xray core, no domain or certificate of your own required
• VLESS + WebSocket + TLS: used when relaying through a CDN, with the same structure as the equivalent VMess combination

REALITY and XTLS Vision are currently implemented only for VLESS, not VMess. If node details show flow: xtls-rprx-vision or security: reality, the node is definitely VLESS.

Encryption overhead: one layer vs. two in practice

It's clearer to express the difference as CPU overhead: VMess over TLS encrypts twice — once for the outer TLS layer and once inside the protocol — while VLESS encrypts only once, in the outer TLS layer. Every encryption pass costs CPU cycles, and the gap grows with the number of connections.

On which devices does this difference show up? On a desktop with a modern processor it's basically unmeasurable; on a single-core budget server, an older phone, or a router, the layer VLESS saves shows up in connection counts and throughput.

Client compatibility: the core version decides whether VLESS works

Whether VLESS works depends on the core version bundled with the client. v2rayN 6.x uses the Xray core by default and supports the full VMess and VLESS range; v2rayNG is likewise built on the Xray core; v2flyNG uses the v2fly core, which supports VLESS from v4.27 onward but not REALITY.

The version number is a hard requirement. V2Ray core v4.26 and earlier don't recognize vless:// links, so a subscription containing VLESS nodes fails to import outright. To check: in the v2rayN main window, go to Settings → Parameter settings → Core: Basic settings; an Xray core shows version 1.x, a v2fly core 4.x or 5.x.

The share-link prefix also tells them apart: vmess:// is followed by base64-encoded JSON, while vless:// uses a URI query string of the form vless://uuid@address:port?params#remark. Both link types can coexist in one subscription; the client parses each by its prefix, and the node list simply gains a few more entries.

When it matters

Putting the four comparison points into everyday practice, only three situations really call for caring about protocol differences.

The other two cases are more clear-cut: when hardware is tight, prefer VLESS for its one less encryption layer; when you need CDN relay or compatibility with older clients, VMess + WebSocket + TLS fits more situations.

A protocol is an agreement between server and client, not a switch you can flip at will. Understanding these four differences is enough for everyday node use and connection troubleshooting.