When choosing a proxy protocol, most people only ask "does it work?" — overlooking significant differences in stealth capability, throughput, and configuration complexity. This article takes a deep look at the major protocols supported by Clash/Mihomo, comparing them on first principles so you can make the best choice for your network environment.
VMess: The V2Ray Flagship Protocol
VMess is the encrypted transport protocol designed by the V2Ray project and one of the earliest and most widely deployed protocols in Clash. VMess uses a UUID as an authentication credential and incorporates a timestamp check (server and client must be within 90 seconds of each other), which effectively prevents replay attacks.
VMess obfuscates its packet headers, giving the bare protocol some degree of traffic fingerprint resistance. Combined with ws + TLS (WebSocket over TLS) or grpc + TLS transport, the traffic becomes nearly indistinguishable from ordinary HTTPS. Its main drawbacks are slightly higher header encryption overhead compared to QUIC-based protocols on high-latency links, and the time synchronization requirement adds a minor operational burden on the server side.
proxies: - name: vmess-ws type: vmess server: example.com port: 443 uuid: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx alterId: 0 # 0 enables AEAD encryption (recommended) cipher: auto tls: true network: ws ws-opts: path: /api/v1/ws headers: Host: example.com
VLESS: The Lightweight Successor
VLESS is VMess's streamlined successor. It removes VMess's symmetric encryption layer, delegating all encryption responsibility to the outer TLS, in exchange for lower CPU overhead and higher throughput. When used with XTLS Vision flow control, VLESS can pass inner TLS data through directly — avoiding the performance cost of double TLS — making it the strongest choice for high-bandwidth scenarios.
Note that VLESS should not be deployed without TLS — it relies entirely on an outer TLS layer for security. It also does not support alterId; authentication is based purely on UUID.
Trojan: TLS As the Disguise Itself
Trojan takes a completely different design philosophy from VMess/VLESS — rather than making traffic "look like HTTPS," it runs directly over real TLS. After the TLS handshake, the client sends a password for authentication. Requests with an incorrect password are forwarded to a real web server (e.g., Nginx), so any active probe by a firewall or DPI system sees a legitimate HTTPS response.
Trojan's resistance to active probing is its standout feature. Even if an inspector tries to connect to a Trojan server directly, the absence of the correct password causes the probe traffic to be served by the real web backend — the inspector cannot tell it's a proxy. The trade-offs are a more complex setup (requires a real domain name and a valid certificate) and slightly lower single-connection throughput compared to VLESS+XTLS.
proxies: - name: trojan-node type: trojan server: example.com port: 443 password: your-password sni: example.com skip-cert-verify: false # Never set true in production udp: true
Hysteria2: The QUIC-Era Speed Champion
Hysteria2 is built on QUIC (multiplexed, reliable transport over UDP), with BBR congestion control and an aggressive bandwidth utilization strategy. On high-packet-loss, high-latency links, Hysteria2 dramatically outperforms all TCP-based protocols. In testing, Hysteria2 can maintain near-full bandwidth even at 30% packet loss, while TCP-based protocols drop to under 10% throughput under the same conditions.
The trade-off: Hysteria2's UDP traffic has a more distinctive fingerprint and may be throttled or blocked in networks that aggressively limit UDP (such as some campus or corporate networks). Its congestion algorithm also consumes significant upstream bandwidth, so it may not be ideal on VPS instances with limited uplink capacity.
up and down fields must reflect your actual bandwidth in Mbps. Setting them too high makes the congestion algorithm overly aggressive and can actually reduce performance. Measure your real bandwidth first.proxies: - name: hy2-node type: hysteria2 server: example.com port: 443 password: your-password up: 50 Mbps down: 200 Mbps sni: example.com skip-cert-verify: false
Protocol Selection Reference
| Protocol | Transport | Stealth | High-Latency Perf. | Setup Complexity | Best For |
|---|---|---|---|---|---|
| VMess+WS+TLS | TCP | ★★★★☆ | Moderate | Moderate | General use, broad compatibility |
| VLESS+XTLS | TCP | ★★★★★ | Moderate | Higher | High-bandwidth, performance-first |
| Trojan | TCP | ★★★★★ | Moderate | Moderate | Active probe resistance, self-hosted |
| Hysteria2 | UDP/QUIC | ★★★☆☆ | Best | Low | High packet-loss / high-latency links |
Mixing Protocols in One Config
In Clash, nodes using different protocols can live in the same proxy group. A practical approach: add both Hysteria2 nodes and TCP-protocol nodes into a url-test group. Clash automatically benchmarks them and picks the fastest. When the network environment favors QUIC, Hysteria2 wins; when UDP is restricted, Clash automatically falls back to Trojan or VMess — the best of both worlds.