VMess, VLESS, Trojan and Shadowsocks: Which Proxy Protocol Should You Choose?

When choosing a proxy protocol, do not rely only on the name shown for a node. The protocol handles authentication and data encapsulation; TLS, Reality, WebSocket, gRPC and TCP provide the security or transport layer, while the client core determines whether the combination can actually run. On the same route, VMess and VLESS may have only a small speed difference. Put the same protocol on a mobile network with heavy packet loss, however, and connection stability may differ significantly.

First, separate four commonly confused technical layers

VMess, VLESS, Trojan and Shadowsocks can all handle proxy authentication and data forwarding, but they do not follow exactly the same design. VMess includes protocol-level authentication and encryption. VLESS focuses on lightweight authentication and forwarding, and usually works with TLS or Reality. Trojan is commonly deployed over TLS. Shadowsocks protects proxy traffic with a specified symmetric encryption method.

Transport is a separate layer. When a node is written as “VLESS + TCP + Reality,” VLESS is the proxy protocol, TCP is the underlying transport, and Reality is the security and handshake scheme. In “VMess + WebSocket + TLS,” WebSocket carries the data, TLS provides encryption, and VMess still handles protocol authentication. Comparing VMess and VLESS while ignoring the rest of the stack usually leads to an incomplete conclusion.

When to use VMess, VLESS, Trojan or Shadowsocks

VMess: legacy configurations and established subscriptions

VMess has long been used in V2Ray-family configurations. Common fields include the address, port, UUID, transport type, path and TLS settings. It also requires a reasonably accurate device clock: a significant local time offset can cause authentication to fail. If VMess nodes suddenly all stop working while the network itself is fine, first set the date, time and time zone on Windows, macOS, Android or Linux to automatic synchronization.

For a stable VMess + WebSocket + TLS subscription, there is no need to migrate just because a newer protocol name has appeared. With older devices, legacy server configurations or an existing entry point to preserve, VMess often offers more practical compatibility value than the small theoretical difference in encapsulation. Modern configurations generally use a UUID with alterId set to 0. If a subscription still includes legacy parameters, the provider should update it instead of having users repeatedly modify settings in the client.

VLESS: a leading choice for Xray environments

VLESS reduces the encryption work handled by the protocol itself and usually delegates transport security to TLS or Reality. It is not a connection that is “encrypted by default”; without the correct security layer, the protocol name alone says nothing about link security. VLESS combinations with Reality and XTLS Vision often depend on the Xray core and require exact matches between client and server fields, including UUID, serverName, public key, shortId, fingerprint and flow.

VLESS is mainly attractive for its flexible combinations and support for newer Xray features, not because it is guaranteed to be faster on every network. On a home broadband connection with low packet loss, VLESS and other sensible configurations can usually use the available line capacity. On mobile networks with frequent cell handoffs or switching between Wi-Fi and cellular data, recovery depends more on the transport, timeout settings and the client’s background state.

Trojan: easy to maintain with an existing certificate and standard TLS entry point

Trojan uses password authentication and is commonly deployed directly over TLS. The client must verify the server address, port, password, SNI and certificate domain. The server address may be an IP address, but serverName should usually contain a domain covered by the certificate. If they differ and SNI is left empty, certificate-name mismatches or terminated handshakes are more likely.

Trojan works well in environments that already have a domain, certificate and entry point on port 443. Its configuration fields are relatively straightforward, but fewer fields do not mean fewer troubleshooting steps. Certificate validity, device time, SNI, ALPN, transport type and the intervening network can all affect the handshake. Keep allowInsecure disabled in the client; fix certificate errors by checking the time, domain and certificate chain.

Shadowsocks: lightweight devices and explicit encryption methods

The core Shadowsocks settings are the server, port, password and encryption method. Traditional AEAD methods and the 2022 series are not interchangeable aliases; the client and server must use the same method. If an imported subscription reports an “unsupported encryption method,” first check the core version and method support. Do not change method to another value that merely looks similar, or authentication will fail.

On devices with limited CPU and memory, a sensibly configured Shadowsocks setup is often easy to deploy and maintain. Link performance still depends on the encryption method, server implementation and network quality. Before choosing it, confirm that the subscription provides a complete configuration, then test page loading, sustained downloads and long-lived connections on the actual network instead of relying on a single latency reading.

Choose a protocol by network and device scenario

Home broadband usually offers a stable exit address and low packet loss, so prioritize long-term maintainability. For a new Xray server, evaluate VLESS + Reality or VLESS + TLS first. If existing VMess or Trojan nodes are stable, keep a fallback configuration. Changing the port, transport and security layer at the same time just to switch protocols makes the cause of a later failure difficult to isolate.

The main challenges on mobile networks are usually jitter, sleep-related cleanup and network switching rather than peak bandwidth. With the Xray core, v2rayNG can run common VMess, VLESS, Trojan and Shadowsocks configurations, but background connections are also affected by Android power-saving policies. If the connection drops after the screen has been off for several minutes, add v2rayNG to the system’s battery-optimization exemption list before comparing protocols.

Do not chase the newest combination on older devices

On low-performance devices, the bottleneck may be the TLS handshake, encryption processing or the graphical client itself. Test three tasks in sequence: open a page with multiple small resources, download a relatively large file and maintain a long-lived connection for 10 minutes. If latency is normal but CPU stays near 100% during sustained downloads, the device’s processing power may be the limitation. If CPU usage is modest but the connection is rebuilt frequently, investigate packet loss and transport parameters instead.

• Home broadband: prioritize a VLESS or Trojan combination that is easy to maintain long term, while keeping a compatible fallback node.
• Mobile networks: address background restrictions and network switching before comparing connection recovery between protocols.
• Older devices: prioritize configurations with fewer fields and explicit core support; avoid unnecessary transport layers.
• Legacy subscription migration: keep the original node and copy the configuration for comparison instead of overwriting the only working entry point.

The client core determines which configurations can be imported and run

v2rayN is a desktop graphical client, and common 7.x builds can run all four protocols with the Xray core. v2rayNG is an Android graphical client that uses the Xray core and suits mobile configurations involving VLESS, Reality and similar combinations. v2flyNG uses the v2fly core and fits the V2Fly configuration ecosystem. When an Xray-specific field appears, do not assume that changing the share-link name alone will make it compatible.

Importing a subscription only writes node records into the client; it does not mean the current core can run every node. Subscription links may contain a flow, security type or encryption method that the client cannot recognize. If the same subscription works in v2rayN and v2rayNG but fails in v2flyNG, compare protocol extension fields and core capabilities first instead of assuming that the subscription URL is damaged.

1. In v2rayN 7.x, open “Subscription groups” → “Subscription group settings” and confirm that the subscription URL is complete and the group is enabled.
2. Return to the main screen and select “Subscription groups” → “Update all subscriptions.” Check whether the node count and update time change.
3. Select a node and choose “Servers” → “Test server real connection latency.” Do not judge proxy availability using only ICMP-style latency.
4. Open “Settings” → “Parameter settings” and verify the local SOCKS and HTTP listening ports. Common defaults are 10808 and 10809, respectively; use the values shown in the current interface.
5. In v2rayNG 1.10.x, open “Subscription settings” from the top-left menu, save the URL, return to the main screen and select “Update subscription.”
6. Before connecting, open the node editor and check the address, port, user ID or password, transport, TLS, SNI and flow one by one.

Protocol configuration example
Protocol: VLESS
Transport: TCP
Security: Reality
Core: Xray
Port: actual server listening port
Check: UUID / serverName / publicKey / shortId / fingerprint / flow

How to compare speed, latency and traffic camouflage

Protocol speed tests must control the variables. Test on the same device and network, using the same server route and similar times, with all four nodes routed through the same exit whenever possible. If the VMess node is in one region and the VLESS node is in another, the result mainly reflects route differences and cannot prove that one protocol is better.

Latency also comes in different forms. TCP connection latency measures only the time required to connect from the client to the target port. Real connection latency includes the proxy handshake. Page loading is also affected by DNS, TLS, concurrent connections and the destination’s response time. An 80 ms result in v2rayN does not mean every page resource will finish loading within 80 ms.

Run three rounds of reproducible tests

1. Initial connection: test real connection latency five times for each node, remove the highest and lowest results, then compare whether the remaining three are stable.
2. Sustained transfer: continuously download the same fixed test file for 60 seconds and watch for repeated drops to zero; do not use a momentary peak as the conclusion.
3. Long-lived connection: keep a web session or terminal connection open for 10 minutes and record reconnects or interruptions after the device screen turns off.
4. Failure retest: repeat once after switching networks, such as from home Wi-Fi to a mobile network, and compare recovery time rather than bandwidth alone.

“Traffic camouflage” should not be attributed to the protocol alone. VMess over bare TCP has different external characteristics from VMess over WebSocket + TLS. VLESS with Reality also differs from VLESS with ordinary TLS. Trojan’s deployment quality depends on the TLS and server entry-point configuration. The protocol is only one layer of the complete path; the domain, certificate, SNI, transport and server response together determine handshake behavior.

Troubleshooting order for import failures, handshake failures and connected-without-traffic issues

Protocol selection ultimately comes down to a working connection. Import failures usually involve link formatting or client recognition. Handshake failures typically involve authentication, time, the security layer or transport fields. If the client shows connected but no traffic flows, continue by checking the system proxy, routing rules, DNS and local listening ports. Separating these three issue types avoids unnecessary changes.

1. Confirm the core: identify whether the current client is v2rayN, v2rayNG or v2flyNG, and check whether the node contains extension fields unsupported by that core.
2. Check system time: VMess and TLS-based connections can both be affected by an incorrect clock, so enable automatic date, time and time-zone settings.
3. Check authentication fields: for VMess/VLESS, check the UUID; for Trojan, check the password; for Shadowsocks, check the password and method.
4. Check security fields: for TLS, verify serverName and the certificate domain; for Reality, verify the public key, shortId, fingerprint and flow.
5. Check transport fields: verify the type—TCP, WebSocket, gRPC and so on—as well as the path, service name and Host against the server configuration.
6. Review core logs: distinguish carefully between timeout, connection refused, authentication failed, certificate and unsupported method.
7. Check the local exit: confirm that the system proxy is enabled and that the application port matches the port currently listened to by v2rayN.

Common protocol-selection questions

The final decision can be reduced to one operating sequence: confirm core support, verify the complete protocol stack, then test stability on the actual network. For a new Xray configuration, VLESS is a common primary candidate. Keep VMess when continuing a legacy subscription. Use Trojan when a properly configured TLS entry point is available. Consider Shadowsocks for resource-constrained devices or a simple backup configuration. Always follow the parameters actually provided by the server.