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

Separate the protocol, transport, and security layers

VMess, VLESS, Trojan, and Shadowsocks can all carry proxy connections, but they solve the problem in different ways. Before comparing them, separate three layers: the protocol defines how the client and server authenticate and exchange data; the transport determines whether that data travels over TCP, WebSocket, gRPC, or another carrier; and the security layer encrypts the connection or establishes a protected session.

A subscription entry usually combines several layers. For example, a VLESS node may use TCP with TLS, or Xray's REALITY with Vision flow control. Another VMess node may use WebSocket, with TLS protecting the outer connection. Although the protocol names differ, real-world speed and stability also depend on server distance, route quality, congestion, transport, client core version, and routing rules.

After receiving a subscription, most users do not need to manually convert a VMess node to VLESS, and changing only the link prefix cannot convert the protocol. The protocol type, authentication details, server listener, and security layer must match the server. Use the configuration shown by the client exactly as provided in the subscription. If the provider offers multiple node groups, choose among them using latency tests and actual browsing performance.

The key differences between the four protocols

VMess: a mature solution with negotiated authentication and encryption

VMess is a long-established protocol in the V2Ray ecosystem. The client authenticates with the server using a user identifier, and modern implementations typically use AEAD to process authentication data. VMess is sensitive to clock skew between the client and server. If a device's clock is significantly wrong, authentication may fail or the connection may drop immediately after being established.

VMess works with transports such as TCP and WebSocket, and TLS can be configured on the outer layer. The protocol's own authentication and data processing are separate from transport obfuscation. Whether the traffic resembles that of a normal encrypted website depends on the transport, security layer, domain, and server deployment actually used. Its strengths include mature deployment guidance and broad support for common VMess subscriptions in v2rayN, v2rayNG, and v2flyNG. The trade-off is a relatively longer processing path, which generally creates more overhead than a streamlined VLESS setup on weaker devices or under high concurrency.

VLESS: streamlined authentication with security handled by the outer layer

VLESS keeps user-identifier authentication but does not duplicate data encryption inside the protocol. In practice, connection protection is delegated to TLS, REALITY, or another security layer that matches the server configuration. This separation reduces duplicate processing and makes parameter combinations clearer, making VLESS a good fit for modern Xray deployments.

VLESS is not a guarantee of speed. When the server route and transport are the same and the security layer is configured correctly, it can typically transfer data with lower protocol overhead. Actual performance can still suffer from unsuitable transports, incorrect flow-control parameters, or complex routing. A subscription with xtls-rprx-vision flow control or REALITY parameters uses Xray-specific extensions and requires an Xray core with the corresponding support. When v2rayNG uses the Xray core, these configurations are more straightforward to use; v2rayN requires a matching core and configuration mode. v2flyNG uses the v2fly core, so Xray-specific parameters must not be treated like an ordinary VLESS node.

Trojan: TLS as the primary outer layer

Trojan authenticates the client with a password and uses TLS as a central part of the connection. When deployed correctly, both the handshake and subsequent data remain inside the TLS session. Its configuration depends on more than a password: the server address, port, domain, certificate name validation, and transport parameters all matter. Any mismatch with the server can cause the TLS handshake to fail.

Trojan has a straightforward structure and is well supported in common desktop and Android use cases. It suits servers that already have the conditions required for domain and TLS deployment. Most performance overhead comes from TLS, network round-trip time, and the chosen transport—not from the length of the password string. If a subscription includes both Trojan over TCP and Trojan with another transport, test them separately; the same protocol name does not guarantee the same latency.

Shadowsocks: a lightweight encrypted proxy

Shadowsocks establishes a proxy connection with a pre-shared password and a specified encryption method. Modern configurations commonly use AEAD methods, while some servers also provide the Shadowsocks 2022 series. The client must support the exact encryption method named in the subscription. Supporting the general “Shadowsocks” category does not mean the client can parse every newer method and extension parameter.

Its relatively lightweight protocol structure remains useful when processor performance is limited, connection counts are moderate, or reducing protocol-processing overhead is a priority. A basic Shadowsocks connection does not attempt to imitate a complete website workload; its externally observable characteristics also depend on the version, encryption method, network environment, and server deployment. “Lightweight” therefore describes the processing path and configuration structure, not necessarily stronger obfuscation.

Handshake, obfuscation, performance, and support compared

“Obfuscation” cannot be scored independently of the transport layer. VMess over WebSocket over TLS, VLESS over TCP with REALITY, Trojan over TLS, and basic Shadowsocks have entirely different connection structures. Even when two nodes both use TLS, their domain settings, handshake parameters, server behavior, and network paths may differ. For most users, the most reliable approach is to import the subscription parameters unchanged and validate the connection under real-world conditions.

“Client support” should also be separated into protocol support, parameter support, and core support. v2rayN is a desktop client that can manage different cores and multiple subscription types; v2rayNG uses the Xray core and is suited to Android subscriptions containing Xray parameters such as VLESS, REALITY, and Vision; v2flyNG uses the v2fly core and is suited to standard V2Ray/v2fly configurations. A successful import only means the link was parsed. At runtime, confirm that the core recognizes every field.

Choosing for home broadband

Home broadband is usually stable and devices generally have sufficient performance, so the priorities are server route quality, evening congestion, and long-term compatibility. If a subscription provides VLESS, Trojan, VMess, and Shadowsocks, test them in the order below rather than relying on a single latency check.

1. Start with a node whose configuration fully matches the client core. Give Xray parameters to an Xray core and standard v2fly configurations to a v2fly core.
2. Test connection setup time, stability during continuous browsing, and large-file transfers separately. Do not treat the lowest one-off latency as the only result.
3. Repeat the tests during your usual evening hours. Congestion on the route is usually a bigger factor than the small amount of processing overhead introduced by the protocol itself.
4. Confirm that system proxy and split-routing settings work correctly, so direct local traffic is not mistakenly counted as node performance.

With modern devices and a healthy route, VLESS with a suitable security layer is often the first candidate. When a stable TLS deployment already exists, Trojan is also a good everyday connection. VMess remains suitable for established nodes, especially when the subscription only offers VMess or the server has not migrated. Shadowsocks can serve as a lightweight alternative. This is not a protocol ranking, but a practical testing order for common deployment conditions.

Choosing for mobile networks

Mobile networks involve cell handoffs, signal fluctuations, changing network addresses, and brief packet loss. In this environment, recovery time and transport stability matter more than peak speed in a lab test. The protocol is only one layer; client background policies, battery-saving settings, and routing scope also affect performance.

VLESS, Trojan, and VMess can all work reliably on mobile networks when the transport and server configuration suit the current link. If a node takes a long time to recover after a network change, disconnect and reconnect first, then compare other protocol nodes on the same server. Do not change the protocol, DNS, routing, and Mux at the same time, or you will not know which setting made the difference.

Mux multiplexes several logical connections over fewer underlying connections; it is not a fundamental difference between the four protocols. Some browsing scenarios may benefit from multiplexing, while some high-bandwidth or long-lived connections may experience head-of-line blocking. For mobile testing, start with the subscription default. If stalling is frequent, compare Mux enabled and disabled separately while keeping every other parameter unchanged in each round.

In v2rayNG, per-app proxying can reduce the number of background connections that do not need a proxy, while routing rules can send local services directly. v2flyNG should likewise import configurations according to the capabilities of its actual core. If a subscription includes REALITY or Vision, first verify the Xray core version and node parameters rather than simplifying it to an ordinary VLESS link.

Choosing for older devices

Older devices are usually limited by processor performance, available memory, and the system network stack. Lower-overhead configurations are more likely to sustain stable throughput, but hardware acceleration for encryption, repeated transport encapsulation, and excessive connection counts can all change the final result.

Shadowsocks' lightweight structure makes it a good first test, but choose a modern encryption method supported by the client core. VLESS can also maintain low overhead with streamlined transport and a matching security layer. Trojan depends on TLS, so its real-world performance is tied to the device's TLS processing capability. VMess has a relatively longer processing path; if the device stays fully loaded at high throughput, compare VLESS or Shadowsocks nodes on the same route.

To reduce resource use, first narrow the scope of per-app proxying, reduce unnecessary concurrent connections, and avoid stacking too many transport layers. Keep routing rules readable: connect local domains and LAN addresses directly, send destinations that require a proxy through the proxy outbound, and use blocking rules only for clearly defined targets. The number of rules is not the only concern; frequent complex domain matching and multi-layer resolution can also increase runtime load.

If an older device can run only an earlier client version, prioritize standard protocol parameters that it explicitly supports. Newer VLESS extensions, Shadowsocks 2022 methods, or specific flow control may require an updated core. When the server offers multiple subscription groups, choose a compatible group instead of deleting unknown fields manually and continuing to connect, because those fields may depend on one another.

Steps after importing a subscription

A subscription combines the server address, port, authentication details, protocol, transport, and security layer. The first step in choosing the right protocol is not editing the link but checking the imported result. v2rayN, v2rayNG, and v2flyNG use different interface labels, but the verification logic is the same.

1. Confirm the protocol: Check whether the node is shown as VMess, VLESS, Trojan, or Shadowsocks. Do not mistake a subscription group name for the protocol.
2. Confirm the address and port: The imported server address and port should both be present in full. Do not keep only the domain while omitting the port.
3. Confirm the transport: Check that TCP, WebSocket, gRPC, or another transport matches the subscription. Keep fields such as the path and host name intact.
4. Confirm the security layer: Check TLS, REALITY, the server name, and flow-control fields. These parameters are especially important for VLESS.
5. Confirm the core: Give nodes with Xray extensions to a core that supports those extensions, and run standard v2fly configurations according to v2fly capabilities.
6. Confirm the system clock: Automatically synchronize the device date and time zone to prevent VMess authentication failures caused by clock skew.
7. Run real-world tests: Test the connection first, visit frequently used sites next, and then observe reconnects and speed fluctuations during continuous use.

After a subscription update, reselect the updated entry if a node with the same name has changed protocol or parameters. The client may retain an old copy, so confirm that the active configuration belongs to the latest subscription group during testing. Routing rules and node protocols are independent dimensions: changing the protocol does not automatically fix incorrect split routing, and updating routes does not change the server's authentication method.

Common selection mistakes

Myth 1: VLESS is always faster than VMess

VLESS has a more streamlined protocol structure, but the speed ceiling is often set by the route, server load, and transport. When a cross-region route is congested, the processing saved at the protocol layer can hardly offset poor network quality. Only a comparison using the same server, network, and broadly similar security layer is meaningful.

Myth 2: Trojan connects with a password alone

The password is only one authentication parameter. The TLS server name, port, DNS resolution, transport type, and certificate deployment all participate in connection setup. If the imported subscription reports a handshake failure, compare these fields first instead of repeatedly changing the password.

Myth 3: All Shadowsocks clients support the same features

Encryption methods and protocol versions can vary between cores. Methods in older configurations, modern AEAD methods, and the Shadowsocks 2022 series cannot be treated as one compatibility category based on their names alone. If the client cannot recognize the encryption method, switch to a compatible node offered by the server or update the matching client core.

Myth 4: A successful import means every parameter works

A client may parse common fields first and report unknown parameters only when starting the core. REALITY, Vision, and specific transport configurations in particular require support from the client interface, configuration generator, and runtime core. When startup fails, identify whether the error occurred during subscription parsing, configuration generation, core startup, or the network handshake; the next step will then be much clearer.

The final choice: keep a practical combination for each scenario

On home broadband, start by testing VLESS and Trojan, then keep stable VMess or Shadowsocks nodes as backups. On mobile networks, prioritize recovery after disconnects, sustained connections, and transport adaptability rather than a single latency result. On older devices, start with Shadowsocks or a streamlined VLESS configuration and decide based on processor usage and sustained throughput.

If the subscription offers only one protocol, use the server parameters as provided. Protocol choice comes from the server's actual deployment, not from an arbitrary client toggle. If all four protocols are available, keep a simple record of the node name, protocol, core, latency during usual hours, sustained-connection behavior, and download speed. After several rounds of comparison, retain one primary node and one or two backups on different routes.

The four protocols have no fixed ranking independent of the environment. VMess is known for mature compatibility, VLESS for its streamlined design and reliance on outer-layer security, Trojan for the importance of correct TLS deployment, and Shadowsocks for its lightweight structure and encryption-method compatibility. Filtering layer by layer through subscription parameters, client core, device capability, and network conditions is more reliable than looking at the protocol name alone.