If you already have a subscription, start with a complete node configuration that connects reliably—not a ranking of protocol names. If you manage your own server, compare authentication, transport security, and device overhead. This guide explains all four protocols and offers recommendations for desktop, Android, and low-spec devices. You’ll also learn which settings to check when importing a node and how to tell whether switching protocols can actually improve speed.
Know the difference between proxy protocols, transports, and encryption
VMess, VLESS, Trojan, and Shadowsocks are proxy protocols, not four client apps. v2rayN is a desktop client; v2rayNG is an Android client that uses the Xray core; v2flyNG is an Android client that uses the v2fly core. Clients manage nodes and run a core; the supported protocols and settings depend on the core and its version.
A node usually involves more than one protocol label. For example, VLESS + TCP + REALITY combines a proxy protocol, a transport, and a security mechanism. WebSocket is not another name for VMess, and TLS is not exclusive to Trojan. Speed comparisons that say only “VLESS vs. VMess” leave out the transport, encryption, and network route—and usually aren’t enough to draw a useful conclusion.
- Proxy protocol: Defines how users are authenticated, destination addresses are specified, and data is forwarded—for example, VMess or VLESS.
- Transport: Determines how proxy traffic is carried, such as over TCP or WebSocket. Both ends must use a compatible combination.
- Security mechanism: TLS, REALITY, and similar mechanisms provide handshake and transport protection. Support depends on the core.
- Routing and traffic capture: System proxy settings, TUN, and routing rules determine which apps use the proxy; they do not change the remote protocol.
That’s why nodes using the same protocol can behave very differently. Egress location, peak-hour load, cross-network packet loss, and relay routes often affect page loads and download speeds more than the protocol itself.
How the four protocols differ in design, authentication, and encryption
Shadowsocks began as a lightweight encrypted proxy. VMess is an authentication and encryption protocol in the V2Ray ecosystem. VLESS uses a leaner protocol structure that separates some responsibilities. Trojan typically relies on TLS to protect proxy connections. These protocols were designed with different goals; they shouldn’t be treated as a simple old-to-new performance ranking.
| Protocol | Authentication credentials | What it protects | What to check when importing |
|---|---|---|---|
| VMess | UUID; authentication depends on system time | Supports protocol-level data encryption; TLS can also be added | UUID, encryption settings, system time, and transport parameters |
| VLESS | UUID | Connections are commonly protected with TLS or REALITY | Security type, server name, flow control, and related public key parameters |
| Trojan | Password | Standard configurations rely on TLS for transport protection | Password, server name, and certificate validation |
| Shadowsocks | Password or a key required by the selected method | Proxy data is protected by the selected encryption method | Encryption method, key format, and server compatibility |
VMess: Keep existing configurations working and check the time and authentication settings
VMess is a practical choice for existing nodes that are already working reliably. Newer configurations should use AEAD authentication; the nonzero alterId values found in older guides are legacy settings, not a general recommendation for new nodes. Authentication is sensitive to system time, so enable automatic time synchronization first if the connection fails. A correct UUID doesn’t guarantee that the WebSocket path, Host, or TLS server name is correct.
VLESS: Lightweight doesn’t mean you can skip the security layer
In common VLESS configurations, encryption=none means this layer does not apply conventional payload encryption; it does not mean the entire connection is unencrypted. With TLS or REALITY, the corresponding security mechanism protects the connection. Don’t expose a public node over an unprotected connection. REALITY and features such as Vision also require a compatible Xray core; an Xray configuration should not be assumed to work with every v2fly core.
Trojan and Shadowsocks: Check TLS and the encryption method
Trojan typically uses password authentication and TLS to protect traffic. Check the certificate validation settings and server name. Shadowsocks requires an explicit encryption method, such as chacha20-ietf-poly1305. Shadowsocks 2022 uses a separate set of methods with specific key requirements—you can’t simply change the method name and reuse any old password. Neither protocol will connect just by entering a server address.
Bottom line: Check the full configuration before checking protocol support
Match the node’s protocol, transport, security type, and authentication fields one by one. A matching protocol name alone doesn’t guarantee that a client can connect. Don’t disable certificate validation as a substitute for a correct configuration.
Choose by use case: everyday browsing, legacy subscriptions, and low-spec devices
The recommendations below are for users who can choose their server configuration. If you only have access to a subscription, use the settings provided by its operator. Changing a client from VMess to VLESS does not make the remote server support another protocol.
VLESS + TLS or REALITY
RecommendedFor a new node, consider this combination when both ends support it. Configure all parameters to match; if using Vision, the server and client flow-control settings must also agree. This is a deployment option, not a guarantee of faster speeds on every network.
Best for: Everyday connections on a server you manage, with Xray support verified.
VMess
Keep using a node that already works reliably. If the server uses WebSocket + TLS, preserve the path, Host, and server name. There’s no need to rebuild a working configuration just to change protocols.
Best for: Existing subscriptions or deployments where you need to keep the current connection setup.
Trojan
When the server has a correctly configured TLS setup, the password and certificate fields are relatively straightforward. Check the server name and certificate chain before trying to optimize performance.
Best for: Setups with a working certificate and domain that use a standard TLS configuration.
Shadowsocks AEAD
When both ends support the same method, the configuration has relatively few fields, making it worth evaluating on low-spec devices. Whether AES hardware acceleration is available can affect its real-world overhead compared with ChaCha20 methods.
Best for: Devices and setups where simple configuration and CPU usage matter.
“Lightweight” describes only some processing costs. On a low-spec device, routing unnecessary direct traffic through the proxy can have a bigger impact than changing protocols. Set up your routing rules first, then compare CPU usage and throughput on the same route to avoid mistaking routing differences for protocol advantages.
Save battery on mobile and stay stable on desktop: adjust traffic capture separately
You can’t judge Android battery use by protocol name alone. Weak signal, frequent reconnects, background apps that stay online, and whether the proxy connection remains active all affect battery life. Without tests on the same device and network, there’s no basis for claiming that one protocol always saves a specific amount of power.
Configuration plan: Use the same candidate nodes and control which traffic goes through the proxy
Desktop: v2rayN
- Start by testing browser access through the system proxy, then enable TUN if needed.
- Check the active listening port under Settings → Parameter Settings; menu names may vary by version.
- Keep direct-connection rules in place and pause downloads and background system updates during tests.
Android: v2rayNG / v2flyNG
- Use per-app proxy settings to include only the apps that need it; don’t broaden the test unnecessarily.
- Keep the network, screen brightness, and test duration the same, then record battery use.
- With v2flyNG, check core support first; don’t assume Xray-specific combinations will work.
Sharing a subscription doesn’t mean both clients support every node equally. Keep compatible nodes for each client and test under the same conditions.
If the connection drops frequently when the screen is off, check background activity restrictions and reconnect entries in the logs first. Don’t immediately blame VMess or Trojan. Relaxing battery restrictions may keep the connection alive longer, but can also increase background activity; decide based on how you use the device.
How to benchmark proxy speed: Fix the port, route, and test conditions first
A port number does not identify a protocol. Port 443 is commonly used for TLS services, but changing any node to 443 does not enable TLS. A local listening port only handles connections between apps and the client. The three numbers below illustrate different configuration roles; they are examples, not recommended defaults to apply across the board.
Use the port shown in your client’s current interface. Some versions use a mixed listener and don’t require separate HTTP and SOCKS ports. The remote port must match the server. If a local listener is only for use on your device, bind it to the loopback address to avoid exposing it to your local network.
- Keep the egress server the same: Compare protocols on the same server whenever possible. Subscription nodes in different regions only let you compare the overall node experience, not isolate the effect of the protocol.
- Keep the task consistent: Test the same download URL for three consecutive 60-second runs. Record average throughput, failures, and CPU usage. This is a testing method, not a set of results from this article.
- Test both cold connections and sustained transfers: First-page loads depend more on handshakes, DNS, and round-trip latency; large downloads reveal sustained throughput more clearly.
- Record the complete configuration: Note TLS, transport, flow control, multiplexing settings, and core version. Don’t just write “VLESS is fast.”
- Retest at peak times: If the difference between protocols is smaller than the variation between test runs, prefer the configuration with fewer failures and simpler maintenance.
Bottom line: Find the bottleneck before switching protocols
It’s worth focusing on encryption and encapsulation overhead only when CPU usage stays near 100%. If CPU usage is low but every node is slow, check the route, packet loss, and server-side rate limits first. Switching protocols won’t fix those bottlenecks.
Can’t connect after importing? Four common issues
A subscription distributes node settings; it can’t add capabilities to an incompatible core. After updating a subscription, check that all node fields are present, then review the client logs. Hide UUIDs, passwords, subscription URLs, and other authentication details before sharing troubleshooting information.
VMess: The UUID is correct, so why is authentication still failing?
First, enable automatic time synchronization in your system’s date and time settings, then check that the server still has the user enabled. For an older node, look for legacy alterId settings; don’t blindly copy settings from an old guide. Finally, compare the transport and TLS parameters one by one.
VLESS imports successfully, so why does the connection report that it’s unsupported?
A successful import only means the client recognized the link format. Check which core is actually running and whether the node uses features such as REALITY or Vision. Add any missing security parameters. If the core doesn’t support them, choose a compatible node instead of removing flow-control settings and hoping for the best.
Trojan reports a certificate error. Can I skip validation?
First, correct the system time, then confirm that the server name matches the server certificate. Ask the server administrator to check the certificate’s validity period and chain. Don’t treat skipped validation as a permanent fix: it weakens verification of the remote server’s identity.
Shadowsocks: The password is the same, so why doesn’t it work in another client?
Check the encryption method, server port, and key format together. In particular, don’t use a traditional AEAD password as a fixed-length Shadowsocks 2022 key. Confirm that both ends support the same method, then check your UDP and routing requirements.
How to choose: Compatibility first, reliability next, resource use last
For everyday browsing, choose a node with a reliable route and complete, working settings. For a new deployment, consider a secure VLESS configuration; there’s no need to replace a working VMess or Trojan setup just because of its name. On low-spec devices, test options such as Shadowsocks AEAD, and decide based on CPU usage, connection failures, and throughput on your own device.
- Check compatibility first: Can the current core run the protocol, transport, security mechanism, and flow-control settings together?
- Then check reliability: Does the connection drop frequently during your usual hours? Do websites and apps work as expected?
- Optimize last: Only tests under consistent conditions can show whether switching protocols helps.
For terminology, see the protocol glossary. Before entering security settings, read the protocol reference. Keep a verified working configuration, then change one setting at a time. It’s easier to find problems that way than by changing the protocol, DNS, routing, and core all at once.