Shadowsocks vs. VMess vs. Trojan vs. Hysteria2: Which Should You Choose?

The Quick Overview

None of the four protocols is objectively "best" — each is simply a better fit for a particular network environment. In broad strokes:

Shadowsocks: Lightweight, Battle-Tested, and Stable

Shadowsocks is simple enough that mature client implementations exist on virtually every platform, and its encryption overhead is minimal, which keeps latency consistently low. Its weak point is that its traffic patterns have been extensively studied over the years, and on heavily filtered or DPI-aware networks, a bare Shadowsocks connection is comparatively easy to fingerprint and target. It's usually paired with an obfuscation plugin such as obfs to compensate.

VMess: Flexible, at the Cost of More Configuration

VMess was designed in part to address Shadowsocks' authentication and fingerprinting weaknesses, and it supports multiple transports — WebSocket, mKCP, and others — with optional TLS layered on top. That flexibility comes with more moving parts to configure correctly: server address, port, UUID, alterId, cipher, transport type, and any TLS-related settings all need to line up exactly with the server. A single mismatch on any of these will break the connection, which makes VMess a bit more tedious to troubleshoot than Shadowsocks.

Trojan: Disguised as an Ordinary Website, Strong Against Censorship

Trojan's design is refreshingly direct: it mandates standard TLS and disguises proxy traffic as an ordinary user browsing an HTTPS website, making it hard for network filtering to distinguish from real traffic based on fingerprint alone. The trade-off is a higher deployment bar — it needs a real domain and a valid certificate, and the sni value must match the certificate's domain or the connection gets flagged or simply fails. From an end user's perspective, though, as long as the provider has already handled these details, the experience is no different from any other protocol.

Hysteria2: A Newer Protocol That Shines on Bad Networks

Hysteria2 is built on QUIC (UDP) and comes with forward error correction and congestion control baked in, which tends to make it noticeably smoother than traditional TCP-based protocols on lossy, high-latency links — long-distance international routes being a common example. The catch is that some public and corporate networks throttle or downgrade UDP traffic; if your network isn't friendly to UDP, Hysteria2 loses its main advantage, and falling back to a TCP-based protocol like Trojan is usually the more reliable choice.

How to Choose

• Running on a heavily restricted network and need long-term stability — go with Trojan;
• Want configuration flexibility and custom transports — VMess is a solid fit;
• Just need something simple and lightweight on a relatively open network — Shadowsocks is enough;
• Dealing with high latency and packet loss, and UDP isn't blocked — try Hysteria2 for a noticeably faster experience.

In practice, many subscriptions bundle nodes across several protocols at once, so there's no need to commit to just one. Mixing them into the same proxy group and letting the client's latency test pick the best performer automatically is usually the more practical approach.

Mixing Protocols Beats Picking Just One

Rather than hunting for a single "correct" protocol among the four, it's more useful to treat them as different tools in the same toolbox. Established providers commonly ship nodes across multiple protocols in one subscription, and there's nothing stopping you from dropping them all into the same url-test proxy group — the latency test will automatically surface whichever one performs best on your current network, without you having to manually decide.

This matters even more if your network conditions change throughout the day — office Wi-Fi in the morning, home broadband at night, mobile data on weekends. Different networks tolerate different protocols differently: a corporate network might clamp down hard on UDP, which hurts Hysteria2, while mobile carriers tend to be more permissive toward standard TLS traffic like Trojan. Letting the client auto-switch based on live measurements is a lot less error-prone than manually remembering to switch every time you change networks.

The Real Cost of Switching Protocols

Switching between protocols is, at its core, just swapping out node information — it doesn't touch rules, proxy groups, or DNS settings, so the actual cost is much lower than it sounds. Most of the time, all you need to do is update your subscription (providers that offer multiple protocols usually bundle them into the same subscription link anyway) or manually swap the relevant entries in the proxies list, while your proxy groups and rules stay exactly as they are. What actually deserves careful testing after a switch is the stability and speed of the new nodes themselves, not protocol compatibility. For the exact fields each protocol needs in config.yaml, see the protocol parameter section of the Advanced Configuration Docs.