VMess vs. VLESS vs. Trojan vs. Shadowsocks: A Proxy Protocol Comparison

Protocols, transport, and security layers

VMess, VLESS, Trojan, and Shadowsocks are proxy protocols; v2rayN is a desktop client, not a fifth protocol. The client manages nodes, subscriptions, system proxy settings, and routing, while the core handles the actual connection. On Android, v2rayNG uses the Xray core, while v2flyNG uses the v2fly core. Similar-looking interfaces do not guarantee identical feature support.

When reviewing node details, check three layers together. The protocol defines authentication and proxy requests; the transport determines how data is carried, such as over TCP or WebSocket; and the security layer protects the connection, for example with TLS. REALITY is a security mechanism in Xray, not a proxy protocol alongside VMess, nor a one-click speed boost for any node.

• Protocol: Check whether it is VMess, VLESS, Trojan, or Shadowsocks. It must match the server.
• Transport: Check the transport type, such as TCP or WebSocket. For WebSocket, verify the path and Host as well.
• Security: Check TLS, the server name, and certificate validation. REALITY also requires parameters such as the public key provided by the server.
• Client settings: System proxy and TUN determine which traffic enters the core; they do not turn one remote protocol into another.

How the four protocols work and where encryption applies

VMess originated in the V2Ray project and includes user authentication and data protection. VLESS was initially designed to be leaner and avoid redundant work; common configurations rely on TLS or REALITY for connection security. Trojan carries proxy requests over a TLS tunnel. Shadowsocks uses a comparatively lightweight encrypted proxy design, with capabilities depending on the method and implementation.

“VLESS is unencrypted” describes only a common protocol-layer setting, encryption: none; it does not tell you whether the entire connection is encrypted. Likewise, enabling TLS does not mean you can enter arbitrary values: the server name, certificate chain, and server configuration must still match. Do not hide configuration errors by disabling certificate validation.

Handshake overhead: first connection vs. ongoing traffic

Handshake overhead affects how long a new connection takes to establish; it is not the same as download bandwidth. For a typical new TCP connection using TLS 1.3, TCP setup usually takes one round trip, and a full TLS handshake usually takes another. DNS, the proxy request, and the connection to the destination are additional. TLS session resumption, connection reuse, and packet loss all affect real-world results, so these round trips cannot simply be added up to predict page load time.

• VMess: Handles protocol authentication and payload protection. Adding TLS or WebSocket on top introduces the processing and packet overhead of those layers as well.
• VLESS: A lean request header does not mean the entire connection has no handshake. The actual connection path depends on the combination of TLS, REALITY, transport, and flow.
• Trojan: A typical deployment establishes a TLS tunnel before sending proxy requests. Whether TLS session resumption is available depends on the implementation and connection conditions.
• Shadowsocks: A typical AEAD TCP connection can send encrypted request data directly without a separate TLS handshake. That does not eliminate TCP setup or guarantee lower end-to-end latency.

The HTTP upgrade for WebSocket adds an extra step. Connection reuse can let multiple logical connections share an underlying connection, but it also changes congestion behavior and how widely failures can affect traffic. So comparing “VMess over WebSocket over TLS” with “Shadowsocks over direct TCP” means comparing complete connection setups, not just protocol header sizes.

Mobile battery use: radio wakeups matter more than the protocol name

There is no reliable, universal ranking of the “most battery-efficient protocol.” Encryption uses CPU, but results also depend on hardware AES acceleration, the ChaCha20 implementation, and traffic load. On cellular networks, repeatedly waking the radio, keeping connections alive, retransmitting under weak signal, and background app sync can all be major sources of battery drain.

TUN usually captures more traffic than a proxy configured for a single app; DNS requests, UDP, and background connections may also pass through the core. Any resulting change in battery use cannot be attributed entirely to VLESS or Trojan. For a fair test, avoid detailed logging, repeated speed tests, and large-scale node scans, which add their own workload.

1. Keep the device, network type, and screen brightness constant. Before testing, record the battery level, signal status, and background apps.
2. Use the same 20-minute routine for every run—for example, 10 minutes of browsing, 5 minutes of video at a fixed quality, and 5 minutes with the screen off. This is a test plan, not a benchmark conducted by this site.
3. Keep TUN or app proxy mode, DNS, and routing rules the same. Change only one protocol configuration per run and record actual traffic.
4. Repeat each candidate three times and check system battery usage and the core logs for reconnects. Do not draw conclusions from differences smaller than the battery indicator’s resolution.

Choose based on your nodes and client

The recommendations below apply only to everyday connections with the required server parameters already available and a compatible Xray core. They are not protocol rankings. If your subscription offers only one usable protocol, stick with the verified configuration; there is no need to rebuild the entire connection just to change protocol names.

In v2rayN, select a node and open its edit window to check the protocol and transport parameters; field names may vary by version. On Android, when using v2rayNG or v2flyNG, first confirm that the core supports the protocol, encryption method, and security extensions. The same subscription will not necessarily behave identically with both cores.

Test under the same conditions: Tcping is not enough

Tcping mainly shows whether a TCP port is reachable and how long the connection takes to establish. It cannot verify the UUID, password, TLS server name, or proxy request, and it does not confirm UDP support. A real connection test is closer to an actual proxy request, but results still depend on the test target, DNS, routing, and connection reuse.

1. Use the same entry point: In v2rayN, keep the system proxy or TUN setting consistent and check that the local listening port matches the app settings. For example, if the local port is set to 10808, the app must not still point to an old port. This is an example setting, not a default for every version.
2. Confirm the routing rule: Make sure test traffic actually uses the selected proxy outbound. If a routing rule sends the target directly, the result says nothing about that node.
3. Measure separately: Record results for the first request, repeated requests, large file transfers, and UDP apps. Do not combine different tests into a single score.
4. Alternate and retest: Test in A, B, A, B order, with at least five requests per candidate. Record the median and failure count to reduce the impact of changing network conditions.

Protocol selection FAQ