VMess and VLESS are proxy protocols, not client names. VMess offers protocol-level payload encryption options and uses time-based authentication; the base VLESS protocol does not encrypt payloads and is commonly paired with TLS or REALITY. If you already have a subscription, first check whether your client can parse the complete configuration, then test whether it works. Don’t judge speed or security by the protocol name alone.
Understanding protocols, transports, and security layers
When choosing a V2Ray protocol, distinguish three layers: VMess or VLESS handles proxy requests and user authentication; TCP, WebSocket, and gRPC determine how the connection is carried; TLS or REALITY provides the corresponding security protection. The same VLESS node can use different transport and security settings. Two nodes using the same protocol do not necessarily share the rest of their configuration.
A V2Ray client provides an interface for editing configurations, managing subscriptions, and controlling connections; the core handles the proxy protocol itself. v2rayN is a desktop client; v2rayNG is an Android client that uses the Xray core; v2flyNG uses the V2Fly core. To determine whether a node will connect, check that the core supports the entire configuration combination—not just whether “v2ray” appears in the client’s name.
| Configuration layer | Common values shown | What to check |
|---|---|---|
| Proxy protocol | VMess、VLESS | Protocol type, UUID, and any other fields required by the protocol |
| Connection destination | Server address and port | Address and remote listening port, such as the provider-specified 443 |
| Transport | TCP、WebSocket、gRPC | WebSocket path and Host, or gRPC service name |
| Security settings | TLS、REALITY | Server name and the relevant certificate or REALITY parameters |
| Flow control | Empty, xtls-rprx-vision | Whether the server configuration requires it; don’t add it yourself |
For example, “VLESS + TCP + REALITY + Vision” is a complete combination. Vision is a flow-control setting, not a separate protocol alongside VLESS. REALITY is not another name for WebSocket, either. If that’s the configuration provided by the server, you can’t switch the transport to WebSocket and keep using the original parameters.
Key differences between VMess and VLESS
VMess does more than attach a UUID to a connection. It has its own authentication and data-protection mechanisms, with common payload encryption options including auto, aes-128-gcm, and chacha20-poly1305. Some configurations may also leave payloads unencrypted, so it’s not accurate to say that all VMess traffic is encrypted at the protocol layer. Whether to use outer TLS is a separate security setting.
The base VLESS protocol uses a lighter request structure and does not encrypt payloads. In common node configurations, encryption=none is expected; it doesn’t mean the entire connection is in plaintext. Outer TLS or REALITY can provide security protection. Conversely, if there’s no suitable security layer, a UUID alone does not mean the connection is encrypted.
| Comparison | VMess | Base VLESS protocol |
|---|---|---|
| User identifier | Usually a UUID | Usually a UUID |
| Payload encryption | Protocol-level encryption options; depends on configuration | Not provided; often relies on outer security settings |
| Time dependency | Authentication requires the client and server clocks to be close | Base authentication does not use a VMess-style time window |
| Common combinations | VMess + WebSocket + TLS | VLESS + WebSocket + TLS, or VLESS + TCP + REALITY |
| Can they be swapped directly? | No. The server and client must use the same protocol | |
Modern VMess configurations typically use AEAD authentication, with alterId commonly set to 0. Don’t copy nonzero values from outdated online guides into new nodes. VLESS has no corresponding alterId setting, and VMess encryption options shouldn’t be carried over. If the subscription provides the correct parameters, keeping them as supplied is more reliable than guessing each value.
Time checks: Check your system clock first if VMess won’t connect
VMess authentication depends on time. Common implementations require the client and server clocks to be within about 120 seconds of each other, though the exact requirement depends on the core in use. Clock drift after a computer wakes from sleep, disabled automatic time settings, or an incorrect server clock can all cause authentication to fail. Changing the node’s port from 443 to 80 won’t fix this.
- Windows: Go to Settings → Time & language → Date & time, turn on “Set time automatically,” then select “Sync now” and reconnect. Changing the time zone alone usually won’t correct an inaccurate system clock.
- Android: Open Date & time in your system Settings and turn on automatic time. Depending on your device, this option may be under System or Additional settings.
- Test again: Disconnect and reconnect to the original VMess node, then check whether the authentication error has disappeared from the core log. If other VMess nodes work but one doesn’t, ask the provider to check the server time and account configuration.
VLESS doesn’t have the same protocol-level authentication time window, but that doesn’t mean the system clock can be set arbitrarily. TLS certificates have validity periods, and a significantly incorrect date can still cause certificate validation to fail. If the log says a certificate is not yet valid or has expired, check the date first, then determine whether the issue is your device’s clock or the server’s certificate.
Transport combinations: Choose a client based on the complete node configuration
Both VMess + WebSocket + TLS and VLESS + WebSocket + TLS require you to check the path, Host, and TLS server name. For example, if the provider specifies the path /proxy, don’t change it to /. The connection address, HTTP Host, and TLS server name serve different purposes. They may match or differ; follow the node configuration instead of mechanically entering the same address in all three fields.
REALITY nodes may also require a public key, shortId, and server name; nodes using Vision need the matching flow-control setting. Missing, incorrect, or lost fields during subscription conversion can all prevent a connection. The VLESS protocol name alone does not guarantee that the current core supports these extended combinations.
Xray core and complete VLESS configurations
RecommendedFor nodes where the provider explicitly requires REALITY or Vision, first check Xray core support. On desktop, confirm the selected core in v2rayN; on Android, you can use v2rayNG. Keep the transport, security, and flow-control parameters from the subscription.
Best for: Users whose subscription includes VLESS + REALITY or explicitly requires Xray extensions.
V2Fly core and compatible node configurations
Existing VMess + WebSocket + TLS nodes can be used if the core supports their configuration. On Android, v2flyNG uses the V2Fly core. Don’t assume Xray extensions are compatible; after importing, check the fields and logs.
Best for: Users whose provider explicitly supports V2Fly and whose existing node combination has been verified to work.
How to choose: Check the full configuration, not just the protocol name
First confirm that the protocol, transport, security layer, and flow control are all supported, then test the connection. If an existing VMess node works reliably, there’s no need to switch just for the name. For a subscription that explicitly requires REALITY, choose a compatible core first.
Importing subscriptions: Don’t manually change VMess to VLESS
A subscription distributes node configurations in bulk; it isn’t a third proxy protocol. One subscription can include both VMess and VLESS, or just one of them. After import, the client saves each node’s protocol, server, and transport parameters separately. If a subscription update reports “unsupported,” check the specific node combination instead of simply changing the protocol in a dropdown.
Steps: Check both ends of the same subscription
Desktop: v2rayN
- In Subscription Group Settings, enter a name and URL, save, then update the subscription.
- Open a node’s edit window and check its protocol, remote port, transport, and security settings.
- Confirm that the core in use supports the node combination, then set it as the active server.
Android: v2rayNG
- To import a subscription in v2rayNG, add its URL under Subscription Group Settings in the sidebar, then update the subscription from the main menu.
- Check that the VLESS node has a complete server name, REALITY parameters, and flow-control setting.
- Start the connection, approve the system VPN prompt, then test in a browser.
Both clients can use the same subscription URL, but their parsing support and update timing may differ. Check the results after updating to see whether the node lists match.
Menu names vary by client version. If you can’t find an option, look for the features named “Subscription Group” and “Update Subscription.” For v2rayNG downloads and first-connection steps, see the client download page and getting started guide; there’s no need to rebuild every node parameter by hand.
- Import failed: Check that you copied the full subscription URL and that the response is in a format your client can parse.
- Some nodes are missing: Check for unsupported protocol extensions or fields. If needed, ask the provider for a subscription compatible with your client.
- Manual changes disappeared after an update: Subscription updates may overwrite node settings. For temporary troubleshooting, save a separate copy. After resolving the issue, use the provider’s valid configuration.
V2Ray node speed tests: Compare real requests, not protocol names
VMess’s protocol processing and VLESS’s lighter structure do differ, but real-world performance also depends on the route, server load, transport, packet loss, and local device. If two nodes differ in region, entry point, or security layer, you can’t attribute the entire speed difference to VMess versus VLESS. This article doesn’t claim speed percentages without test conditions.
- Keep the setup consistent: Use the same device, network, and test destination; pause downloads that are using bandwidth.
- Keep the route consistent: Confirm that the current node is forwarding the test request rather than a routing rule sending it direct. A reachable TCP port only confirms that the endpoint accepts connections; it doesn’t prove proxy authentication succeeded.
- Repeat the test: Test each node at least 3 times and record successful attempts, time to first byte, and sustained download performance. Don’t let one low-latency result outweigh repeated failures.
- Check the logs: Record authentication failures, TLS errors, and request timeouts separately. Fix configuration errors before comparing performance.
To rule out browser proxy settings, you can specify a local SOCKS proxy explicitly. The 127.0.0.1:10808 below is only an example of a local listening address; replace it with the actual SOCKS or mixed port shown in your client. It is not the node’s remote port 443.
curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 30 --output /dev/null --write-out "HTTP=%{http_code} first_byte=%{time_starttransfer}s total=%{time_total}s\n" https://example.com/This command is for Unix-like terminals with curl installed. On Windows, use curl.exe and change the output target from /dev/null to NUL. socks5h resolves the destination hostname through the SOCKS proxy. The 10-second connection timeout and 30-second total timeout are limits for this test, not protocol performance metrics. The example site is only for checking requests, not for measuring bandwidth.
How to choose: Keep the node that works reliably
After repeating requests to the same destination, prefer the node with a consistently high success rate and no authentication or certificate errors in the logs. Compare latency and throughput only when those conditions are similar. Change one parameter at a time to isolate problems.
Common issue: The protocol works, but an app still may not use the proxy
A successful node connection and an app’s traffic going through the proxy are two different things. The system proxy mainly affects software that follows system proxy settings; v2rayN’s TUN mode routes traffic through a virtual network interface, with the actual scope still affected by routing and exclusion rules. Switching between VMess and VLESS won’t automatically fix browser extensions, terminal environment variables, or per-app proxy settings.
VLESS says none. Does that mean there’s no encryption?
Open the node’s edit window and check its security settings first. encryption=none in base VLESS doesn’t mean there’s no outer protection. If the configuration requires TLS or REALITY, make sure those fields are complete; don’t judge by “none” alone.
VMess suddenly won’t connect at all. Should I switch protocols first?
Sync your system clock first, then retry the original node and check the logs. If all VMess nodes fail at once while other connections work, check the time first. Don’t simply change the original node to VLESS; that won’t change the server.
What if VLESS imports successfully but fails to connect?
Check the subscription’s server port, transport, TLS server name, REALITY public key, shortId, and flow-control setting one by one. Confirm that the core supports the combination, then check the logs. “Imported successfully” only means the configuration was parsed; it doesn’t guarantee the parameters are valid.
Why does the command line work when the browser doesn’t?
If an explicit SOCKS request succeeds, first check the browser’s proxy extension and the client’s system proxy status. Then confirm that routing rules aren’t sending the destination direct. One app failing doesn’t mean VMess or VLESS is unavailable.
Do I have to use VLESS with TUN enabled?
No. TUN is a way to route traffic through a local interface; it doesn’t restrict the remote protocol. Start with a node that’s already been verified to work, then check the virtual interface, permissions, DNS, and routing. Note the original settings before enabling TUN, and turn it off to retest if something goes wrong.
For everyday use, follow this order: confirm that your client and core are compatible, check all subscription parameters, verify the clock and certificates, then test whether the app’s traffic is actually being proxied. VMess and VLESS differences can help pinpoint issues, but they don’t replace this troubleshooting process. For more on checking outbound tags, DNS, and routing matches, see the complete configuration guide.