VMess, VLESS, Trojan, and Shadowsocks: Protocol Comparison & Use Cases

1. Understand the Node: Protocol, Transport, and Security Layer

A subscription entry such as “VLESS + WebSocket + TLS” combines three different components, not three interchangeable protocols. VLESS handles proxy requests and user authentication, WebSocket carries the data, and TLS protects the connection. Judging a node's speed or security by the word VLESS alone overlooks the settings that actually affect the connection.

Clients and cores are also separate. v2rayN, v2rayNG, and v2flyNG are clients for managing configurations; the core handles the actual connection. V2Ray and Xray do not support exactly the same features. Even nodes labeled VLESS may depend on a particular transport or security mechanism.

• Proxy protocol: VMess, VLESS, Trojan, and Shadowsocks determine the request format, authentication, and some encryption behavior.
• Transport: TCP, WebSocket, gRPC, and others determine how proxy data travels over the network. Both ends need compatible settings.
• Security layer: TLS, REALITY, and others cannot be inferred from the port number or swapped arbitrarily.
• Routing: Determines whether requests go direct, through a proxy, or are blocked. Selecting a proxy node does not mean every app's traffic will use it.

2. How the Four Protocols Handle Encryption and Authentication

All four protocols can be used for proxy connections, but they protect data differently. The table covers common configurations with broad compatibility. For newer extensions or core-specific settings, follow the server requirements and check what your local core supports.

VMess: Check AEAD First, Then Review Transport Settings

VMess isn't automatically unusable just because a node is old. A properly maintained AEAD node can still be a practical choice. The alterId setting in older configurations can be confusing: common modern configurations use 0 for AEAD. Don't change it to a larger number on your own. VMess authentication also depends on time, so keep your computer and phone clocks accurate.

VLESS: Common Configurations Use an Outer Security Layer

A common VLESS configuration with encryption=none does not mean the entire connection is unencrypted. An outer TLS or REALITY layer can protect it. Conversely, VLESS over TCP without a security layer is not protected in the same way just because the application accesses an HTTPS site. Some newer implementations offer additional encryption extensions, but they are not supported by every client.

Trojan and Shadowsocks: Passwords Mean Different Things

Trojan's shared password is used for authentication, while TLS protects the connection. With Shadowsocks, the password or key and the cipher together determine whether a connection can be established. For example, aes-128-gcm and chacha20-ietf-poly1305 are not interchangeable. The 2022 series also requires specific key formats; you can't simply reuse an old password and change the method.

3. Handshake Overhead and Speed: There Is No Fixed Protocol Ranking

The wait before a webpage first opens includes DNS lookup, connecting to the server, the outer security handshake, proxy authentication, and connecting to the destination. WebSocket often involves an HTTP upgrade; gRPC relies on HTTP/2; and TLS session reuse can also affect connection setup time. These combinations can't be reduced to a claim that one protocol always requires “one fewer handshake.”

Throughput is a separate consideration. Server bandwidth, peak-time congestion, packet loss, and device performance can all become bottlenecks. Under suitable conditions, VLESS + Vision can reduce some repeated-encryption overhead, but it is not a default feature of every VLESS node and does not guarantee better speed on every route.

These ports illustrate where different connection layers sit; they are not benchmark results. A server port and a local proxy port are different things: the browser connects to the local listening port, and the core then connects to the server port in the subscription. Entering the server's 443 port as your local SOCKS port will not create a proxy connection.

1. Test on the same device, network, and at the same time. If possible, compare different protocol nodes on the same server route.
2. For each candidate node, record five first-load timings for the same page, then run the same 30-second download test three times. Don't treat a single peak result as sustained speed.
3. Before testing, keep the system proxy or VPN mode and routing rules consistent. Verify that the test traffic actually uses the selected node so direct connections don't skew the comparison.
4. Record timeouts, median page-load time, and sustained download speed. TCP latency alone cannot tell you whether web browsing, video, or UDP apps will work.

4. Choosing a Protocol for Your Use Case: Start with Server Support

You can't switch a node from VMess to VLESS in the client alone without a matching server configuration. The recommendations below assume your provider has supplied a complete node for the protocol. If your current node works reliably, confirm the benefits of switching with real tests rather than judging by how new the protocol name sounds.

5. Using v2rayN, v2rayNG, and v2flyNG Together

To check compatibility, verify the client version, core version, and complete protocol combination—not just the client name. v2rayN is a desktop client and can use different cores depending on the distribution and configuration. v2rayNG uses the Xray core; v2flyNG uses the V2Fly core. The latter two are not interchangeable for every node just because their names look similar.

In the classic v2rayN interface, subscription management is commonly found under “Subscription Group” → “Subscription Group Settings,” while local settings are under “Settings” → “Parameter Settings.” The cross-platform desktop interface may use different names; follow the labels in your current version. On Android, use the add option on the main screen to import a share link, then review the selected node's edit screen. Don't assume button locations are identical across versions.

• Imported, but won't start: Check the core startup log first for unsupported transports, security types, or ciphers instead of immediately changing the password.
• Works on the computer, but not on Android: Compare the core versions and node fields on both devices, especially flow, fingerprint, server name, and transport path.
• Same node list, different results: Compare DNS, routing, and traffic-capture settings. Syncing nodes is not the same as syncing global settings.

6. Checking Protocol Settings: What to Check First When a Connection Fails

Before changing settings, keep a copy of the original configuration from your service provider for comparison. Change only one setting at a time, based on evidence, then reconnect and check the logs. Changing the port, SNI, and transport all at once leaves you with no useful point of reference.

The server name for a TLS node usually matches a domain covered by the certificate, and may differ from the connection address. WebSocket's Host is an HTTP-layer field; the server can configure it separately from TLS SNI, but both must meet its requirements. If you see a certificate error, check the system time, domain, and certificate chain. Don't use allowInsecure as a routine fix.

If the logs show that the connection succeeded but some sites won't load, focus on DNS, routing rules, and the connection to the destination. Switching protocols might happen to put you on a different route, but that doesn't prove the original protocol was the problem. For general troubleshooting steps, see Troubleshooting. If a concept is unclear, check the Quick Reference.

7. Frequently Asked Questions About Choosing a Protocol

A good choice comes down to three steps: check what the server provides, confirm the client and core fully support it, then compare real-world performance on your current network. VMess, VLESS, Trojan, and Shadowsocks all require matching configurations. Changing a protocol name won't fix routing, DNS, or poor network routes.