VMess, VLESS, Trojan, and Shadowsocks Compared: Protocols, Differences, and Use Cases

At a glance

Start with the protocols your server supports, then check client-core, transport, and security-layer compatibility. This guide explains how encryption differs across four protocols, recommends options for desktop, Android, and multi-device use, and shows how to compare them under consistent test conditions. For users with a node or subscription who need to check whether their setup is compatible.

Understand protocols, transports, security layers, and clients

“VLESS + WebSocket + TLS” in a node name does not mean three competing protocols. VLESS defines proxy requests and authentication, WebSocket carries the data, and TLS protects that connection. The label “VLESS” alone is not enough to judge speed or security.

v2rayN is a desktop client, not a fifth proxy protocol. It imports and selects nodes and manages runtime settings; the selected core handles the actual connection. On Android, v2rayNG uses the Xray core, while v2flyNG uses the V2Fly core. Even clients from the same core family may not support the same features across versions.

Proxy protocol: VMess, VLESS, Trojan, and Shadowsocks define how the client and server exchange proxy requests.
Transport: TCP, WebSocket, or gRPC, for example; it must match the transport enabled on the server.
Security layer: TLS and REALITY each have their own configuration requirements. Switching a dropdown alone does not convert a setup.
Routing and traffic capture: Determines which apps and destinations use the proxy; it is separate from the node protocol.

Encryption and compatibility across four protocols

Compare complete configurations rather than labeling a protocol “the fastest” or “the most secure.” The table covers common deployments; supported fields still depend on the node provider’s documentation, core version, and configuration requirements.

Protocol	Authentication and encryption	Key settings	When it makes sense to keep it
VMess	Usually authenticated with a UUID; modern deployments use VMess AEAD. Data encryption depends on the configuration.	UUID, encryption settings, transport parameters, and device time.	You already have a stable endpoint and the client and server settings match.
VLESS	Usually authenticated with a UUID; common configurations set the protocol encryption field to none, relying on the accompanying security layer for protection.	TLS or REALITY settings; with Vision, also check flow and transport support.	The server provides a complete configuration and the client core supports that combination.
Trojan	Password-based authentication; common deployments protect proxy traffic with TLS.	Password, server name, certificate validation, and port.	You already have a well-maintained TLS endpoint and want straightforward settings.
Shadowsocks	Uses a pre-shared key; modern AEAD methods and Shadowsocks 2022 methods have different key requirements.	Encryption method, key format, and TCP/UDP support.	You already have a compatible modern encryption method and want a simpler connection setup.

VMess: Check AEAD and device time for existing configurations

VMess is not automatically unusable just because a node is older. If an existing connection is stable, there is no need to switch protocols based on the name alone. For modern VMess configurations, alterId is commonly 0; do not copy old tutorials and enter a nonzero value without a reason. A significant clock difference can cause authentication to fail. When troubleshooting, enable automatic time synchronization first, then check the UUID and transport settings.

VLESS: A lightweight protocol still needs a security layer

For common VLESS nodes, encryption=none does not mean the entire connection is unprotected: check whether TLS or REALITY is configured on the outer layer. But do not assume this field means the connection is secure by default, either. REALITY and Vision are not synonyms for VLESS, and support for each must be confirmed. Do not add fields the node provider has not specified.

Trojan and Shadowsocks: Matching passwords do not guarantee compatibility

A Trojan password does not replace TLS certificate validation. If you see a certificate error, check the domain, server name, and certificate chain rather than disabling validation permanently. Shadowsocks requires both the encryption method and key to match. For example, chacha20-ietf-poly1305 and 2022-blake3-aes-128-gcm are not interchangeable; the latter also requires a key in the specified format.

Everyday desktop use: Choose a complete configuration that works reliably

The recommendations below apply to new primary configurations when you can choose the server setup and your client supports the relevant features. They are not a universal ranking. If an existing node reliably meets your needs, keeping it is usually easier than switching protocols repeatedly.

VLESS: Complete security-layer configuration

Recommended

For a new endpoint, consider a VLESS + TLS or REALITY setup offered by the server. Check core support, server name, and required settings; do not combine configurations from different nodes.

Best for: A primary desktop connection when you control the server and are willing to maintain the configuration.

Trojan: Ready-to-use TLS endpoint

If you already have a domain, certificate, and stable server, use the provider’s settings as supplied. Certificate renewals and password management are still part of ongoing maintenance.

Best for: Keeping an existing, working TLS deployment and endpoint.

Shadowsocks: Simple configuration

Choose a modern encryption method supported by both client and server. There are fewer settings, but performance still depends on network conditions; a simpler setup does not guarantee faster speeds on every network.

Best for: Everyday connections with a stable server and a preference for simple settings.

VMess: Keep a stable existing node

If your subscription already includes a working VMess node, test access before making changes. Keep its matching transport and security settings; do not migrate just because of the protocol name.

Best for: Setups where the existing subscription and devices are already working reliably.

To test v2rayN on Windows, open the “System Proxy” menu on the main screen and select “Set system proxy automatically,” then check whether your browser follows the system proxy. Menu labels may differ by version. On Linux and macOS, also check the proxy settings for your desktop environment. Switching the active node does not route traffic from every app.

How to measure resource use: Separate ports, latency, and throughput

Changing routes can make a bigger difference than changing protocols on the same route. Hardware acceleration, TLS handshakes, transport overhead, and packet loss all affect results. Claims such as “VLESS always uses less battery” or “Shadowsocks is always faster” have no meaning without test conditions.

443

Common TLS server port; check the actual configuration

10808

Example of a local listening port; check the client settings

8388

Example Shadowsocks server port; not a fixed requirement

These three ports illustrate the difference between a remote endpoint and a local listening port. Using 443 remotely does not automatically provide all the properties of HTTPS or prove that the certificate is valid. If you need to configure a browser proxy manually, enter the local address and listening port for the relevant protocol—not the remote server address.

Keep conditions consistent: Use the same server, network, and test destination where possible. Keep routing mode fixed so one test is not direct while another uses the proxy.
Check connectivity first: TCPing only shows whether the port is reachable; it does not confirm that authentication, TLS, or a proxy request succeeded. Follow up with a real connection test and an actual website visit.
Repeat measurements: Run five real connection tests for each setup. Record failures and the median of successful results; do not report only the lowest value.
Then test sustained load: Access the same test resource for 60 seconds and record throughput and CPU usage. On mobile, also compare battery use over the same period. Do not rank protocols from a single short test.

Android battery life and multi-device use: Control what gets routed first

On mobile, battery drain often comes from background apps that stay online, frequent reconnects, or weak signal—not just encryption. v2rayNG’s local VPN traffic capture is separate from the remote proxy protocol: enabling the local VPN interface does not change the protocol used by the remote node.

For everyday use, check “Settings” → “Per-app proxy” in v2rayNG and confirm whether the mode proxies only selected apps or bypasses selected apps; wording varies by version. If only your browser needs the proxy, reduce unrelated background traffic before comparing battery use across protocols for more meaningful results.

Using desktop and Android together: Share a subscription, verify each client separately

Desktop: v2rayN

Choose a core that supports the required protocol and transport.
After importing, check the server, port, and security-layer settings.
Choose system proxy or another traffic-capture method to suit your apps.
After updating the subscription, confirm which node is active.

Android: v2rayNG / v2flyNG

v2rayNG uses Xray; v2flyNG uses V2Fly.
Check whether the installed version supports the node’s features.
Configure per-app proxy and routing rules as needed.
Test the connection on both Wi-Fi and mobile data.

Using the same subscription helps keep the configuration source in sync, but different cores and versions may not parse the same nodes into identical working configurations.

For multiple devices, also check the provider’s device, concurrent-connection, and traffic limits. Subscription URLs often contain access credentials, so do not share them publicly like ordinary web addresses. For a self-hosted service where you need to revoke access per device, assign each device its own UUID, password, or key—provided the server supports multi-user configurations.

Connection failures and UDP requirements: Troubleshoot by symptom

Video playback does not prove UDP is working, and a page that will not load does not necessarily mean the protocol is wrong. First distinguish between a client that has not started, failed authentication, a certificate error, DNS resolution failure, and a routing mismatch. Then decide whether to switch nodes.

The node latency is low. Why will web pages not load?

First check whether the displayed result is TCPing or a real connection test. In v2rayN, verify the active node and system proxy status, then check the client logs for authentication, TLS, or port-in-use errors. Finally, check the browser’s own proxy settings to make sure it is not bypassing the system proxy.

VLESS imported successfully. Why does the connection fail immediately?

Check the server, port, UUID, transport, and security layer one by one. For a REALITY endpoint, also check provider-required fields such as the public key, shortId, and server name; a Vision setup must have the matching flow. Successful import only means the link was parsed—it does not mean the core supports every field.

Trojan reports a certificate error. Can I just skip validation?

First correct the device clock. Then check that the server name matches a domain covered by the certificate, that the server certificate has not expired, and that the certificate chain is complete. Do not use permanently disabled certificate validation as a substitute for fixing the problem. If you connect by IP, keep the correct server name configured as well.

Voice chat or games need UDP. Can all four protocols use it out of the box?

A protocol’s ability to carry UDP does not mean it will work on your current route. Check local traffic capture, core support, server-side UDP forwarding, and firewall rules. Shadowsocks native UDP forwarding usually requires the relevant UDP port to be open. Common Trojan implementations encapsulate UDP over a TLS connection, so test performance under packet loss.

Choosing a protocol: Prioritize compatibility, reliability, and maintenance

If you have a subscription, the most effective order is to import it, verify feature support and real-world access, and then compare performance. For a self-hosted setup, factor in domain certificates, user management, security-layer settings, updates, and maintenance when choosing a protocol.

Everyday desktop use: Prioritize nodes with reliable real connections and access to the sites you need. Consider VLESS when the full setup supports it.
Android battery life: Reduce unnecessary app routing and repeated reconnects first, then compare power use under the same conditions. Do not infer battery life from the protocol name.
Multi-device use: Choose a set of features supported by all your clients. A subscription distributes configurations; it cannot add core features a client does not support.
Stable existing endpoint: VMess, Trojan, and modern Shadowsocks configurations may all be worth keeping. There is no rule that requires a migration based on the protocol name alone.

Record the complete combination: “protocol + transport + security layer + core version + route.” For help importing a configuration and setting up a proxy, read the Setup Guide. For unfamiliar terms, see the Glossary—both are more useful for troubleshooting than changing multiple settings at random.