VMess, VLESS, Trojan, and Shadowsocks Compared: A Practical Proxy Protocol Guide

Start with a consistent framework: a protocol is not a complete connection setup

VMess, VLESS, Trojan, and Shadowsocks describe proxy protocols first and foremost. A real connection also includes the transport layer, encryption layer, DNS resolution, routing rules, and the client core. Seeing “VLESS” in a node name does not reveal its performance; check whether TCP, WebSocket, gRPC, TLS, Reality, and other parameters match.

The same protocol can have very different connection characteristics and overhead depending on the transport combination. For example, VLESS over TCP with Reality and VLESS over WebSocket with TLS are two different setups; VMess over TCP and VMess over WebSocket should not be treated as equivalent just because both use VMess. Confirm which combinations the server provides, then verify that the client fully supports them.

Core differences and use cases for the four protocols

VMess was one of the earlier widely adopted protocols in the V2Ray ecosystem and typically uses UUID authentication. It is sensitive to system time, and excessive clock drift can cause authentication failures. Many existing subscriptions still include VMess nodes, making it useful for compatibility with older servers and configurations—not an automatic first choice based on its name alone.

VLESS delegates content encryption to outer security mechanisms such as TLS and Reality, resulting in a leaner protocol layer. With the Xray core, VLESS is commonly combined with TCP, gRPC, WebSocket, TLS, or Reality. Its strength comes from the complete combination, not from “removing encryption” by itself; transmitting it over an untrusted network without suitable outer protection is not a complete security solution.

Trojan typically runs over TLS and authenticates with a password. Enter the server address, port, password, SNI or server name accurately, and handle certificate verification correctly. If a subscription requires a domain but you replace it with the server IP, TLS name matching may fail. For certificate errors, first check the system time, domain, and SNI instead of permanently disabling verification.

Shadowsocks uses a pre-shared password and an AEAD encryption method. Its small number of configuration fields makes it suitable for devices with limited performance or simple server setups. It does not automatically provide sophisticated obfuscation; real-world performance depends on the server implementation, selected encryption method, and transport. When importing an older node, also confirm that the client core supports the specified encryption method.

Three prerequisites for choosing a protocol

• Server support comes first: a client cannot turn a VMess node into VLESS on its own. The protocol, port, and transport parameters must be provided together by the server.
• Core support comes first: when v2rayNG uses the Xray core, it can handle common VLESS, VMess, Trojan, and Shadowsocks configurations. When v2flyNG uses the v2fly core, check newer extension parameters against the capabilities of the actual core.
• Stability comes first: on the same route, repeated connection success, time to first byte, and recovery after switching networks are usually more useful than the peak result of a single speed test.

Choosing for mobile networks, home broadband, and older devices

The main variables on mobile networks are cell handoffs, changing network addresses, brief packet loss, and background restrictions. A protocol name cannot eliminate these issues. Start by testing a VLESS combination explicitly provided by the server and fully supported by the client core, then observe recovery after switching between Wi-Fi and mobile data. If traffic remains stalled after the switch, stop and restart the connection in v2rayNG and check whether the device manufacturer’s battery policy restricts background networking.

Home broadband is better suited to stability comparisons. Use the same device, access method, and target site, and record connection time, sustained downloads, and video seeking during evening peak hours. If VLESS and Trojan are hosted on different servers, the results may primarily reflect route differences rather than the protocols themselves.

Older devices should avoid unnecessary concurrency, complex routing, and frequent speed tests. Shadowsocks has relatively lean configuration fields and can be a lightweight option when the server provides it; there is no need to migrate a stable VMess node merely to change its name. Judge performance by CPU usage, heat, reconnection count, and actual throughput.

Direct recommendations by use case

1. Primary mobile connection: when the server provides VLESS with a matching secure transport, test VLESS first and focus on recovery after network changes and background keep-alive.
2. Always-on home broadband: both VLESS and Trojan can be stable options; compare them for at least three rounds on the same route and during the same time period.
3. Older Android devices: keep a verified, stable Shadowsocks or VMess setup first, and avoid concurrency or complex rules without a practical need.
4. Legacy subscription migration: import everything first instead of manually changing protocol fields in bulk. Confirm that both old and new nodes connect before removing failed configurations one by one.

Check parameters in v2rayN, v2rayNG, and v2flyNG

After importing a subscription, do not modify nodes immediately. Subscription data may include the protocol, address, port, user ID, password, transport, path, Host, SNI, fingerprint, flow control, and other parameters. Treating fields in a node name as actual configuration can create a setup that “looks identical but does not connect.”

In the v2rayN desktop client, open “Subscription groups” → “Update all subscriptions,” then select a node and view its configuration details. Next, go to “Settings” → “Parameter settings” and make sure the local SOCKS and HTTP listening ports are not occupied by another program. If you use the example ports 10808 and 10809, other proxy tools on the system must not listen on the same addresses and ports.

In v2rayNG, use the add entry in the upper-right corner to import a single link from the clipboard, or add a subscription URL under subscription groups. Check the active configuration before connecting and open the live log afterward. v2flyNG uses the v2fly core; when importing newer VLESS extension configurations, first confirm the core requirements specified by the subscription provider rather than assuming that different cores handle every extension field identically.

Verification order
1. protocol：vmess / vless / trojan / shadowsocks
2. address: server domain or address
3. port: server listening port, for example 443
4. credential: UUID, password, or Shadowsocks key
5. transport：tcp / ws / grpc
6. security: tls / reality / value specified by the server
7. serverName: server name used by TLS or Reality
8. path or serviceName: fill in only when required by the selected transport

Classify connection errors by the log

1. Connection timeout: first check the address, port, current network, and server status. A timeout usually occurs before the protocol session is established.
2. Authentication failed: check the UUID, password, encryption method, and device time. For VMess configurations, enable automatic system time synchronization first.
3. TLS handshake failed: check the domain, SNI, system time, and certificate chain. Trojan and VLESS or VMess using TLS can all produce this error.
4. Connected but no traffic: check the system proxy, VPN permission, DNS, routing rules, and per-app proxy scope instead of immediately switching protocols.
5. Nodes disappeared after a subscription update: first confirm the active subscription group and filters, then check whether the subscription source returned a new node list.

Use repeatable tests instead of single-peak results

Protocol tests should minimize differences in route and server load. The most reliable approach is to compare setups on the same server, with the same outbound bandwidth and similar configurations. If that is not possible, limit the conclusion to “the performance of these specific nodes” rather than generalizing it to the protocol.

Time to first byte is closer to the browsing experience than a simple network round-trip time. Open three uncached pages in succession and record the time from request initiation until body text appears. For video and large files, focus on sustained throughput and speed variation over one minute. On mobile networks, also test switching between Wi-Fi and mobile data once.

Close other download tasks during testing, keep DNS and routing mode fixed, and confirm the active node before each round. Run at least three rounds and use the median rather than the highest value. If the three results differ by more than 30%, first suspect route congestion, signal variation, or server load instead of the protocol.

1. Update the subscription and record each node’s protocol, address, port, transport, and security layer.
2. Keep the client, network, and routing mode fixed; connect three times in succession and record the number of successful connections.
3. Record DNS resolution, time to first byte, sustained download, and recovery after switching networks separately.
4. Check the logs for retries, handshake failures, connection resets, or DNS timeouts.
5. Keep the two most stable nodes: one for primary use and one for failover.

Common protocol selection questions

Most protocol issues ultimately come down to mismatched parameters, incompatible core capabilities, incorrect time, TLS name errors, or local routing problems. Identify the error type first, then decide whether to switch protocols; this is more effective than repeatedly changing nodes at random.