Start by separating the proxy protocol from the transport and security layers, then check the server settings and client core. This guide is for users choosing a subscription node, moving configurations between desktop and Android, or setting up their own server. By the end, you’ll know which fields each protocol requires, which combinations aren’t interchangeable, and what to check first when a connection fails.
1. Proxy Protocol, Transport, and Security Are Different Layers
VMess, VLESS, Trojan, and Shadowsocks define how a client authenticates with a proxy server and how requests are encapsulated and forwarded. TCP, WebSocket, and gRPC describe the connection or transport. TLS and REALITY are security mechanisms. Node names often combine details from several layers, so the protocol name alone doesn’t tell you everything about the configuration.
For example, VLESS + WebSocket + TLS and VLESS + TCP + REALITY both use VLESS, but they require different server entry points, handshake parameters, and network conditions. Changing the transport on the first node to TCP won’t turn it into the second. Without a matching server listener, the client will simply fail to connect.
- Proxy protocol: Determines whether authentication uses a UUID, password, or specific key material, and how requests are encapsulated.
- Transport: Determines whether the connection uses a direct stream or a transport such as WebSocket or gRPC. Available combinations depend on the client core and server implementation.
- Security layer: Determines how the connection is protected and how the server’s identity is verified. TLS typically requires the correct server name and a trusted certificate.
- Routing and traffic capture: System proxy, TUN, and domain-based routing control how traffic enters the client and where it goes. They aren’t properties of the four protocols themselves.
2. Encryption and Configuration Differences
When comparing encryption, ask two questions: Does the proxy protocol encrypt the payload, and is there an additional layer such as TLS? A field set to none doesn’t necessarily mean the whole connection is unencrypted. Likewise, using port 443 doesn’t prove that TLS is enabled.
| Protocol | Authentication and encryption | Common combinations | Fields to check |
|---|---|---|---|
| VMess | Identifies users with a UUID; modern configurations use VMess AEAD, with payload encryption determined by the security setting | TCP；WebSocket + TLS | UUID, security, alterId, transport, security layer, system time |
| VLESS | Identifies users with a UUID; the protocol itself does not encrypt the payload | TCP + TLS; WebSocket + TLS; TCP + REALITY with Xray | UUID, encryption, flow, TLS or REALITY parameters |
| Trojan | Password authentication; typical deployments rely on TLS to protect the connection | TCP + TLS; other transports require support on both ends | Password, port, server name, certificate verification, transport |
| Shadowsocks | Encryption uses a method and password or key material; AEAD and the 2022 series have different requirements | Native TCP and UDP forwarding; additional transports require extra support | method, password or key format, port, UDP support |
VMess: Check AEAD and legacy fields
Modern VMess configurations typically use alterId: 0 for AEAD. Don’t copy a non-zero alterId from an older guide into a current configuration. VMess authentication also depends on the system clock. If the time on Windows or Android is significantly off, enable automatic time synchronization before assuming the UUID is wrong. Whether to add TLS depends on the server setup.
VLESS: No built-in payload encryption doesn’t mean it should run in the clear
encryption: "none" is a common VLESS setting; TLS or REALITY provides connection protection. Don’t remove the security layer from a typical public-facing setup just because “VLESS has low overhead.” xtls-rprx-vision is a flow value for specific combinations. Don’t copy it to every WebSocket node or enable it on the client alone.
Trojan and Shadowsocks: More Than a Password Must Match
With Trojan, the TLS handshake can fail before authentication even if the password is correct, for example when the TLS server name is wrong. Shadowsocks requires an exact match for the encryption method: aes-128-gcm and 2022-blake3-aes-128-gcm are not interchangeable. The latter has specific key-format requirements; a regular password won’t do.
Bottom Line: Check the Security Layer Before Comparing Protocol Names
Check the node editor’s TLS or REALITY settings and certificate verification status. Don’t disable the security layer because VLESS uses encryption set to none, and don’t treat disabling certificate verification as a long-term fix for Trojan.
3. Choose by Use Case, Not by a Speed Ranking
With a subscription, the provider determines which options are available. If two nodes use different protocols and also differ in server, route, load, or exit, a speed test can’t show that one protocol is universally faster. For a self-hosted setup, first consider your certificate, domain, and network entry point, then choose a transport combination.
VLESS: For a New Xray Setup
RecommendedChoose TLS or REALITY based on your deployment, provided both the server and client support it. Check the UUID, security parameters, and flow. Don’t mistake “fewer parameters” for “the security layer is optional.” This recommendation applies to new configurations where you control the server.
Best for: Xray users who manage the server and can maintain the complete set of connection parameters
VMess: Keep a Proven Node
If an existing VMess AEAD node is stable and imports correctly on both desktop and Android, there’s no need to replace it. Before changing protocols, check legacy fields and time settings. Don’t rebuild a working server just to change its protocol name.
Best for: Existing subscriptions, WebSocket + TLS deployments, and compatibility with existing configurations
Trojan: When You Have a Domain and Certificate
A standard TCP + TLS setup has a relatively straightforward configuration, but you still need to maintain the certificate, DNS records, and server name. Troubleshooting should cover the TLS handshake as well as the password.
Best for: Users who can maintain certificates and have a Trojan server entry point
Shadowsocks: For Straightforward Encrypted Forwarding
Native connections keep the main settings in one place: method, key, and port. If you need UDP, verify server-side forwarding and network access separately. A webpage loading successfully isn’t enough to confirm UDP works.
Best for: Users with a matching server who want native TCP/UDP forwarding
None of these four protocols guarantees anonymity. Server operations, DNS routing, app sign-in status, and client routing settings can all affect the results. Choose based on your deployment constraints, not assumptions about security based on a protocol’s name.
4. Support Boundaries in v2rayN, v2rayNG, and v2flyNG
v2rayN is a desktop client, v2rayNG is an Android client that uses the Xray core, and v2flyNG uses the v2fly core. Clients manage nodes and generate configurations; the core actually implements the protocols. A client recognizing a subscription entry doesn’t guarantee that its current core supports every extension in it.
| Client | Where to check | What to consider |
|---|---|---|
| v2rayN | Protocol, transport, and security settings in the node editor; core details in the startup log | Check the core actually in use on desktop; VLESS + REALITY requires a compatible Xray core and matching parameters |
| v2rayNG | Long-press a node → Edit; check startup errors on the log screen | The four basic protocols work when configured accordingly; newer extensions depend on the Xray version bundled with the app |
| v2flyNG | Node editor, app version, and startup log | Check what the v2fly core actually supports; Xray-specific REALITY and Vision parameters can’t be carried over as-is |
Migration: Check the Protocol Family, Then the Extension Fields
Desktop: v2rayN
- After importing, open the node editor and verify the address, port, transport, and security layer.
- For REALITY, check the public key, shortId, server name, and fingerprint settings.
- After startup, check the core log. Fix configuration parsing errors before testing a webpage.
Android: v2rayNG or v2flyNG
- Use a core that matches the server parameters; don’t compare only the protocol names shown in the app.
- Before switching to v2flyNG, check for Xray-specific extensions.
- Check system VPN permission and per-app settings so you don’t mistake a traffic capture issue for a protocol problem.
Using the same subscription URL avoids duplicate entry, but whether both clients can use the same node depends on core support. Update the subscription separately in each client.
5. Use Ports and Logs to Pinpoint Connection Failures
The three port numbers below illustrate different port roles. They aren’t defaults for every client or deployment requirements. The server’s inbound port and the local proxy listening port are at opposite ends of the connection and can’t be used interchangeably. Check the node configuration and the actual local listening port before entering a value.
- First, confirm the core starts. If the log shows a configuration parse error, an unknown field, or a port conflict, fix the configuration first. Testing protocol speed at this point is meaningless.
- Next, confirm the app is capturing traffic. On desktop, check that the system proxy points to the active listening port. On Android, check that the VPN is connected and the target app isn’t excluded.
- Check that the server is reachable. For a connection timeout, verify the address, inbound port, firewall, and that the service is running. A timeout alone doesn’t mean the UUID is wrong.
- Separate the security handshake from user authentication. For certificate errors, check the system time, server name, and certificate chain first. For authentication errors, verify the UUID, password, key, and encryption method.
- Finally, check the transport parameters. For WebSocket, verify path and Host; for gRPC, check serviceName; for REALITY, check the server-provided public key, shortId, and other fields.
For example, if the local SOCKS listener is confirmed as 127.0.0.1:10808, use the command below to test whether a request passes through the client. It uses a domain-based test page and contains no subscription credentials. If your port differs, use the actual value.
curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 https://example.com/socks5h means the SOCKS proxy resolves the destination domain. This test bypasses system proxy settings, but not the core’s routing rules: if the domain is routed directly, a successful response doesn’t prove that the remote proxy can reach the internet. Check the matched rule and outbound in the logs before drawing a conclusion.
6. How to Make a Fair Performance Comparison
Between different routes, latency, congestion, packet loss, and server load often matter more than protocol overhead. The names VMess, VLESS, Trojan, and Shadowsocks can’t be translated directly into throughput. Results also depend on hardware encryption acceleration, extra transports, and whether test traffic uses the same outbound route.
- Same device and network: Don’t compare results from a wired desktop connection with those from an Android mobile network.
- Same server and exit: Change only the protocol combination where possible, keeping the region, bandwidth, and test target the same.
- Same test window: Run each setup at least 3 times and record connection time, sustained transfer speed, and failures separately.
- Test TCP and UDP separately: A webpage loading successfully only confirms that the corresponding request worked; it doesn’t prove UDP forwarding is working.
- Record the full combination: Write “VLESS + TCP + REALITY,” not just “VLESS,” so the results include the conditions that matter.
Bottom Line: Keep Stable Setups and Change One Variable at a Time
Export a recoverable configuration first, then change only one setting at a time—and only when the server supports it. Consider replacing your everyday node only after 3 consecutive tests show improvement and the logs confirm the same outbound route.
7. Protocol Choice FAQs
VLESS encryption is set to none. Should I change it to AES?
No. This VLESS field isn’t an encryption method selector like the ones used by VMess or Shadowsocks. Open the node editor and check that the security layer is set to TLS or REALITY as required by the server, then verify the relevant parameters. Don’t enter an algorithm from another protocol in the encryption field.
Why does Trojan report a certificate error on port 443?
The port doesn’t verify identity. First enable automatic time synchronization, then compare the TLS server name with the domain covered by the server certificate. Check whether the certificate has expired and whether the chain is complete. The connection address and server name can differ, but the latter must match the deployment requirements. Don’t leave certificate verification disabled as a long-term workaround.
The same subscription works in v2rayNG but not v2flyNG. What should I do?
Open the node editor and check whether the configuration includes REALITY or xtls-rprx-vision. These Xray extensions aren’t generic VLESS parameters you can carry over. Use a compatible node provided by the server or a matching core. Don’t simply delete fields that trigger errors; the server may require them.
Shadowsocks loads webpages, but game traffic fails. Did I choose the wrong protocol?
First check whether the game uses UDP. Then verify that UDP forwarding is enabled on the server, the relevant ports are allowed through the firewall, and the client’s traffic capture covers the app. A successful TCP webpage test doesn’t replace a UDP test. Compare other protocol combinations offered by the server only after checking these conditions.
My existing VMess node is stable. Should I switch everything to VLESS?
There’s no need to migrate based on the protocol name alone. First verify that the current configuration uses modern AEAD, the system time is correct, and the security settings match the deployment. If you need new features or easier maintenance, add a matching VLESS server configuration and test it before migrating. Don’t overwrite your only working node.