Check the server configuration first, then the client core and network conditions. This guide separates protocols, transports, and security layers, compares how the four protocols authenticate users, protect data, and affect connection overhead, and explains what to check on desktop and Android. If you already have a subscription, use these checks to assess compatibility. If you run your own server, use them to plan testing instead of judging performance by protocol name alone.
1. Know the Difference Between Protocols, Transports, and Security Layers
VMess, VLESS, Trojan, and Shadowsocks are proxy protocols. TCP, WebSocket, and gRPC are common transport options. TLS and REALITY provide connection security. A subscription entry such as “VLESS + TCP + REALITY” describes a configuration, not three interchangeable protocols.
The client and server settings must match field by field. If the server offers VMess, changing the client type to VLESS won't work. If the server uses WebSocket, you can't arbitrarily switch the client to raw TCP. A mismatch in the protocol, port, credentials, transport settings, or security layer can cause the connection to fail.
- Protocol layer: Determines how users are authenticated, how destination addresses are specified, and whether proxy traffic is encrypted by the protocol itself.
- Transport layer: Determines how proxy traffic is carried. WebSocket uses an HTTP upgrade, while gRPC typically runs over HTTP/2. Both require matching server support.
- Security layer: TLS validates certificates and protects the connection. REALITY requires a compatible implementation and matching parameters, such as the public key and server name; it isn't a drop-in replacement for standard certificate configuration.
- Routing layer: Determines which requests are proxied, sent directly, or blocked. Changing protocols won't fix DNS, routing rules, or apps that aren't using the proxy.
2. Encryption and Authentication Compared
| Protocol | Authentication | Data protection | What to check |
|---|---|---|---|
| VMess | UUID; the system clock must be correct | Common configurations use the protocol's own authenticated encryption; TLS can also be added | UUID, AEAD settings, encryption method, and transport parameters |
| VLESS | UUID | Traditional configurations use encryption: none and typically rely on TLS or REALITY to protect the connection | UUID, flow, security layer, and matching server parameters |
| Trojan | Password | Standard deployments rely on TLS to protect authentication and proxy traffic | Password, server name, and certificate validity |
| Shadowsocks | Encryption method and corresponding password or key | Uses the selected method for symmetric encryption; AEAD methods also provide integrity protection | method, key format, and TCP/UDP support |
Common VMess AEAD configurations use alterId: 0. Don't carry over a nonzero alterId from an old share link without checking: confirm the actual mode with the server administrator. An incorrect system clock can also affect VMess authentication. Enable automatic time sync before repeatedly changing the UUID.
In traditional VLESS, encryption: none means the protocol layer itself doesn't encrypt traffic. It doesn't mean that an outer TLS or REALITY layer isn't working. Conversely, a public connection using VLESS over raw TCP with no security layer shouldn't be considered private just because it uses a UUID. Check the core versions on both ends for support of any additional features.
Shadowsocks methods such as aes-128-gcm and chacha20-ietf-poly1305 are not interchangeable with Shadowsocks 2022 methods. The latter have specific key format and length requirements, so you can't simply reuse any text password. Even if both clients label the protocol “Shadowsocks,” they may not support the same methods.
Bottom line: check the full configuration before switching protocols
Record the full combination: “protocol + transport + security layer + authentication parameters.” If an existing node only times out, first check these four items and confirm the server is reachable. Changing the protocol name alone won't fix a blocked port or a certificate mismatch.
3. Handshake Overhead and Speed: Protocol Names Don't Tell the Whole Story
The wait when first opening a webpage can include DNS lookups, TCP connection setup, the TLS handshake, proxy authentication, and the destination site's response. A full TLS 1.3 handshake typically takes one round trip, and TCP setup has its own round-trip cost. Connection reuse and session resumption change the overhead for later requests, so record cold connections separately from download speeds over an established connection.
VMess and Shadowsocks provide encryption at the protocol level, but that doesn't mean every deployment is faster than a TLS-based setup. Results depend on factors such as AES hardware acceleration, server load, packet loss across network links, and congestion control. Trojan uses TLS, but once a long-lived connection is established, the initial handshake cost isn't added to every packet.
- Keep test conditions consistent: Use the same device, network, and destination, and close background downloads. Use the same server location where possible; otherwise, you're comparing network routes, not protocols.
- Test first requests and reused connections separately: Restart the connection and time the first request, then make repeated requests to the same destination. Don't treat results over a reused connection as first-handshake results.
- Repeat at least five times: Record the median, failure count, and sustained transfer performance. A single low-latency result doesn't show how reliable a connection is.
- Test UDP separately: A webpage loading only confirms that the relevant TCP path works. It doesn't tell you whether voice, gaming, or QUIC traffic works.
4. Transports, Ports, and Server Requirements
VMess and VLESS are commonly paired with transports such as raw TCP or WebSocket. Standard Trojan configurations use TLS; support for other transports depends on the implementation. The native Shadowsocks protocol doesn't include WebSocket or the semantics of a standard HTTPS website. To use a reverse proxy or CDN, check which transports the server supports rather than relying on the port number alone.
Setting the server port to 443 doesn't enable TLS or make the setup CDN-compatible. With WebSocket, the path must match: if the server uses /proxy-ws, the client can't use /. HTTP Host is used for relevant HTTP requests; TLS SNI is used to negotiate the server name. They serve different purposes, even if both fields contain a domain name.
- Standard TLS: The certificate must cover the server name in use and be within its validity period. Don't make skipping certificate verification your routine fix.
- VLESS + REALITY: Enter the public key, shortId, server name, and other fields as specified by the server. Selecting the REALITY option alone isn't enough to complete the configuration.
- VLESS flow:
xtls-rprx-visionisn't a universal speed boost. It must be supported by the transport, security layer, client, and server. - UDP: Check the server firewall, core support, client entry point, and specific transport. A working TCP connection doesn't confirm UDP support.
5. Choosing Between v2rayN, v2rayNG, and v2flyNG
A client provides the configuration interface and runtime entry point; its core implements the protocol features. On desktop, check which core v2rayN actually uses for the current configuration. v2rayNG for Android uses the Xray core, while v2flyNG for Android uses the v2fly core. Even if a share link imports successfully, check that fields such as flow, REALITY, and the Shadowsocks encryption method were preserved correctly.
v2rayNG: Xray configurations on Android
RecommendedIf the server explicitly offers VLESS + REALITY or a Vision configuration, first check the Xray core version bundled with v2rayNG and verify the imported fields. This recommendation is for using these configurations on Android; it doesn't mean they'll be faster on every network.
Best for: Android devices that need Xray features provided by the server
v2rayN: Check the core used on desktop
A good fit for managing multiple nodes and subscriptions on desktop. Before testing, check the node type, which core is being used, and its version. The client version and core version are separate; after updating the client, check whether the core was updated too.
Best for: Desktop use and centralized management of subscriptions and routing
v2flyNG: Match your configuration to v2fly support
A good fit for Android setups with configurations known to be compatible with v2fly. Don't transfer Xray-specific REALITY or Vision fields directly. Check other protocols and encryption methods against the actual core version too.
Best for: Existing v2fly configurations where you need to keep the same implementation
To check a configuration, open the node editor and review fields such as address, port, transport, and TLS one by one, then check the runtime logs. Menu names can vary between versions, so don't rely on old screenshots to find a setting. Share links using vmess://, vless://, trojan://, or ss:// use different parsing formats; changing the prefix doesn't convert one protocol into another.
6. Decisions for Existing Subscriptions and New Deployments
Decision order: get a working connection first, then control test variables
Existing subscription or service
- Use the protocol and parameters provided by the server; don't change the protocol type yourself.
- Prefer a configuration fully supported by the client core that passes real requests.
- Keep the routing and DNS policies consistent, and compare stability across nodes in the same region.
- Keep a working configuration before upgrading. Don't share subscription URLs or authentication details.
New deployment or server under your control
- If you need to deploy a standard TLS certificate, consider Trojan or VLESS + TLS.
- If you already have a stable VMess configuration, test compatibility and maintenance requirements first.
- If you need an encrypted proxy using symmetric encryption, check the Shadowsocks method and UDP support.
- If you need REALITY, first confirm that both ends use compatible Xray implementations and matching parameters.
Start with a working configuration you can reproduce, then change just one parameter at a time. Changing the protocol, transport, and route together makes it much harder to isolate the problem.
For regular web browsing, route quality and time to first connection often matter most. Sustained downloads depend more on bandwidth, congestion, and server resources. For voice and gaming, focus on UDP forwarding and jitter. There's no universal ranking based on claims like “VLESS is newer than VMess” or “Shadowsocks configurations are shorter.”
If you just need apps that ignore the system proxy to use the proxy, check TUN or the scope of Android's VPN routing before switching protocols. Proxy protocols handle data exchange between the client and server; whether app traffic reaches the client is a separate issue. See the client setup guide for related steps.
7. Common Protocol Selection Questions
VLESS uses encryption: none. Should I change it to AES?
For traditional VLESS configurations, keep none if that's what the server requires; don't apply VMess encryption settings. Instead, check that TLS or REALITY is enabled as specified by the server, and verify the server name and authentication parameters. If the server uses a specific extension, configure it according to the documentation for both core implementations.
The Trojan port is reachable. Why am I still getting a certificate error?
A reachable port doesn't mean TLS verification passed. Check the server name in the node editor, then verify that the certificate covers the domain, is within its validity period, and that the system clock is correct. If the server's certificate chain is incomplete, fix it on the server rather than leaving certificate verification disabled.
Why can't I connect after changing the Shadowsocks encryption method?
Check the method and password or key against the server settings. In particular, when switching from a traditional AEAD method to a 2022 method, confirm that the client supports it and that the key meets its requirements. Changing only the dropdown while keeping the old password usually isn't enough to migrate.
Why does the same VLESS link work in one client but fail in another?
Compare the core versions on both ends, along with the imported transport, security layer, flow, public key, and shortId. If the link uses Xray-specific features, use a compatible implementation. Find the exact failure stage in the logs before making changes; a successful import doesn't prove compatibility.
All four protocols time out. Should I keep trying them one by one?
Stop cycling through protocols. First check the local network, system clock, server address, and port. Then confirm the server is running and the firewall allows the connection. If several protocols use the same failing route, changing protocols won't fix an unreachable network path. For more basic checks, see Troubleshooting.