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.

VMess + WS + TLS Configuration Example
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.

Trojan Configuration Example
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.

Hysteria2 tip: The 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.
Hysteria2 Configuration Example
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

ProtocolTransportStealthHigh-Latency Perf.Setup ComplexityBest For
VMess+WS+TLSTCP★★★★☆ModerateModerateGeneral use, broad compatibility
VLESS+XTLSTCP★★★★★ModerateHigherHigh-bandwidth, performance-first
TrojanTCP★★★★★ModerateModerateActive probe resistance, self-hosted
Hysteria2UDP/QUIC★★★☆☆BestLowHigh 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.