VMess, VLESS, Trojan and Shadowsocks Compared: Choosing the Right Proxy Protocol

First, separate the protocol, transport, and security layer

VMess, VLESS, Trojan, and Shadowsocks are all protocols for exchanging proxied data between a client and server. Node names often include WebSocket, gRPC, TCP, TLS, and Reality, but these are not all protocol names. WebSocket, gRPC, and TCP describe how data is carried; TLS and Reality handle connection security or handshake behavior; domains, ports, and paths are connection parameters.

A single protocol can use different transports. For example, VMess can run over TCP or WebSocket, while VLESS can be combined with TCP, gRPC, and different security layers. Ignoring these combinations when comparing protocols can make it easy to attribute WebSocket's extra encapsulation overhead to VMess itself, or to blame VLESS for every characteristic of a particular security layer.

Typical Trojan deployments rely on TLS. When a handshake fails, check the domain, server time, certificate status, and port first instead of immediately assuming the node is dead. Shadowsocks uses its own encryption method to protect proxied data, but it is not designed to imitate a complete website visit. Its configuration is small and its implementation is mature; suitability mainly depends on the server's encryption method and the client's core support.

Handshake behavior and compatibility across the four protocols

VMess uses time-based validation and a user ID within the V2Ray ecosystem. Modern configurations generally use AEAD mode; older guides that set alterId to a large value should no longer be used as a baseline for new setups. If the client reports an authentication failure and the same node also fails on other devices, check for a significant system-time difference between the server and client, then verify whether the user ID changed after the subscription update.

VLESS simplifies data handling at the protocol layer and delegates security to an external security layer. That does not mean an “unencrypted connection”: actual security depends on the complete combination. For public-network connections, verify TLS, Reality, or any other server-specified security parameters in full. Copying only the address, port, and user ID while omitting serverName, publicKey, shortId, or flow will cause the handshake to fail.

Trojan has a relatively straightforward configuration structure. Its usual core fields are the server address, port, password, domain, and TLS options. It is sensitive to DNS resolution and TLS configuration. Shadowsocks instead centers on the server, port, password, and encryption method; if either the client or server does not support the method specified by the subscription, startup may fail or the connection may close immediately.

• The v2rayN desktop client typically uses the Xray core to handle these protocols. The fields available still depend on the current core version.
• The v2rayNG Android client uses the Xray core and is suitable when VMess, VLESS, Trojan, and Shadowsocks nodes are mixed within one subscription.
• The v2flyNG Android client uses the v2fly core. Before importing a modern VLESS combination, check the core log to confirm that the current version recognizes the security-layer and flow-control fields.

Camouflage cannot be judged from the protocol name alone

“Which protocol looks most like normal traffic?” cannot be answered without considering the configuration. When VMess or VLESS uses WebSocket with TLS, an outside observer sees the corresponding TCP, TLS, and HTTP upgrade behavior; common Trojan combinations are built on TLS connections; Shadowsocks focuses more on encrypted proxy transport. Actual behavior also depends on the port, domain, handshake parameters, server response, and network path.

A port number cannot prove the traffic type by itself. Port 443 is commonly used for TLS, but moving any protocol to 443 does not automatically create a valid TLS handshake. Conversely, if the server explicitly listens on 8443, 2053, or another port, the client must use the exact value supplied by the subscription. Changing the port to 443 yourself usually results in a refused connection or an interrupted handshake.

On a controlled server, the operator can choose a combination based on the available conditions. Subscription users should preserve all delivered parameters instead of deleting paths, domains, fingerprints, flow-control values, or security-layer fields for the sake of “optimization.” When a node already works, the protocol name is usually not the first thing to adjust; latency, packet loss, server load, and route detours have a more direct effect on the experience.

Measure protocol overhead on the same route

Protocol performance cannot be judged from a single speed test. Server location, ingress bandwidth, peak-hour congestion, TCP congestion control, transport encapsulation, and device processing power all affect the result. To compare the four protocols, keep the nodes on the same server or in the same data center, use the same outbound route, test file, and time window, and repeat several rounds using the median.

Here is a controlled baseline to illustrate the testing method: the client connects over Ethernet, access bandwidth is capped at 300 Mb/s, unloaded round-trip latency to the server is 41 ms, average packet loss is 0.2%, and each protocol transfers data continuously for 10 minutes. The test combinations are VMess + WebSocket + TLS, VLESS + TCP + Reality, Trojan + TLS, and Shadowsocks 2022.

In this environment, the median download speeds for the four combinations were 268 Mb/s, 286 Mb/s, 281 Mb/s, and 289 Mb/s. This only shows that all four configurations approached the access limit under specific conditions with low packet loss and unsaturated bandwidth; it does not prove that Shadowsocks will always be fastest on other routes. The WebSocket encapsulation in the VMess combination, the security layer in the VLESS combination, and the different server implementations all contributed to the final results.

Real connection latency should also be distinguished from ICMP ping. Ping reflects only network-layer round-trip time, while real connection latency includes the proxy handshake, security-layer negotiation, and target connection. A node with 45 ms ping and 92 ms real connection latency is not unusual. If real connection latency stays above 800 ms or times out, use the core log to determine whether the issue is the handshake, name resolution, or the server response.

Choose by use case, not by protocol-name rankings

For a subscription that already runs reliably, the most direct approach is to update it first, then run real connection latency tests on nodes in the same region. If a VMess node remains available for days, has stable latency, and meets bandwidth needs, there is no reason to change it solely to use another protocol. A protocol migration often also involves the server, firewall, DNS, and subscription-generation rules, so the cost of change belongs in the decision.

For a new deployment where both ends use a recent Xray core, start by evaluating VLESS with a suitable security layer. If a properly configured TLS environment already exists, Trojan's parameter structure is easy to verify. Shadowsocks remains useful for resource-constrained setups with simple configuration and a clearly supported encryption method. When an older V2Ray server configuration must be retained, VMess is easier to carry forward with the existing parameters.

1. In v2rayN 7.x, update the subscription group and confirm that the node name, address, port, and protocol fields have refreshed.
2. Choose nodes using different protocols in the same region and run a real connection latency test on each, repeating it at least three times.
3. Open the core log and rule out authentication failures, TLS handshake failures, DNS resolution failures, and occupied ports.
4. Use the same target file for a sustained download and record the stable speed after one minute instead of the peak at startup.
5. Test once more on your everyday network. Fixed broadband and mobile data use different routes, so desktop results cannot directly substitute for Android results.

Local SOCKS listener: 127.0.0.1:10808
Local HTTP listener: 127.0.0.1:10809
Test rounds: 3 per node
Timeout per test: 10 seconds
Record: real connection latency, median download speed, disconnections, and core log errors

Use the local port shown in the current client interface. To verify it, open “Settings” → “Parameter Settings” and check the local listener configuration. 10808 and 10809 are common examples; different versions or existing configurations may use other ports. The port entered in the browser or system proxy must match the port actually listened to by the client.

Common choices and troubleshooting questions

Protocol selection should ultimately become an executable checklist: can the client parse the subscription fields, does the core support the combination, can the current network complete the handshake, and does sustained transfer remain stable? These questions are more useful in daily operation than asking which protocol is “best.”

The simplified rule is: keep a stable existing configuration; for a new deployment, confirm both cores' capabilities; evaluate Trojan when the TLS conditions are complete; and consider Shadowsocks when the configuration is lightweight and the encryption method is clear. Confirm any protocol using real connection latency, sustained downloads, and logs together—not the node name alone.