If you already have a subscription, start with a node that has complete settings and is supported by the kernels on both ends. If you manage your own server, compare authentication, security layers, and transport options. This guide explains how protocols relate to client kernels, compares four popular options, and walks through checks for desktop and Android. Learn when to stick with VMess, when to use VLESS + REALITY, and which conditions suit Trojan or Shadowsocks.
Know the difference: protocol, transport, security, and client
“VLESS + TCP + REALITY” in a node name does not list three interchangeable options. VLESS handles proxy requests and user authentication; TCP is the underlying transport; REALITY provides security-handshake and authentication mechanisms. Confusing these layers can lead to questions like “Why won’t VLESS connect?” or “Does using port 443 automatically enable TLS?”
v2rayN, v2rayNG, and v2flyNG are graphical clients, not aliases for these four protocols. What v2rayN can do depends on the selected core and its version; v2rayNG uses the Xray core, while v2flyNG uses the v2fly core. A field appearing in the interface does not mean an older core supports that combination. And a successful subscription import does not guarantee that every setting was preserved correctly.
- Proxy protocol: VMess, VLESS, Trojan, and Shadowsocks define the request format and authentication method.
- Transport: TCP, WebSocket, gRPC, and more determine how proxy data travels over the connection; support varies by implementation.
- Security: TLS, REALITY, or encryption built into the protocol. Don’t infer the security setup from the node name alone.
- Access and routing: System proxy, TUN, and routing rules determine which apps and destinations use a node; they do not change its protocol.
Comparing four protocols: encryption, authentication, and REALITY
The table below covers common configurations that are still in use. VMess assumes a modern AEAD setup; for Shadowsocks, distinguish legacy AEAD from the 2022 series. The same protocol name can cover different algorithms and implementation versions, with different compatibility requirements.
| Protocol | Authentication and encryption | Common transports | REALITY support | Key settings to check |
|---|---|---|---|---|
| VMess | User ID authentication; commonly uses AEAD encryption, with TLS available as an additional layer | TCP, WebSocket + TLS, and more | Not a standard pairing for REALITY | UUID, encryption options, transport settings, system time |
| VLESS | Common configurations use UUID authentication; legacy setups do not encrypt data themselves and rely on an outer security layer | TCP + TLS, TCP + REALITY, WebSocket + TLS, and more | Common with Xray; verify support on both ends | UUID, flow, security layer, server name, and public-key-related settings |
| Trojan | Password authentication; standard setups rely on TLS to protect data | Usually TCP + TLS; other transports depend on the implementation | Supported by some Xray configurations; don’t assume compatibility from the name | Password, TLS server name, certificate, transport |
| Shadowsocks | Compatibility depends on the algorithm and key; common options include AEAD and the 2022 series | Native TCP and UDP; verify any additional encapsulation separately | Not a native protocol feature; don’t apply VLESS settings directly | Method, password or key format, UDP support |
VMess auto is an encryption-selection mechanism provided by the implementation, not a separate protocol. Modern configurations generally use AEAD authentication headers; don’t add alterId just to match an outdated or unverified guide. Time-based authentication also requires an accurate device clock, so enabling automatic time sync is a more targeted first step than repeatedly changing the UUID.
For common VLESS configurations, encryption=none must be understood in the context of the security layer. It does not mean the entire connection is necessarily unencrypted, nor does it mean VLESS encrypts traffic automatically: TLS or REALITY provides protection when used as the outer layer. Confirm support for newer extensions separately; this guide does not assume every core supports them by default.
Shadowsocks aes-128-gcm and 2022-blake3-aes-128-gcm are not interchangeable. The 2022 series has its own key-length and encoding requirements: a 128-bit key is 16 bytes, and a 256-bit key is 32 bytes, encoded as required by the configuration. You can’t enter any short password and expect the client to convert it into the right key.
Handshake and speed: why protocol names don’t determine performance
First-connection time includes DNS lookup, network round trips to the node, the security handshake, the proxy request, and the destination’s response. TCPing usually only tells you whether a TCP connection to the node’s port can be established; it doesn’t verify the UUID, password, certificate, or REALITY settings. It therefore can’t establish that one protocol is faster end to end.
For a typical TCP connection, establishing a new connection usually takes one round trip; a full TLS 1.3 handshake usually takes one more. Whether these steps can overlap, resume a session, or reuse a connection depends on the implementation. A WebSocket upgrade and its additional HTTP layer can also increase connection setup time. Packet loss can magnify these costs, but they shouldn’t be mechanically added into a universal latency formula.
These numbers describe port usage, not speed-test results. A server on port 443 is not necessarily presenting a certificate that browsers can validate; a local SOCKS listener on port 1080 does not mean the remote server must use the same port. Distinguish the local listener from the remote endpoint to avoid mistaking a local connection issue for a protocol performance problem.
- Keep the comparison fair: Use the same server, route, and time of day where possible. Nodes in different regions can’t prove one protocol is better than another.
- Measure latency and throughput separately: Test a real connection first, then run a speed test against the same file. Repeat five times and record the median and number of failures.
- Track device metrics: Check CPU use, temperature, and battery drain. On Android, heat during a sustained download may affect usability more than a handshake difference of a few milliseconds.
- Change one setting at a time: Keep connection reuse, routing, and DNS settings unchanged while comparing transports and security layers. Otherwise, you won’t know what caused the difference.
Choose by server setup: where each protocol fits
No protocol is universally best regardless of server routing, configuration management, and local core. The recommendations below assume you can control and maintain the server. If you only have subscription access, use the complete configuration supplied by the service provider; don’t piece together settings just to use a newer-sounding protocol.
VLESS + REALITY
RecommendedA good option to test first when both ends use a compatible Xray core and you can maintain the server settings. For the common Vision setup, check xtls-rprx-vision, the server name, public-key-related settings, and shortId—not just the UUID.
Best for: users who manage the server and can keep desktop and Android settings in sync.
Trojan + TLS
When you already have a domain, certificate, and renewal process, the configuration is relatively straightforward. Check certificate trust, server name, and password separately to isolate issues. An expired certificate or mismatched SNI can block the connection before any proxy request is made.
Best for: setups with existing TLS operations that want to follow standard certificate validation practices.
VMess + WebSocket + TLS
If you already have a working reverse proxy and VMess node, you can keep using them. If traffic passes through a CDN, confirm that it supports the required WebSocket forwarding, port, and traffic type. The path, Host, and TLS server name are separate fields.
Best for: setups where an existing subscription or service architecture already uses VMess reliably.
Shadowsocks AEAD / 2022
A native configuration has relatively few fields to check: address, port, algorithm, and key. Verify supported algorithms, UDP forwarding, and any additional encapsulation separately; fewer fields do not guarantee greater stability on every network.
Best for: setups where the server explicitly provides the required algorithm and you need to test native TCP and UDP forwarding.
v2rayN and v2rayNG: check settings after importing
A subscription distributes node settings; it is not a fifth proxy protocol. If the same node name appears in two clients after import, that only confirms the name matches—it doesn’t prove that flow, transport, and security settings were all parsed correctly. After the first import, open the node editor and compare each setting with the information from the provider.
How to check one node on desktop and Android
Desktop: v2rayN
- Check which core and version are actually in use; don’t record only the UI version.
- Open the node editor and check the protocol, address, remote port, and security layer.
- Test using the actual local port, then check that system proxy or TUN is set up for your use case.
- If the connection fails, check the runtime log to distinguish a timeout, authentication failure, or certificate error.
Android: v2rayNG
- Check whether the bundled Xray version supports the full configuration provided by the server.
- Check the node’s transport protocol, TLS or REALITY settings, and server name.
- Start the connection and confirm that Android’s VPN permission has been granted.
- Temporarily disable per-app exclusions to ensure the test app is routed through the proxy.
Subscription updates sync only the node fields they contain. Check local routing, DNS, system proxy, and per-app settings separately.
With VLESS + REALITY, the commonly missed settings are server name, public-key-related settings, shortId, and flow. With VMess + WebSocket, check the path and Host. For Trojan, check the password and certificate server name; for Shadowsocks, start with the method and key format. Field names can change between client versions, so match settings by what they mean, not where they appear in the interface.
- Separate the address from the server name: The connection address can be a server IP, while the TLS server name usually needs to match the certificate or a name allowed by the server. Don’t automatically enter the IP in both fields.
- Keep certificate validation enabled: For certificate errors, check the system time, server name, trust chain, and certificate validity. Disabling validation is not a suitable long-term fix.
- Test UDP separately: Being able to browse the web doesn’t mean UDP works. Check the protocol implementation, server forwarding, firewall, and client connection mode.
- Protect your credentials: Don’t include subscription URLs, UUIDs, passwords, keys, or complete share links in public screenshots.
Protocol selection FAQ
Is VLESS always faster than VMess?
Not necessarily. Common VLESS configurations reduce encryption work within the protocol itself, but may still use TLS or REALITY. Keep the server and test destination constant, run five real connection tests and download tests, then compare the median, failure rate, and CPU usage. Results from different routes can’t be attributed to the protocol name.
The node says REALITY. Why does it time out after import?
First, confirm that the server address and remote port are reachable. Then open the node editor and check the server name, public-key-related settings, shortId, and flow. Next, check the Xray versions on both ends. A successful TCPing only confirms a connection to the port; it doesn’t prove that the REALITY handshake succeeded. Use the specific handshake error in the log to diagnose the settings.
Shadowsocks opens websites, but games won’t connect. What should I do?
First confirm that game traffic is routed through the proxy, then check whether UDP is enabled and supported by both the server and client. A browser or system HTTP proxy alone is usually not enough to route game traffic over UDP. Even when the protocol supports UDP, the server firewall or current network may block that traffic.
Can v2flyNG use the same REALITY node directly?
A successful subscription import doesn’t prove that a node will work. v2flyNG uses the v2fly core, while the common REALITY setups covered here are based on Xray. If you need to use this type of node, check core support first. On Android, you can test the configuration provided by the service using v2rayNG; renaming a node won’t make it compatible.
Will my routing rules still work if I switch to Trojan?
Rules can remain in place if they reference an unchanged outbound tag and the new node is correctly assigned to it. If they depend on a node name, group, or specific outbound, check them again. Test one destination that should bypass the proxy and one that should use it, then confirm the actual outbound in the log. Don’t rely solely on the client showing “Connected.”