VMess vs. VLESS: UUID, alterId, and Encryption Explained

VMess vs. VLESS: Understanding Protocol, Transport, and Security Layers

“VMess + WebSocket + TLS” in a node name does not mean three protocols at the same level. VMess handles proxy authentication and data encapsulation, WebSocket is the transport, and TLS secures the outer connection. The same three layers apply to VLESS. Simply changing VMess to VLESS in the editor while leaving everything else untouched won’t make the server accept the connection.

The table covers common VMess AEAD and traditional VLESS configurations with encryption: "none". Newer cores may support additional fields or features. Always follow the complete settings provided by the server and check compatibility with both cores.

UUID and alterId: Authentication Credentials Aren’t Encryption Strength

A UUID is a common format for representing a user ID, for example 9d34742b-7f0c-4ca6-9f51-bb35d8a6d127. It typically consists of hexadecimal characters and hyphens, totaling 36 characters in the standard format. The server identifies a connection using its configured user record, and the client must provide the matching ID. A UUID is neither a server address nor a TLS certificate.

In Chinese-language interfaces, alterId is often called an “extra ID.” It comes from an earlier VMess authentication design; it does not mean “create extra accounts,” and a higher value does not make a connection more secure. Modern VMess deployments typically use AEAD and set 0. Some newer cores no longer accept the legacy authentication method. If an older guide says to use 64, check the server’s authentication mode with your provider rather than treating it as a universal recommendation.

• For a new VMess node: Keep the ID and authentication settings supplied with the subscription, and first confirm whether it uses AEAD.
• For a VLESS node: Enter its user ID without adding alterId, and check the associated TLS or REALITY settings.
• When generating a UUID yourself: Update both the server and the client. Changing only the client will cause authentication to fail.
• When asking for help: Hide the full ID, subscription URL, and share link. These may grant direct access to the node.

Both protocols displaying a UUID does not mean the same UUID works across protocols. Even if the server is configured with the same string, VMess and VLESS use different message formats and must connect to the corresponding inbound port and protocol.

Choosing Encryption: security, encryption, and TLS Belong to Different Layers

“VLESS encryption is set to none—is that plaintext?” It depends on the full connection stack. In a traditional VLESS configuration, encryption: "none" means the protocol layer does not add payload encryption. If the outer layer uses correctly configured TLS or REALITY, the connection between the client and the corresponding server is still encrypted. Without an outer security layer, VLESS itself should not be treated as a private channel.

VMess user settings may include values such as security: "auto", aes-128-gcm, or chacha20-poly1305. The security field here is not the same as streamSettings.security: the former belongs to VMess user settings, while the latter describes transport security. The examples below show where these fields go; they are not complete, ready-to-connect configurations.

{
  "protocol": "vmess",
  "settings": {
    "vnext": [
      {
        "address": "example.net",
        "port": 443,
        "users": [
          {
            "id": "9d34742b-7f0c-4ca6-9f51-bb35d8a6d127",
            "alterId": 0,
            "security": "auto"
          }
        ]
      }
    ]
  },
  "streamSettings": {
    "network": "ws",
    "security": "tls",
    "tlsSettings": {
      "serverName": "example.net"
    },
    "wsSettings": {
      "path": "/proxy"
    }
  }
}

The corresponding VLESS user object is commonly written as "encryption": "none". Add "flow": "xtls-rprx-vision" only if the server explicitly uses Vision and the transport combination and core support it. Standard VLESS + WebSocket + TLS nodes generally do not need this flow; don’t enable it just because the option appears in the interface.

1. Start by checking the outer security type specified for the node: TLS, REALITY, or no security layer.
2. For TLS, check serverName, the certificate domain, and the validation result. Don’t treat skipping certificate verification as a routine fix.
3. For REALITY, check the required server public key, shortId, serverName, and fingerprint. These fields are not interchangeable.
4. Finally, check protocol-specific fields: VMess security, or VLESS encryption and optional flow.

Choosing a Client and Core: Match Node Capabilities, Not Names

v2rayN is a desktop client whose GUI manages nodes, subscriptions, and the system proxy; the selected core handles the actual protocol connection. On Android, v2rayNG uses the Xray core, while v2flyNG uses the V2Fly core. Similar client names don’t mean every version supports the same transports or extensions.

There’s no need to rebuild a stable VMess subscription just to switch protocols. If the same provider offers both VMess and VLESS, keep the server region, test target, and test time consistent, then compare connection success rates and download performance. Speed differences between exit nodes don’t prove that one protocol is faster.

Checking a Node in v2rayN: From Import to Verifying Proxy Traffic

Import the provider’s complete share link or subscription instead of copying settings from a screenshot. The vmess:// and vless:// prefixes indicate different protocols; replacing the prefix does not convert the data that follows. Subscription updates may also overwrite manual changes. When troubleshooting, duplicate the node first so test settings stay separate from the original.

1. Import the node: Copy the complete share link, then in v2rayN choose “Servers” → “Import batch URLs from clipboard.” Menu labels may vary by version; use the equivalent import command in your current interface.
2. Check the key settings: Double-click the imported node and verify the protocol, address, port, and user ID, then check the transport and TLS or REALITY settings. For VMess, check the alterId; for VLESS, check the flow.
3. Confirm the active node: Save it and set it as the active server. Check the core logs for unsupported fields, port conflicts, or startup errors.
4. Check the local proxy endpoint: In “Settings” → “Parameter Settings,” check the actual listening port. For example, the local SOCKS endpoint might be 127.0.0.1:10808, but use the value shown in your interface—not a port copied from another device.
5. Send a new request: Enable the system proxy or configure the app’s proxy settings for your setup, then open a test site. Existing connections may not switch immediately when you change nodes; close and reopen the app if needed.

A successful TCPing only means the target TCP port responds to a connection attempt. It does not confirm that the UUID, TLS, flow, or proxy exit is correct. If the port responds but the actual connection fails, check authentication and handshake logs first. If the core connects but only some sites fail, check DNS and routing instead of randomly changing the UUID.

Common Issues: Identify the Failing Layer Before Changing Settings

The selection process comes down to this: first meet the server’s protocol and core requirements, then match all authentication and transport settings, and finally compare real-world request performance. For most users, keeping an original subscription that can be traced back and changing only verified settings is more useful than memorizing which protocol is “newer.”