VMess vs VLESS: Encryption, Performance, and Client Compatibility

At a glance

VMess and VLESS are proxy protocols, not client names. Their main differences lie in protocol-level encryption, authentication, and supported security layers—not in whether a node is labeled “high speed.” This guide compares common VMess AEAD and VLESS encryption=none configurations, covering TLS, REALITY, Vision, and core requirements. It also shows how to identify node fields in v2rayN. Useful if you already have a subscription and need to check configuration compatibility or migrate an older VMess node.

VMess vs VLESS: Know the Protocol, Transport, and Security Layer

A node typically combines three sets of settings: VMess or VLESS specifies the proxy protocol, TCP or WebSocket specifies the transport, and TLS or REALITY specifies how the connection is protected. These are not interchangeable options. For example, “VLESS + WebSocket + TLS” and “VLESS + TCP + REALITY” both use VLESS, but they require different client settings.

Setting	VMess	VLESS
Identity field	Usually a UUID; modern configurations use AEAD authentication	Usually a UUID; common basic configurations do not encrypt the payload themselves
Protocol-level encryption	Supports AES-128-GCM, ChaCha20-Poly1305, and others, depending on the core and settings	Commonly set to encryption=none, with TLS or REALITY providing connection protection
TLS relationship	Can be combined with TLS; built-in encryption is not the same as TLS	Common deployments rely on TLS or REALITY to protect the connection
alterId	Legacy compatibility field; typically 0 in modern AEAD configurations	No such field
Vision and REALITY	VLESS Vision configurations cannot be applied directly to VMess	Requires a supported Xray version and transport combination
What to consider	Whether the existing server and client are reliably compatible	Whether the server settings, core capabilities, and security layer all match

Here, VLESS refers to the common encryption=none configuration found in subscriptions. Some newer Xray versions may also offer extended encryption capabilities, so it is not accurate to say that all VLESS configurations can never encrypt traffic. If you encounter a different encryption value, check the versions and documentation for both endpoints; do not change it to none on your own.

How to identify a node: check its fields, not its label

Node labels can say anything. First confirm the protocol in the edit window, then check the transport and TLS/REALITY settings, and finally review Flow. Compare speeds only after all three layers match.

Encryption and alterId: VMess AEAD is not outer TLS

VMess can encrypt payloads at the protocol level. In common configurations, security=auto lets the core select an available algorithm based on its implementation and runtime environment; it does not “automatically enable TLS.” If TLS is also enabled for the node, both VMess's own processing and outer TLS are involved. They serve different purposes, so seeing “encryption” does not mean you can skip certificate configuration.

VLESS commonly keeps the protocol itself simpler and relies on an outer layer to protect the connection. Seeing encryption=none in a VLESS configuration does not mean the entire connection is necessarily unencrypted; check whether TLS or REALITY is configured. Conversely, if encryption is set to none and there is no security layer, do not assume the proxy connection is fully protected just because you are visiting an HTTPS website.

Typical alterId value in modern VMess AEAD

443

Common TLS server port, not a requirement

5.0.0

V2Fly version that removed legacy non-AEAD VMess authentication

Can you still copy alterId=64 from old tutorials?

alterId is a legacy field from VMess's older authentication mechanism—not a performance tier, and a higher value does not mean better security. Modern configurations typically use alterId=0 with AEAD. V2Fly removed support for legacy non-AEAD authentication starting with version 5.0.0. Other cores may handle legacy configurations differently, so a connection working on one older version is no guarantee of continued support.

For a new configuration: Use the current settings provided by the server. Do not copy values such as 64 or 32 from an old tutorial.
If an old node fails to import: Ask your provider for an updated share link and confirm whether the server still depends on legacy authentication.
If you manage the server: Coordinate upgrades and the authentication migration on both ends before updating the subscription. Do not just change one number in the client.
For authentication errors: Check the UUID, device date and time zone, and settings on both ends. VMess requires clock synchronization, so the encryption algorithm is not the only thing to investigate.

Performance: VLESS is not a guaranteed speed boost

With common configurations, VLESS skips VMess's protocol-level payload encryption, which may reduce some CPU work. In practice, connections still need to handle TLS or REALITY, transport overhead, and network I/O. Hardware-accelerated AES-GCM can have very little overhead; for everyday browsing, latency, congestion, and server load often matter more than the protocol difference.

You cannot benchmark two nodes in different regions from different providers and attribute the entire difference to VMess or VLESS. WebSocket, connection reuse, routing rules, and the test file source can all affect results. This guide does not include reproducible benchmark data, so it makes no percentage-based speed claims.

Keep the route consistent: Use the same server and exit point, test at similar times, and keep transport and security settings comparable.
Keep the test consistent: Test page loads and short connections first, then download the same large file. Run each test at least 3 times and look at the variation, not just the highest result.
Track device load: Check core process CPU usage in your desktop task manager. Protocol overhead is more worth investigating when bandwidth is high and CPU usage is near capacity.
Establish a baseline first: Do not change DNS, routing, TUN, and multiplexing settings at the same time. Isolate one variable before drawing conclusions.

Recommendation: Keep a stable VMess setup unless there's a reason to switch

If your current node meets your bandwidth needs and has no core compatibility issues, keep the working configuration for now. If you need REALITY or Vision, choose a VLESS configuration explicitly supported by the server and keep a verified node as a fallback.

XTLS, Vision, and REALITY: Check the combination and core support

XTLS, Vision, and REALITY are not three speed-boost switches you can enable at will. The commonly used xtls-rprx-vision is a VLESS Flow value; REALITY is a connection security mechanism, not a separate proxy protocol alongside VMess and VLESS. Supported combinations also depend on the Xray version, transport, and server configuration.

A common VLESS + TCP + REALITY + Vision node requires checking the UUID, address, port, serverName, server public-key parameters, shortId, and Flow. The public-key field may be labeled Public key or something similar in the client; follow the provider's instructions and check the core in use. Do not copy a regular TLS certificate hostname into REALITY's serverName, and do not assume switching a TLS dropdown to REALITY is enough to migrate the configuration.

Xray core

Recommended

For the VLESS + REALITY / Vision combinations discussed here. The client must be able to save the relevant fields, and the core actually in use must support the server's features. Seeing “VLESS” in the app does not guarantee that every extension is supported.

Best for: configurations where the server explicitly requires REALITY or xtls-rprx-vision

V2Fly core

Can be used for VMess and other configurations supported by its version, but cannot handle Xray's REALITY / Vision configurations. For existing nodes, check the specific transport, authentication method, and version; do not assume features are shared between the two projects.

Best for: existing compatible configurations and environments where the server explicitly uses V2Fly features

How to identify VMess and VLESS nodes in v2rayN

Start with the Type or Protocol column in the main node list, then open the node editor to check the details. Menu labels, column names, and layouts may differ between desktop versions of v2rayN, so the steps below use common entry points. If your interface looks different, follow the meaning of the fields rather than relying on the node label.

Import a link: Copy the complete share link, then use “Servers” → “Import batch URLs from clipboard” in the main window, or the equivalent clipboard import option in your version. Do not paste a subscription URL where a single-node JSON is expected.
Open the edit window: Double-click the node row or choose Edit from its right-click menu. VMess typically has encryption and alterId fields; VLESS typically has encryption and Flow fields.
Check the security layer: Review the transport, TLS/REALITY, and SNI/serverName separately. Port 443 does not prove that TLS is enabled; check the security-layer field.
Check the active core: Confirm the selected core in the current version's core settings, then verify the actual core name in the startup log. Do not use the V2Fly core for REALITY / Vision.
Route traffic through the node: After selecting a node, use “System Proxy” → “Set system proxy” in the tray menu so apps that follow the system proxy can connect. Apps that do not follow it need separate configuration, or you can use TUN as described in the guide.

Share-link prefixes can also help with a quick identification: vmess:// indicates VMess and commonly contains Base64-encoded node JSON; vless:// indicates VLESS and typically carries transport and security settings in URL query parameters. Base64 is encoding, not encryption. Treat the UUID and server details in the link as access credentials.

Check both ends: verify the actual capabilities of each client

Desktop: v2rayN

Check the node protocol first, then the core actually running.
Verify the transport, security layer, and Flow one by one.
Check node connectivity, system proxy, and TUN as three separate steps.

Android: v2rayNG / v2flyNG

v2rayNG uses Xray; compatibility still depends on the specific version.
v2flyNG uses V2Fly; do not copy REALITY / Vision settings into it.
An imported subscription does not mean every node in the list will work.

Sharing a subscription only shares the node source; it does not make core capabilities consistent. Verify the nodes actually used by each client separately.

Common import and connection issues: find the cause by checking fields

When troubleshooting, separate the process into three stages: whether the link parses, whether the core starts, and whether the connection reaches the server. For import failures, check the format and supported fields; for startup failures, check the configuration and core; for connection timeouts, then check the address, port, and network. Do not keep changing the UUID and encryption method at every stage.

Changed VMess to VLESS and now it won't connect?

The two protocols use different handshakes, and the server must be configured for the matching protocol. Restore the original node type and ask the provider for a VLESS-specific share link. Even with the same address, port, and UUID, the server may not accept both protocols.

VLESS shows none—is encryption turned off?

First check whether you are looking at the encryption setting or the security layer. The common encryption=none configuration can be used with TLS or REALITY. If the security layer is also blank, do not guess; confirm the server setup and which networks it supports.

Subscription includes VLESS, but the client says Flow is unsupported?

Open the node editor to check Flow, then look at the core name in the runtime log. Update to a compatible client and core that meet the server's requirements. Removing Flow does not guarantee a connection, and a Vision node cannot be handed directly to v2flyNG.

TLS certificate error—is it safe to enable skip verification?

First sync the system clock, check SNI/serverName against the certificate hostname, and verify the certificate validity and server certificate chain. Do not use allowInsecure as a permanent fix; it weakens certificate verification and will not resolve UUID, Flow, or port errors.

Latency test succeeds, but the browser still won't load anything?

Make sure the node is active, then check whether the system proxy or TUN is routing browser traffic. If you configure a local proxy manually, use the port the client actually listens on; enter 10808 only if that is your local port. Do not use the server's port 443 as the local proxy port.

The choice comes down to this: if your current VMess setup is stable, prioritize compatibility and keep it. If the server requires REALITY / Vision, use a VLESS and Xray combination that supports those features. The protocol name tells you only part of the story; the full configuration and implementations on both ends determine whether it will work. For more on routing, DNS, and TUN, see the Terminology Guide; if you're setting things up for the first time, follow the Quick Start step by step.