SS / VMess / Trojan: A Side-by-Side Protocol Comparison

What Problem Do These Protocols Actually Solve

Whether it's Shadowsocks or VMess, at their core they all wrap your network traffic in a layer that makes it hard for network devices in the middle (ISPs, firewalls) to recognize as "proxy traffic," while also making sure the data can't be eavesdropped on or tampered with in transit. The differences between protocols mainly come down to three things:

• Encryption strengthWhat algorithm is used to encrypt data, whether forward secrecy is supported, and how hard it is to break or analyze.
• Disguise capabilityHow closely the traffic pattern resembles normal HTTPS/TLS traffic — the closer it looks, the harder it is for pattern-based blocking to identify.
• Performance overheadThe compute and latency cost of encryption/decryption and the handshake process, which directly affects your experience.

Shadowsocks (SS): Lightweight but Easy to Fingerprint

Shadowsocks was the first protocol to really take off, and its design is very simple: encrypt data symmetrically with a shared key (typically an AEAD cipher like chacha20-ietf-poly1305 or aes-256-gcm), with almost no extra handshake overhead.

• Pros: simple to implement, fast, low resource usage on the client — mature implementations exist on almost every platform.
• Cons: its traffic pattern is fairly fixed, making it easier for deep packet inspection (DPI) to identify through traffic analysis; in heavily censored network environments it's more likely to be targeted for throttling or blocking.
• Best for: relatively permissive network environments where speed and stability are the priority.

VMess: The Core Protocol of the V2Ray Ecosystem

VMess comes from the V2Ray project, and builds on SS by adding mechanisms like timestamp verification and per-user UUID authentication. It also supports being carried over WebSocket + TLS, disguising proxy traffic as an ordinary HTTPS web request — giving it stronger disguise capability than plain SS.

• Pros: good disguise when paired with WS+TLS, mature ecosystem, supports multiplexing (mux) to reduce the number of connection handshakes.
• Cons: more configuration options, slightly higher encryption/decryption and header-parsing overhead than SS, and it has some sensitivity to clock sync (too large a time gap between client and server can cause authentication to fail).
• Best for: situations that need strong disguise capability while accepting a somewhat more involved configuration.

Trojan: Disguised as Real HTTPS Website Traffic

Trojan's design philosophy is straightforward: reuse the standard TLS protocol directly. The server disguises itself as an ordinary HTTPS website (you can even serve real web content from it), so proxy traffic and normal traffic to that site are nearly indistinguishable — because it genuinely is standard TLS.

• Pros: the strongest disguise capability, low protocol overhead (reuses standard TLS libraries), relatively simple to deploy.
• Cons: needs a valid domain certificate (a free one from Let's Encrypt is usually fine), and demands slightly more from server-side maintenance.
• Best for: heavily censored network environments, or cases where you want long-term stability without frequently switching protocols.

Hysteria2 / TUIC: A New Generation of QUIC-Based Protocols

Protocols like Hysteria2 and TUIC, which have taken off in the last couple of years, run over the QUIC (UDP) transport layer. Compared to traditional TCP-based protocols, they naturally handle packet loss better and establish connections with lower latency, giving a noticeably better experience on unstable networks or high-latency links (like long international routes).

• Pros: UDP-based, resilient to packet loss, fast connection setup, a clear speed advantage on poor networks, with built-in congestion control tuned for proxy use.
• Cons: some networks throttle or block UDP traffic more aggressively than TCP, and ecosystem maturity and client support still lag a bit behind the three protocols above.
• Best for: unstable network quality, long international distances, and situations where download/streaming speed matters a lot.

How to Choose, at a Glance

In practice, many subscription services already provide nodes across multiple protocols, so you don't need to set anything up yourself — just switch between nodes or protocol types in the policy group inside your Clash client based on latency and your current network, and change any time you're not happy with it.

FAQ