The core problem a proxy protocol solves is: how to disguise or encrypt your traffic so it can get past network inspection in the middle, while still keeping transmission efficient. Different protocols make different trade-offs between "security," "speed," and "censorship resistance" — there's no absolute "best," only "best fit for your current situation."
A quick look at five protocols
| Protocol | Underlying transport | Characteristics |
|---|---|---|
| Shadowsocks | TCP / UDP + simple encryption | The oldest and most established, lightweight implementation, fast — but its traffic pattern is comparatively easy to detect |
| VMess | TCP / WebSocket / mKCP | The native protocol of the V2Ray ecosystem, supports traffic obfuscation, has more configuration options |
| VLESS | TCP + TLS, often paired with XTLS | Lighter than VMess — drops the built-in encryption (relies on outer TLS instead); paired with XTLS it has a clear performance edge |
| Trojan | TCP + TLS | Disguises itself as ordinary HTTPS traffic, harder to fingerprint, relies on a real domain certificate |
| Hysteria2 | Built on QUIC (UDP) | Strong resistance to packet loss and poor networks, fast cold starts, more forgiving on unstable connections |
Balancing speed against censorship resistance
Generally speaking, the "lighter" a protocol stack is (fewer encryption and encapsulation steps), the faster it is — but it's also easier for traffic-analysis tools to fingerprint. The "heavier" the disguise a protocol applies (for example, fully mimicking an HTTPS handshake), the stronger its censorship resistance — at the cost of extra overhead.
- Shadowsocks is the lightweight contender, with a clear speed advantage. It suits networks that aren't under heavy censorship to begin with.
- VMess / VLESS have a mature ecosystem, and pairing them with transports like WebSocket or TLS adds further disguise — highly flexible.
- Trojan is designed to "look exactly like a normal website visit," and holds up more reliably on networks with strict traffic inspection.
- Hysteria2 is built on QUIC and has native packet-loss resilience. On unstable networks — mobile connections that keep switching towers, for instance — it noticeably outperforms TCP-based protocols.
The protocol is only the "how it's transmitted" layer. What actually determines whether you get a stable connection is usually the quality of the server's network route and the number of available nodes — protocol choice raises the ceiling, but route quality sets the floor.
Does Clash / Mihomo support all of these?
All five protocols above are natively supported by the Mihomo core (the engine behind the current Clash ecosystem) — you don't need to install any extra plugins. Once you import a subscription link, the client automatically detects which protocol each node uses. All you need to worry about is whether a node works and whether its latency is acceptable; the protocol-level details are already handled on the provider's end.
If you're running your own server (rather than using a provider's subscription), your protocol choice should be weighed against your own scenario: pick Shadowsocks or VLESS + XTLS for speed, Trojan or Hysteria2 for censorship resistance, and lean toward Hysteria2 if your network is unstable.
How much should an average user actually care?
If you're just using a subscription from a provider, you don't need to dig into the implementation details of every protocol — the provider has already picked a sensible protocol and route combination for you. What's actually worth paying attention to: if the same provider offers nodes on multiple protocols, try switching to something like Hysteria2 when your network is poor, since protocols with strong resistance to weak networks can make a noticeably different experience.
How to tell which protocol a node in your subscription is using
After importing a subscription link into Clash, node names often carry hints about the protocol or route, but the most reliable way is to open the configuration file directly (or check the node details in the client). Take Mihomo's config format as an example — every node has a type field, and its value is one of ss, vmess, vless, trojan, or hysteria2 — one glance tells you exactly which protocol that node uses:
- name: HK-01
type: trojan
server: example.com
port: 443
If all you have is a subscription link and no parsed plaintext config, you can just import the subscription into the client first and then check the node list for details — most graphical clients display each node's protocol type without you having to manually decode the subscription content.
Obfuscation and transport disguises: can they be stacked?
The "censorship resistance" mentioned earlier mostly comes down to the traffic characteristics of the protocol itself, but in real deployments, protocols are often paired with additional transport-layer disguises to further lower the chance of detection:
- WebSocket + TLS: Makes the traffic look like an ordinary web WebSocket connection from the outside, commonly seen with VMess / VLESS behind a CDN.
- gRPC transport: Wraps traffic to look like gRPC calls — another common disguise technique, with a similar configuration and troubleshooting approach to WebSocket.
- XTLS: A transport optimization designed specifically for VLESS that keeps the TLS disguise while cutting extra encryption overhead — currently one of the best-performing pairings for VLESS.
For an average user, these transport-layer details are also already handled by the provider — you don't need to configure any of it yourself. The value of knowing these terms is: when you see a node name tagged with "WS," "gRPC," or "XTLS," you'll know these roughly correspond to transport-layer disguises, not entirely different protocols.
Not sure which protocol to pick? Here's what to do
If you can't tell offhand which protocol suits your current network best, the most practical approach isn't to agonize over theory — it's to just test it. The same provider will often offer node combinations across multiple protocols, so you can benchmark them separately with a url-test proxy group to compare latency and stability. A few minutes of testing gets you a much more direct answer than digging through documentation ever will.