VMess, VLESS, Trojan, and Shadowsocks Compared: How to Choose a Proxy Protocol

The short answer: the protocol name is not the only selection criterion

VMess, VLESS, Trojan, and Shadowsocks can all carry proxy traffic, but they solve the problem differently. VMess handles authentication, time validation, and encryption inside the protocol; VLESS keeps the protocol layer lightweight and relies mainly on outer security mechanisms such as TLS and REALITY for confidentiality; Trojan has always organized authentication and data transfer around a TLS connection; Shadowsocks is known for its simple design, mature implementations, and low resource usage.

When a subscription includes all four node types, do not judge speed by protocol name alone. Real-world performance also depends on bandwidth, round-trip latency, packet loss, transport method, TLS handshakes, server load, and the client core. On the same server, protocol overhead is usually only part of the total time; if the route itself has 180 ms of latency or persistent packet loss, switching from VMess to VLESS alone will not fix the connection.

For a practical starting point, filter by client core first. With v2rayN using the Xray core, check VLESS, VMess, and Trojan nodes first; v2rayNG likewise handles common protocols through the Xray core. With v2flyNG using the v2fly core, follow the protocols and transport parameters supported by the core currently in use. A node importing successfully does not mean every extension field will be recognized, so check the logs before connecting.

A four-part comparison: encryption, overhead, transport, and compatibility

VMess authenticates with a user identifier and time information, while protecting data inside the protocol. It is sensitive to system time, and a large clock difference can cause authentication to fail. VLESS identifies users with information such as a UUID, but does not provide complete content encryption itself. Do not evaluate it separately from the secure transport layer; in practice, confirm fields such as security, flow, TLS, and REALITY together.

Trojan performs authentication and carries data over a TLS connection, so the server certificate, domain match, and system time all affect the handshake. Shadowsocks uses a pre-shared password and a selected encryption method. Modern configurations should use AEAD or a Shadowsocks 2022 method, and the method name must match exactly on the client and server. Older methods may still appear in legacy configurations, but they are not recommended as the default for new deployments.

Choosing for desktop, mobile, and low-powered devices

Desktop work typically involves a browser, sync tools, and messaging apps running together for long periods, so stability matters more than a short speed test. If the subscription offers VLESS with TLS or REALITY and v2rayN is currently using the Xray core, try it as the primary connection; keep a VMess or Trojan node on the same route for comparison. When switching, do not change the server region, transport, and protocol at the same time, or you will not know which change affected the result.

Android devices often switch between Wi-Fi and mobile networks, so reconnect time, battery use, and UDP availability matter more than a single peak-speed result. v2rayNG can handle common Xray nodes and works well with a unified subscription containing VLESS, VMess, or Trojan. With v2flyNG, choose nodes compatible with the capabilities of the v2fly core. Sharing a subscription keeps the node list in sync, but routing rules, per-app proxy settings, and local ports are client-side settings and do not migrate automatically.

On low-powered devices or with many concurrent short connections, test Shadowsocks first. Its core configuration usually consists of only the server, port, password, and encryption method, which makes troubleshooting shorter. If the workload requires complex routing, a specific flow control mode, or REALITY, use an Xray combination that supports those capabilities instead of forcing an incompatible protocol just to reduce a few fields.

1. Primary desktop connection: compare sustained stability between VLESS and Trojan first, then keep a VMess node as a compatibility fallback.
2. Frequent network switching: record the time to recover after each switch and verify that UDP applications work normally.
3. Low-powered devices: measure Shadowsocks CPU usage and sustained throughput first, then decide whether a more complex transport layer is necessary.
4. Existing subscriptions: do not replace a stable VMess node solely because the protocol is older; evaluate the route and the server's maintenance status first.

Replace one-off speed tests with repeatable testing

Keep the server, egress route, target file, and testing window fixed. A practical baseline is about 50 ms round-trip latency from client to server, under 1% idle packet loss, and a 100 Mbps local connection. Test each node three times and disable background sync before testing. The figures below illustrate a test record, not a fixed ranking across different networks.

Record at least four results: time to first connection, sustained download speed, reconnection count within 10 minutes, and UDP availability. Peak speed reflects only one moment and cannot show whether a protocol remains stable during network changes or under weak conditions. If the four nodes are not on the same server, label the result as overall route performance rather than attributing it to the protocol itself.

You can also run a simple cross-check: test VLESS, VMess, Trojan, and Shadowsocks in that order, then repeat in reverse. If the first node tested is always faster, background tasks, temporary server load, or network congestion may be changing. Compare averages only when the forward and reverse results are reasonably close.

• Speed gap under 8%: choose the node with fewer reconnects and cleaner logs.
• Latency gap over 30 ms: check the server region and route first; do not attribute it directly to the protocol.
• Packet loss over 5%: fix the network quality issue first; fine-tuning encryption usually offers limited benefit.
• Only UDP fails: check whether the node supports UDP, whether the client has enabled the relevant forwarding, and whether routing rules are blocking it.

Checking protocol parameters in v2rayN and Android clients

In v2rayN, first use the type column in the server list to confirm whether the node is VMess, VLESS, Trojan, or Shadowsocks, then open its server settings. For VLESS, verify the address, port, user ID, transport protocol, TLS or REALITY, and security flow. For VMess, check the user ID, transport, and security settings. For Trojan, check the password, server name, and certificate-related options. For Shadowsocks, verify the password and encryption method.

The local proxy ports must also match the browser or system settings. Common configurations use SOCKS port 10808 and HTTP port 10809, but users can change these values, so do not treat the examples as fixed for every installation. If an app cannot connect, open Settings → Parameters, check the current local listening ports, and compare them field by field with the proxy address in the app.

• VMess authentication failed: sync the system time first, then confirm that the UUID matches the server.
• VLESS handshake failed: check the fields that actually appear, such as security, flow, serverName, publicKey, and shortId.
• Trojan reports a TLS error: check the device time, server name, port, and certificate domain.
• Shadowsocks connects but carries no traffic: confirm that the client and server use exactly the same encryption method and password.
• The node type is wrong after importing a subscription: update the subscription and check whether the original node's extension parameters were ignored by an older core.

Troubleshooting on Android follows a similar order. In v2rayNG, open the node editor to check the protocol fields, then review DNS, handshake, and connection errors in the runtime log. With v2flyNG, also confirm that the node's capabilities are included in the current v2fly core. If the same subscription works on desktop but not on Android, compare the two cores and node fields before assuming the server is down.

Common misconceptions and the final selection checklist

“VLESS is always faster than VMess” is the most common oversimplification. VLESS has a lighter protocol layer, but in real connections, TLS, transport encapsulation, network round trips, and server load often account for more. Another misconception is treating Trojan as ordinary web traffic. It is built on TLS, but its observable network behavior also depends on handshake parameters, transport behavior, and deployment, so the protocol name alone cannot support an absolute conclusion.

Shadowsocks is not limited to simple web browsing either. Support for UDP, concurrent connections, and specific routing depends on the client, server, and configuration together. Conversely, more configuration fields do not automatically make a connection more reliable. Every protocol requires correct server parameters, an available route, and a compatible core.

The final choice can be reduced to three steps: first, check whether the current client and core fully support the node fields; second, test connection time, reconnections, and UDP on a fixed route; third, keep a backup node using a different protocol. For desktop use, start by evaluating VLESS with the Xray core. Stable existing VMess nodes can remain in service; choose Trojan when TLS deployment conditions are mature; and test Shadowsocks first on low-powered devices or in simple access scenarios.

A protocol is not a permanent setting chosen once and forgotten. After a provider changes its server, a client core is upgraded, or the network environment shifts, the best combination may change. Keep test records and retest under the same conditions instead of chasing a single protocol name.