Subscriptions can hand you all kinds of node types — ss, vmess, trojan, hysteria2, and more. Most people just use whatever the provider gives them without really knowing what sets these protocols apart. This article compares them across three dimensions — speed, censorship resistance, and setup complexity — to help you make an informed choice.
Overview table first
| Protocol | Transport | Censorship Resistance | Typical Use |
|---|---|---|---|
| Shadowsocks | TCP/UDP | Moderate — traffic pattern is fairly easy to fingerprint | Lightweight, quick to set up, a long-standing protocol |
| VMess | TCP + WS/gRPC | Better (with CDN fronting) | When you need to look like normal HTTPS traffic |
| VLESS | TCP + WS/gRPC/XTLS | Good, better performance than VMess | When both performance and detection resistance matter |
| Trojan | TLS | Good — traffic looks close to normal HTTPS | Simple, reliable fronting |
| Hysteria2 | QUIC (UDP) | Strong, well optimized for poor networks | Prioritizing speed on high-latency/lossy connections |
| TUIC | QUIC (UDP) | Strong, fast connection setup | Mobile networks, frequent network switching |
Shadowsocks: simple and reliable
Shadowsocks (SS) is one of the earliest widely adopted encrypted proxy protocols, and its config is simple — just four core fields: server, port, cipher, and password. The downside is a relatively fixed traffic signature, which can make it a target for throttling or blocking in networks with strict traffic fingerprinting.
VMess / VLESS: fronting with a CDN
VMess and its successor VLESS are typically paired with a WebSocket or gRPC transport, wrapped in another layer of TLS, making the traffic look like an ordinary HTTPS request — and it can even be routed through a CDN. VLESS trims some of VMess's encryption overhead and performs better when paired with XTLS.
Trojan: disguised as a "normal website"
Trojan's design is straightforward: the whole connection looks like a standard HTTPS request, and the server can even serve up a normal website as cover if it gets probed. Its config fields are fairly minimal too — a common choice when you want simplicity and good fronting at the same time.
Hysteria2 / TUIC: a new generation built on QUIC
Both of these run on top of QUIC (UDP-based), which naturally gives them better congestion control and connection migration. On high-latency, lossy, or frequently switching networks (like mobile data bouncing between Wi-Fi and 4G/5G), they generally outperform traditional TCP-based protocols.
How connection multiplexing affects real-world speed
Beyond the protocol itself, how the transport layer handles connection reuse can noticeably affect perceived speed. Transports like gRPC (used by VMess/VLESS) can multiplex multiple logical streams over a single physical connection, cutting down on repeated connection setup overhead — especially noticeable on poor or high-latency links. A setup that opens a fresh connection for every request tends to feel choppy when a page loads many small resources (images, scripts) at once. If the same node feels very different when browsing versus downloading a large file, that's usually about the transport's multiplexing strategy, not raw bandwidth.
Why the same protocol feels so different across providers
People often argue about "which protocol is fastest," but in practice, two Trojan nodes from different providers can differ in speed by several times. That's because the final experience depends on far more than the protocol: the server's own bandwidth quality, physical distance to your location, whether the transit path is optimized, and even concurrent user load at that moment — all of these stack up. The protocol only determines how data gets packaged for transport; the underlying network infrastructure is what really sets the speed ceiling.
How to actually test a node's real speed
The latency number (ms) shown in a proxy group doesn't fully capture the real experience — it's usually just the round-trip time of a single TCP/HTTP probe, reflecting latency rather than bandwidth. A more thorough approach: use url-test's latency ranking as a first filter, then download a moderately sized test file on two or three candidate nodes and watch whether the download rate stays stable, rather than looking only at a momentary peak. If a node has low latency but an unstable download rate (fast, then slow), it's likely under heavy concurrent load or has limited egress bandwidth.
Practical advice: how to choose
- Just want it to work reliably: use whatever protocol your provider gives you — Clash auto-detects and handles it, no need to overthink it.
- Network environment has strict filtering: prefer Trojan or VLESS, whose traffic pattern is closest to normal HTTPS.
- Poor network quality (high latency/loss): try Hysteria2 or TUIC first — QUIC generally handles packet loss better.
- Multiple protocols available: put them all in the same
url-testgroup and let the client auto-pick whichever has the lowest latency for your current network.
Will a protocol become "obsolete"
Protocols evolve, but there's no need to worry about an old one suddenly "stopping working." Shadowsocks has stayed active for years, proof that a simple, reliable design has staying power. Newer protocols (like Hysteria2, TUIC) mostly offer a better option for specific scenarios (poor networks, stricter censorship resistance requirements) — not a wholesale replacement of older ones. What matters more in practice is whether a node provider keeps their nodes maintained, not how new or old the underlying protocol is — a poorly maintained node on a shiny new protocol can perform worse than a well-maintained node on an older one.
Summary
There's no single "best" protocol — only "most suitable for your current network." If your subscription offers nodes across multiple protocols, it's worth keeping them all in an auto-speed-test group and letting Clash pick based on actual conditions, rather than sticking rigidly to one protocol.