VMess and VLESS are proxy protocols—not clients or transport methods. To determine whether a subscription node will work, check the protocol, transport, security layer, and core in use. This guide is for users importing subscriptions, checking node settings, or choosing a desktop or Android client. Learn what UUID, TLS, REALITY, and flow do, and how to identify where a connection is failing by checking the relevant fields.
VMess vs. VLESS: Understand Authentication, Encryption, and Transport
A node is more than a “VMess” or “VLESS” label. A complete connection usually includes a server address, port, user credentials, transport, and security layer. The protocol defines how proxy requests are handled and users identified; TCP and WebSocket carry the data; TLS or REALITY provides the corresponding secure handshake and connection protection.
VMess supports encryption within the protocol, and modern configurations typically use AEAD authentication. Common VLESS configurations set encryption to none and rely on an outer layer such as TLS or REALITY to protect the connection. This covers common subscription configurations; newer extensions and different core implementations may work differently.
| Comparison | VMess | VLESS |
|---|---|---|
| User credentials | Uses settings such as UUID for authentication; modern configurations use AEAD. | Common configurations use a UUID to identify the user; it must match the server. |
| Data encryption | Supports encryption within the protocol; the specific algorithm depends on the configuration and core implementation. | Common encryption: none configurations do not encrypt data within the protocol. |
| Outer-layer protection | TLS can be added; protocol-level encryption does not make transport settings irrelevant. | Common public-facing configurations rely on TLS or REALITY for connection protection. |
| Transport options | Common options include TCP and WebSocket; the server configuration determines what's available. | Common options include TCP, WebSocket, and gRPC; support depends on the core and server. |
| Additional checks | System time, authentication settings, and alterId in legacy configurations. | flow, the security layer, and required REALITY fields. |
Check the Full Configuration Before Comparing Protocol Names
For each node, note the protocol, transport, security layer, and flow. Switching clients just because a node is labeled VLESS—or copying a VMess UUID into a VLESS node—does not convert the protocol.
Encryption: VLESS with none Doesn’t Mean the Entire Connection Is Unencrypted
“VLESS is unencrypted” leaves out an important detail: it usually means the VLESS protocol itself does not encrypt proxy data when configured with encryption: none. It does not mean there is no encryption at the outer layer. With VLESS + TLS, TLS protects the connection between the client and the TLS termination point. With REALITY, the core must support and perform the corresponding handshake.
Conversely, VLESS + TCP with the security layer also set to none does not get the outer-layer protection described above. HTTPS in an application protects only that application-layer traffic; it does not mean the entire proxy connection is encrypted. Don’t disable the security layer just to troubleshoot, and don’t treat disabling certificate verification as a permanent fix.
- VMess UUID: An authentication credential, not a server certificate. A valid UUID won’t fix an incorrect TLS server name.
- VMess
security: In VMess user settings, this usually refers to the data encryption option. Don’t confuse it with a field of the same name in the transport settings. - VLESS
encryption: The common value isnone. Check TLS or REALITY to determine whether the node has outer-layer protection. - TLS SNI: The server name sent during the handshake; it is usually also checked against the certificate name. The connection address can be an IP, but that doesn’t mean you should clear the server name.
- REALITY settings: In addition to the UUID, check the server-provided public key, server name, shortId, and any client-required fields such as the fingerprint.
Transport Combinations: WebSocket, TLS, REALITY, and Vision
WebSocket is not an encryption protocol, and TLS is not limited to any particular proxy protocol. So VMess + WebSocket + TLS and VLESS + WebSocket + TLS have similar transport setups, but differ in authentication and protocol handling. Even with the same address and port, changing the protocol in the client’s dropdown is not enough.
| Combination | Key fields | Common pitfall |
|---|---|---|
| VMess＋WebSocket＋TLS | UUID, encryption option, WebSocket Path, Host, and TLS server name. | Treating the WebSocket Host and TLS server name as the same setting. |
| VLESS＋WebSocket＋TLS | UUID, encryption, Path, Host, and TLS settings. | Copying the path from another node or adding a flow that doesn’t apply. |
| VLESS＋TCP＋TLS | UUID and TLS server name; if the server requires Vision, the flow must match too. | Assuming every VLESS node requires xtls-rprx-vision. |
| VLESS＋TCP＋REALITY | UUID, public key, shortId, server name, fingerprint, and any flow required by the server. | Importing only the address and UUID while missing REALITY settings. |
xtls-rprx-vision is a flow setting, not a general-purpose speed boost for any transport. Common Vision setups use TCP with TLS or REALITY; don’t add it to a WebSocket node based on guesswork. Keep fields at their subscription values unless the server requires otherwise.
These numbers illustrate what the fields mean; they’re not instructions to change every node. The server sets the remote port, while the client’s current settings determine the local port. A remote port of 443 alone doesn’t prove that a security layer is enabled. A nonzero alterId in an older guide is a legacy setting to verify; don’t reuse it without confirming with the server.
Client Compatibility: Importing a Node Doesn’t Mean the Core Can Run It
v2rayN is a desktop client that runs nodes using its selected core. v2rayNG is an Android client that uses the Xray core, while v2flyNG uses the v2fly core. Clients manage subscriptions, the interface, and routing, but whether a protocol combination works ultimately depends on the core version and its supported features.
Check Both Platforms: Test the Same Subscription on Each Client
Desktop: v2rayN
- After importing the subscription, open the target node’s editor and check its protocol, transport, and security layer.
- For VLESS + REALITY or Vision, make sure the active core is Xray and supports that combination.
- Check the startup output to distinguish a configuration parsing error from a connection failure.
Android: v2rayNG / v2flyNG
- In v2rayNG, check that the bundled Xray core supports the fields used by the subscription.
- With v2flyNG, choose nodes supported by its v2fly core; don’t assume Xray-specific combinations will work.
- After updating the subscription, check the target node again to make sure you haven’t selected an older manually imported copy.
A subscription can include different protocol combinations. The same node list doesn’t mean every client supports every node equally.
For v2flyNG, seeing “VLESS” in the interface doesn’t prove that REALITY or Vision is supported; check the app and core’s actual support information. VMess isn’t immune to compatibility issues either: legacy share formats, authentication modes, and transport fields can also prevent a node from connecting after import.
- Check the app’s About or core information for the current app and core versions, then ask your provider which combinations are required.
- After updating the subscription, check whether nodes with the same name appear in multiple groups so you know exactly which one you’re testing.
- Save the full error message. If the app exits during startup, check for unsupported fields before changing routing rules.
Importing a Subscription: Check the Fields, Not the Protocol Name, to Diagnose Speed
Common VMess share links use vmess://, while common VLESS share links use vless://. VMess links often encode a configuration block; VLESS links typically carry transport and security settings as URI query parameters. A subscription may return multiple nodes at once. Recognizing the link prefix only confirms that the correct parsing method was used.
When troubleshooting, keep the original subscription node and make a copy to inspect. Share links and subscription URLs often contain active credentials. Before asking someone to help, hide the UUID, tokens, and any account-identifying details. Don’t post a full subscription URL in public logs or screenshots.
Why Does VMess Work but VLESS Fail in the Same Subscription?
Open the failing node’s editor. First check whether the security layer is REALITY and whether the flow is xtls-rprx-vision, then verify that the current core supports them. Next, make sure the public key, shortId, and server name were imported correctly. Don’t assume the account is invalid.
The Node Shows Latency, but the Browser Won’t Load Pages. Is This a Protocol Compatibility Issue?
Not necessarily. A successful TCP probe only means the port is reachable. First confirm what was tested, then check the system proxy and local inbound settings. If the local SOCKS port is 10808, use the command below to test directly and bypass the browser’s proxy selection.
VMess Suddenly Fails Authentication. Should You Switch to VLESS?
Enable automatic time synchronization, check the UUID, and update the subscription again. VMess authentication depends on time information, so a significant system clock error can cause failures. Changing the protocol name won’t fix authentication unless the server configuration is changed to match.
If Both Protocols Connect, Which One Is Faster?
Test the same destination at similar times, recording connection setup time, sustained download performance, and failures. Results are meaningful only when the route, server load, transport, and test conditions are comparable. Speed differences between different servers can’t be attributed to the protocol alone.
curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 -I https://example.com/This command assumes a SOCKS inbound is listening locally at 127.0.0.1:10808. If the client uses a different port, replace it with the actual value. socks5h lets the proxy resolve the destination hostname; --connect-timeout 10 sets a 10-second connection timeout; and -I requests response headers. This checks connectivity, not bandwidth. Once the request reaches the core, it still follows the current routing rules.
Choosing a Protocol: Keep Working Nodes and Match the Server Configuration
Choosing a protocol isn’t an upgrade based on its name. If a VMess node already works reliably, there’s no need to replace its settings just because you see VLESS. Likewise, if the server provides a complete VLESS + TLS or REALITY configuration, there’s no need to switch to VMess for “compatibility.” What matters is that both ends support the protocol implementation and the full set of connection settings.
Keep the Complete, Tested Subscription Configuration
RecommendedKeep the protocol, transport, and security layer provided by the server. Confirm that the core supports them, then test the connection. Update the subscription separately from routing settings to reduce the number of variables when troubleshooting.
Best for: everyday use, importing across devices, and existing working nodes
Keep VMess for Existing Deployments
If the server uses VMess and the client supports its authentication and transport, keep the existing settings. If problems occur, check the system time, UUID, and transport fields first.
Best for: existing VMess servers and troubleshooting with a known-compatible configuration
Use the Required VLESS Security Settings
If the server explicitly provides TLS or REALITY settings, choose a core that supports that combination. Set the Vision flow only when required by the server; don’t add extra parameters.
Best for: users with complete VLESS settings and a clear understanding of core support
- Before importing: Confirm the subscription source, node configuration, and client core requirements.
- Startup failure: Check configuration parsing and unsupported fields first, then check the selected core.
- Handshake failure: Check the system time, authentication credentials, server name, and security settings.
- Problems accessing sites after connecting: Check DNS, the system proxy, TUN, and routing rules. Don’t keep switching protocols.