A protocol name alone doesn’t determine speed, security or battery use. First, understand how protocols, transports and security layers fit together. Then compare the settings for all four protocols and follow practical steps for choosing one for desktop work, commuting or weak networks. This guide is for users with a subscription who need to choose a primary server. Make your choice based on the server configuration and real-world connection performance—not just the node name.
Protocols, Transports and Security Layers: Understand the Full Connection
v2rayN is a desktop client, not a protocol. It manages subscriptions, builds configurations and runs connections through a core. On Android, v2rayNG uses the Xray core, while v2flyNG uses the v2fly core. Similar names don’t mean they support identical configurations. Check that the client’s core supports each feature you need, especially VLESS extensions and REALITY.
A node typically has three layers: the proxy protocol defines authentication and how data is organized; the transport carries the data; and the security layer encrypts and authenticates the connection. For example, “VLESS + TCP + REALITY” and “VLESS + WebSocket + TLS” both use VLESS, but have different handshake flows, server setups and failure points.
- Proxy protocol: VMess, VLESS, Trojan or Shadowsocks. The client and server must use compatible implementations.
- Transport: TCP, WebSocket and others. You can’t swap these freely on the client; they must match the server configuration.
- Connection security: TLS, REALITY or encryption built into the protocol. Not every protocol needs the same additional security layer.
- Routing rules: Determine which connections use the proxy, connect directly or get blocked. They’re separate from the node protocol.
Comparing the Four Protocols: Background, Encryption and Configuration
Shadowsocks began as a lightweight encrypted proxy and later added AEAD and 2022-series methods. Developed for the V2Ray project, VMess combines user authentication with data encryption. VLESS has a leaner design and typically relies on an external security layer to protect the connection. Trojan carries proxy sessions over TLS and depends on valid certificate verification and correct server configuration.
| Protocol | Authentication and encryption | What to check after importing | Common pitfall |
|---|---|---|---|
| VMess | Identifies users with a UUID; modern configurations use AEAD authentication and can specify a data encryption method. | UUID, encryption options, alterId, transport type and TLS settings. | Copying a nonzero alterId from an old configuration to a new server without checking whether it’s required. |
| VLESS | Authenticates with a UUID. The common encryption=none setting doesn’t encrypt the payload on its own; it’s usually paired with TLS or REALITY. | UUID, flow, security layer, and REALITY parameters such as the public key and shortId. | Assuming none means the entire connection is unencrypted—or overlooking the security layer. |
| Trojan | Usually uses password authentication, with TLS to protect the connection. | Password, server name, port and certificate verification settings. | Leaving “Allow insecure” enabled to bypass certificate errors. |
| Shadowsocks | The selected encryption method defines key and data protection. Each method may require a different key format. | Encryption method, password or key, port, and any required transport plugin. | Entering a 2022-series key as if it were any ordinary text password. |
The VLESS notes here apply to common encryption=none deployments; they don’t mean every core version and later extension uses this one configuration. Shadowsocks AEAD and 2022-series methods aren’t interchangeable by name alone: the client core, server implementation and key format must all match.
Port numbers identify configuration details; they don’t prove which protocol is running or whether a connection is secure. Port 443 can carry a non-TLS service, and a correctly configured TLS service can use another port. Always use the complete parameters provided with your subscription.
Handshake Overhead and Speed: Why There’s No Fixed Protocol Ranking
When a page first loads, the wait may include DNS lookup, connecting to the server, the security handshake, the proxy request and the destination’s response. WebSocket usually adds an upgrade request, and intermediate relays can change the route. A shorter protocol header doesn’t guarantee a faster first page.
Sustained downloads are a different matter. Once the connection is established, available bandwidth, congestion, packet loss, server load and device encryption performance often matter more. VMess with TLS may add processing overhead, but that doesn’t prove its real-world throughput will always be lower than VLESS. A single speed test can’t establish a protocol-level difference between nodes in different regions or from different providers.
- Keep test conditions consistent: Choose candidates in the same data center, with similar exits and the same transport and security layers. If you can’t, describe the results as a “node comparison,” not a “protocol comparison.”
- Track two types of metrics: For short connections, record time to first successful connection and failure count. For sustained connections, track interruptions and throughput stability.
- Run each candidate three times: Use the same destination and time window, alternating between candidates so a brief bout of congestion isn’t mistaken for a protocol difference.
- Test the tasks that matter: For work, check web logins and meeting reconnects; for commuting, test recovery after switching networks. Don’t rely on a single peak-speed screenshot.
Bottom line: Rule out network differences before comparing protocol overhead
If you can’t compare configurations on the same server, choose your primary node by connection success rate and performance on real tasks. Don’t attribute speed-test results from different exits to VMess or VLESS.
Choosing a Protocol for Desktop Work: Keep a Proven Setup
For work, reliable connections and easy troubleshooting matter most. If your subscription is already stable, there’s no need to rebuild everything just to change protocol names. For a new deployment, consider VLESS with a correctly configured security layer if both ends support it. If your setup already depends on VMess, Trojan or Shadowsocks, weigh compatibility and maintenance needs just as carefully.
VLESS + TLS or REALITY
RecommendedA strong option to evaluate for a new deployment, provided the client and server support the same parameters. TLS requires proper certificate verification. For REALITY, check the public key, server name, shortId and applicable flow; don’t copy values from another node.
Best for: Desktop work when you can verify server settings and use a compatible core
Trojan + TLS
A natural fit when you already have a domain and a certificate management process. Configuration typically centers on the password and TLS settings, but a strong password doesn’t make certificate verification optional.
Best for: Setups with a reliable TLS service and an established certificate maintenance process
VMess
Keep an existing VMess subscription if it’s configured correctly and works reliably in your client. If connections fail, check the system clock, UUID and transport parameters before switching protocols.
Best for: Existing VMess subscriptions that need to remain compatible with the current deployment
Shadowsocks AEAD or 2022-Series Methods
A direct deployment can keep configuration relatively simple. First confirm both ends support the same encryption method, then check the key. If the server requires an additional plugin, verify that the client supports it too.
Best for: Setups with a clear configuration path that aim to avoid an extra transport layer
In v2rayN, open Settings → Parameter Settings to check the local listening port, then check the system proxy status on the main screen. Field groups may vary by version, so use the interface you have. The system proxy affects only apps that follow that setting; an app connecting directly doesn’t necessarily mean the protocol is broken.
Commuting and Weak Networks: Check Reconnection, UDP and Battery Use
You can’t rank battery use by protocol alone. Screen brightness, mobile signal strength, background apps, routing scope and keepalive behavior all affect power consumption. Repeated reconnects in a weak-signal area may use more power than protocol encryption. Avoid unsupported claims such as “VLESS always saves X% battery.”
Switching protocols won’t eliminate packet loss on a weak network. These four protocol names aren’t four different congestion-control algorithms. Check whether the outer transport uses TCP or another method, whether the server supports UDP forwarding, and what transport the app itself uses. A working web page doesn’t prove the UDP path needed for voice calls works too.
Compare Setups: Test Fixed and Mobile Networks Separately
Desktop: v2rayN
- Choose one node and test sign-ins, file uploads and meeting connections first.
- Keep routing rules the same so direct and proxied connections aren’t mixed in one test.
- Record failures in each round and keep a tested backup node.
Android: v2rayNG
- Test on Wi-Fi and mobile data separately, then switch networks once and check reconnection.
- Set up per-app proxying for the apps you need to route, reducing unnecessary background proxy connections.
- Compare system battery stats over the same usage period, keeping brightness and tasks similar.
Change only one node or routing setting at a time. You can use the same subscription on both devices, but check core compatibility and import results on each one.
If you use v2flyNG, choose nodes based on what its bundled v2fly core actually supports. Don’t assume configurations generated for Xray-specific features will work everywhere. For mobile, prioritize reliable reconnection, support for the apps you need and acceptable battery use under the same workload.
Can’t Connect After Importing? Troubleshoot by Layer
First distinguish a server connection failure from a local app that isn’t using the proxy. Check that the node address and port are reachable, then verify authentication, transport and security settings. Finally, check the local system proxy, DNS and routing. Connection timeouts, authentication failures and certificate errors point to different problems; avoid changing several settings at once.
VMess imports successfully but won’t connect. What should I check?
Sync the system clock first, then check the UUID, alterId and server requirements. Modern AEAD configurations typically use alterId=0. Next, verify the WebSocket path, Host and TLS status. A successful import only means the configuration can be parsed, not that it matches the server.
My VLESS node has a UUID. Why is authentication still failing?
The UUID is only one parameter. Check whether the security type is TLS or REALITY, then compare flow, server name, public key and shortId. Don’t change flow to a different value yourself; get a complete configuration that matches the server.
Trojan reports a certificate error. Can I just skip verification?
Don’t treat skipping verification as a permanent fix. Check the device clock and server name first, then ask the server administrator to check the certificate’s validity period, certificate chain and domain match. Even when connecting directly by IP, use the correct TLS server name and verification settings.
My Shadowsocks password is correct. Why can’t I connect?
Check the encryption method and port too. 2022-series methods require keys in the correct length and format; you can’t substitute any ordinary password. If web browsing works but calls fail, check server-side UDP forwarding, firewall rules and app routing.
A speed test says the proxy works, but my browser can’t open pages. Why?
Check the system proxy status on the v2rayN main screen, then go to Settings → Parameter Settings to verify the local port. Apps with manual proxy settings must use the same port. Next, check DNS and routing matches. Don’t change the protocol on a node that already works.
Final Checklist: Turn Protocol Names into Verifiable Requirements
For most users, the most practical order is: confirm full client support, verify the server configuration, test reliability on real tasks, then compare small performance differences. The protocol sets capability boundaries, while network routes and deployment shape much of the real-world experience. Consider them together.
- Already have a working subscription? Keep the stable node instead of switching protocols just for a newer name.
- Setting up a new desktop connection? First evaluate a compatible VLESS security setup; Trojan may also fit if it works with your existing certificates and server setup.
- Commuting with a phone? Compare recovery after network switches and real battery use. Confirm the Android client’s bundled core supports every parameter.
- On a weak network? Check packet loss, reconnection and the UDP path required by your apps first. Keep backup nodes on different routes.
- Need help troubleshooting? Share the client and core versions, transport and redacted logs. Don’t publish subscription URLs, UUIDs, passwords or private keys.