VMess and VLESS are proxy protocols, not client apps. Typical VMess configurations encrypt data at the protocol layer, while common VLESS configurations rely on TLS or REALITY for transport security. For most users, importing a subscription as provided and checking the protocol, transport, and security settings is safer than changing protocols manually. This guide shows how to identify a node and troubleshoot import failures, including which fields must match and which settings can't be reused as-is.
The one-minute guide: protocol, transport, and security layers
In v2rayN's node editor, you might see VMess, VLESS, WebSocket, and TLS together. They belong to different layers: VMess and VLESS are proxy protocols; TCP and WebSocket determine how the connection is transported; TLS and REALITY provide connection security and authentication. Seeing just one of these names isn't enough to identify the full node configuration.
| Comparison | VMess | VLESS |
|---|---|---|
| Credentials | Typically a UUID | Typically a UUID |
| Common encryption settings | Often options such as auto; the implementation selects an appropriate algorithm | In common legacy configurations, encryption is set to none, with TLS or REALITY configured separately |
| Other fields to check | Encryption method and alterId in older configurations | Security layer, flow, and parameters required by REALITY |
| Can they be swapped directly? | No. The client and server must use the same protocol | |
Think of a UUID as a credential the server uses to identify a user, not as a complete configuration. Even if two nodes share the same UUID, they aren't interchangeable when their ports, protocols, or transport paths differ. The protocol name also says nothing about connection quality; routing between networks, congestion, and server load usually have a greater impact.
Encryption: VLESS encryption=none doesn't mean the entire connection is unencrypted
Typical VMess configurations encrypt proxy data at the protocol layer, usually with VMess AEAD in modern setups. TLS can also be added on top for transport security. Don't confuse VMess data-encryption settings with the TLS toggle: they apply at different layers.
In common legacy VLESS configurations, encryption=none describes the VLESS layer itself; it doesn't mean TLS or REALITY is disabled. To determine whether a connection is protected, check its security-layer settings. VLESS over plain TCP without additional transport security should not be treated as secure in the same way as VLESS with TLS.
- VLESS + TLS: Check that TLS is enabled, the server name is correct, and certificate validation succeeds.
- VLESS + REALITY: Check the server name, public-key parameters, and shortId. If Vision is required, check the flow setting too.
- VMess + WebSocket + TLS: Along with the UUID, check the WebSocket path, Host, and TLS server name.
How to check: review the full combination, not just one field
If VLESS shows none, check the TLS or REALITY settings first. If VMess shows auto, you still need to check the transport and server requirements. Don't change subscription settings just to remove a label that looks unsafe.
Configuration fields: checking the port, UUID, alterId, and flow
An import failure isn't the same as a connection failure. Import issues often stem from an unsupported link format or incomplete content; connection failures usually happen after the node appears in the list. When checking settings manually, start with the address, port, and UUID, then review protocol-specific fields, followed by the transport and security layers.
These three numbers refer to different things. Port 443 may be used by the remote server; 10808 may be the local port an app uses to connect to the proxy; alterId is a legacy VMess configuration field. If your browser is set to use port 10808, that doesn't mean you should change the node's remote port to 10808. Modern VMess AEAD configurations usually set alterId to 0. If an older guide shows a nonzero value, confirm it with your provider instead of applying it to a new node.
- Address and port: Enter the complete values provided by your service. TLS nodes don't always use port 443; TLS can run on other ports too.
- UUID: Copy the entire value without adding spaces. Don't enter a subscription token in the user ID field.
- VMess encryption: Keep the setting from your subscription. Don't copy the VLESS encryption field into it.
- VLESS flow: Set this only if the server requires it, for example
xtls-rprx-vision. Not every VLESS node uses Vision. - Transport and security layers: Check fields such as the path, Host, and server name. Don't apply REALITY parameters to a standard TLS node.
Client compatibility: check the core's capabilities, not just the app name
v2rayN is a desktop client; the core it invokes handles the actual connection. v2rayNG is an Android client that uses the Xray core, while v2flyNG uses the v2fly core. Supporting basic VLESS doesn't guarantee support for every VLESS configuration, especially REALITY, Vision, or newer transport options.
Import the subscription as provided
RecommendedKeep the protocol and security layer specified by your provider, then check that your current client core supports the full configuration. If your existing node works, there's no need to change its settings just because you want to use a different protocol.
Best for: first-time setup, everyday use, and importing across devices
Create a node manually
Enter settings manually only if you have the complete configuration. Both VMess and VLESS require server-side support; changing the protocol in the client alone won't migrate a node.
Best for: self-hosted servers, finding missing fields, and checking import results
Before importing, check the client's About page and core version. If the logs explicitly report an unsupported field, flow, or transport, verify the version and selected core instead of repeatedly changing the UUID. For configurations specific to Xray, don't assume v2flyNG is compatible just because it recognizes the VLESS protocol name.
Check both ends: use the same subscription source, verify each client's capabilities separately
Desktop: v2rayN
- Save the subscription URL under Subscription Groups → Subscription Group Settings.
- After updating the subscription, open the node editor and check the protocol and security layer.
- For combinations such as REALITY, confirm that the core in use supports them and check its version.
Android: v2rayNG or v2flyNG
- First, make sure the current app supports the format returned by the subscription.
- Check v2rayNG against Xray's capabilities, and v2flyNG against v2fly's.
- Update the subscription on each device and check the node count and key fields. Don't assume they sync automatically.
Menu names can change between versions. The same subscription may also return different content depending on the client making the request, so verify each device separately.
Subscription imports and connection checks: start with the format, then check the logs
Single-node share links and subscription URLs serve different purposes. A share link usually contains the settings for one node and often starts with vmess:// or vless://. A subscription URL is typically a web address that returns a list of nodes. Pasting a subscription URL into the single-node editor, or treating an entire webpage as a share link, can cause an import failure.
- Check the input type. Import a single-node link from the clipboard. Add a subscription URL to a subscription group, then update it. Don't use the subscription management page URL as the subscription endpoint.
- Check the import result. Open the node editor and confirm the protocol from its settings, not its label. Then check the port, transport, and security layer.
- Check the logs after connecting. First rule out configuration parsing errors, then check for connection timeouts, authentication failures, or certificate validation errors. Handle each type separately.
- Finally, check the app's proxy settings. Desktop browsers usually need the system proxy enabled or a separate proxy configured. If an app isn't using the proxy, a working node doesn't mean its traffic is going through it.
A speed test only shows performance under the conditions of that particular test; it doesn't prove VLESS is faster than VMess. Switching protocols usually also means changing the server, transport, and network route, so it's hard to compare protocol overhead alone. If your current VMess node is stable, keep using it. If your provider offers a VLESS node compatible with your client, test it separately by opening websites, downloading over time, and checking recovery after switching networks.
FAQ: Why similar-looking nodes need different settings
Can I change VMess to VLESS and connect right away?
No. Ask your provider for a VLESS configuration, or add a matching inbound on your self-hosted server, then import the new node. Keep the working VMess node so you can switch back if testing fails.
VLESS shows none. Should I change it to auto?
In common legacy VLESS configurations, keep encryption set to none and check that TLS or REALITY matches your provider's requirements. auto is commonly a VMess encryption option and shouldn't be copied across protocols.
The same subscription works on my computer but not on Android. What should I do?
Update the subscription on both devices, compare the node's protocol, transport, and security layer, then check each core version. If the failing node relies on REALITY or Vision, focus on whether the Android core supports it. Don't compare node labels alone.
If I get a connection timeout, should I change the protocol or port first?
Don't change either blindly. First check whether the subscription has expired and whether the address and port are correct, then check whether your network can reach the server. Add a test node with a different port or protocol only if your provider explicitly offers those settings.