Clash Protocol Handbook

Chapter 1 · Scope and How to Use This Handbook

Here's how this handbook fits alongside the rest of the site. The Getting Started guide covers the "install to connected" path: download the client, import a subscription, pick a mode, verify the connection — four steps and you're up and running, no protocol knowledge required. This handbook covers the other half of the job: answering questions like "what do ss, vmess, trojan, and hysteria2 actually mean in my node list," "why some nodes in the same subscription are fast and others aren't," and "why an older client can't read certain nodes" — the kind of questions that need some background to answer properly. In short: the setup guide gets you running, this handbook helps you choose well. If you haven't installed a client yet, work through the setup guide first, then come back here as needed; installers for every platform are on the Download page, with Clash Plus as the top pick on each.

The book is organized the way people actually look things up. Chapters 2 through 4 group the six protocols along their technical lineage: Shadowsocks and VMess represent the early self-hosted encryption approach, Trojan and VLESS represent the standard-TLS disguise approach, and Hysteria2 and TUIC represent the newer QUIC-based approach. Chapter 5 puts all six side by side in one performance table and covers mobile battery drain separately. Chapter 6 traces the lineage and feature differences across the original Clash, Clash.Meta, and mihomo kernels — which directly determines which protocols your client can even recognize. Chapter 7 covers how Clash subscriptions relate to other sharing formats. Chapter 8 wraps everything up into concrete picks by use case.

Two terminology notes up front. First, "protocol" in this handbook refers to the type field under a proxies entry in a Clash config file — the transport protocol between client and remote server — which is a different layer from "rules" or "proxy groups." Second, almost nobody hand-writes protocol fields — node parameters come from a subscription, and the client just parses and lists them. So in practice, "choosing a protocol" means two things: favoring a certain node type when a subscription mixes several protocols, and explicitly asking your provider for a certain node type. Keep this in mind — it's the basis for every recommendation in the chapters that follow.

Chapter 2 · Shadowsocks and VMess: Two Generations of Classic Protocol Design

Shadowsocks: Minimal Encrypted Forwarding

Shadowsocks (SS) is the simplest of the six protocols and also the oldest, built around a single goal: establish an encrypted forwarding channel between local and remote, and nothing else. It works like this — the client listens locally, encrypts incoming app traffic with a pre-shared password, and forwards it to the remote server for decryption. There's no handshake phase, no session state, no version negotiation; the very first packet carries actual data. Current implementations all use AEAD ciphers, typically aes-128-gcm, aes-256-gcm, or chacha20-ietf-poly1305 — ChaCha20 in particular runs noticeably faster on older phones and routers without AES hardware acceleration.

This minimalism cuts both ways. On the plus side, overhead is the lowest of any protocol here: no handshake means near-instant connection, and single-layer encryption keeps CPU and memory use negligible — which is why SS remains the go-to for old devices and embedded systems. On the downside, its traffic patterns have been studied extensively over the years, so modern deployments often pair it with transport-layer plugins for extra cover. That's entirely a server-side concern, though — the client just needs to parse the plugin field from the subscription as usual.

VMess: A Structured Session Protocol

VMess is V2Ray's native protocol, designed after SS with a completely different philosophy: instead of a bare-bones pipe, build a fully structured session protocol. VMess uses a user UUID as its credential, packs commands and encryption metadata into the request header, and includes a built-in time-check — if the client and server clocks drift beyond roughly 90 seconds, the handshake fails outright. That's where the classic troubleshooting tip "if every node times out, check your phone's clock first" comes from. VMess also composes well with different transports: it can run bare TCP, or wrap itself in WebSocket, gRPC, and so on with TLS layered on top. WebSocket plus TLS makes the connection look like an ordinary encrypted web session from the outside, which is common on shared hosting setups.

The trade-offs are just as clear: the structured header and layered transport add flexibility, but also more handshake latency and CPU overhead than SS. The old alterId dynamic port-obfuscation mechanism has been superseded by AEAD headers — in a modern subscription this field should be 0, and any older node still using a non-zero value should be treated as questionable on both compatibility and security grounds. Typical config fields for both look like this — useful for checking what a subscription parsed out, not something you should generally edit by hand:

proxies:
  - name: "Example-SS"
    type: ss
    server: node.example.com
    port: 8388
    cipher: aes-128-gcm
    password: "your-password"
  - name: "Example-VMess"
    type: vmess
    server: node.example.com
    port: 443
    uuid: 00000000-0000-0000-0000-000000000000
    alterId: 0
    cipher: auto
    tls: true
    network: ws
    ws-opts:
      path: /ws

Chapter 3 · Trojan and VLESS: Hiding Inside Standard TLS

Trojan: Disguised as Ordinary HTTPS

Trojan takes the opposite approach from the previous two: instead of inventing a new encryption scheme, it reuses the most common protocol on the internet — TLS. From the outside, a Trojan connection looks exactly like a standard HTTPS visit: real domain, valid certificate, standard handshake, all present and correct. Only a client with the right password gets recognized as a proxy request inside that TLS tunnel; anything else — including a browser opening the domain directly — gets served the real website hosted on the server. This puts the deployment burden squarely on the server side, which needs a real domain and certificate; the client side stays extremely simple, with just two core fields: password and sni.

On performance, Trojan's connection cost is exactly one TLS handshake, nothing more. The data path is single-layer TLS encryption, so CPU overhead is lower than VMess-over-WebSocket-over-TLS's multi-layer stack, and throughput ceilings are higher too. The one field worth watching is skip-cert-verify: setting it to true skips certificate validation, and should only be used briefly during troubleshooting when you understand exactly why. If you see it in a regular config, ask your provider what it's for.

VLESS: A Step Further, By Removing Things

VLESS can be thought of as a systematic stripping-down of VMess: since the outer TLS layer already handles confidentiality, encrypting again inside the protocol is redundant work — so VLESS drops built-in encryption entirely, shrinks its header to the bare minimum, still uses a UUID for identity, and leaves confidentiality entirely to the outer TLS. On top of that, the VLESS ecosystem has grown two notable extensions: XTLS flow control (commonly seen as xtls-rprx-vision), which boosts throughput on high-volume traffic by cutting down redundant double-layer encryption processing, and REALITY, which borrows the TLS fingerprint of a real third-party website to complete the handshake — meaning the server no longer needs its own domain and certificate.

For client-side users, VLESS comes with two practical caveats. First, support depends entirely on the kernel generation: mihomo fully supports VLESS, XTLS, and REALITY, while the original Clash kernel doesn't recognize any of it — if you get a node like this and see unsupported proxy type, check your client's kernel first (see Chapter 6). Second, VLESS has more configurable fields than any other protocol here — a mismatch in flow, reality-opts, client-fingerprint, or any other field against the server will break the connection, so these nodes should really only come from an auto-updating subscription; hand-copying them is error-prone.

Chapter 4 · Hysteria2 and TUIC: The Next Generation, Built on QUIC

Shared Foundation: What QUIC Brings to the Table

The four protocols in the previous two chapters all run on TCP. The two in this chapter run on QUIC instead — a user-space transport protocol that runs over UDP and also underpins HTTP/3. Switching layers this way brings three general benefits: first, 0-RTT session resumption, so reconnecting after a drop barely adds any extra handshake round-trips, giving a noticeably better first-connection experience than the combined "TCP three-way handshake plus TLS handshake" overhead. Second, connection migration — a phone switching between Wi-Fi and cellular can keep its session alive without rebuilding the connection. Third, congestion control runs in user space, so it can use more aggressive algorithms instead of being locked into whatever the OS kernel's TCP stack does.

Two Different Implementation Philosophies

Hysteria2 takes an aggressive bandwidth-utilization approach. Its signature feature lets you declare link bandwidth up front (the up/down fields in config), and its built-in congestion control actively fills the pipe based on that — in high-packet-loss, high-latency conditions, throughput often noticeably beats TCP-based protocols relying on standard congestion control, which back off conservatively on packet loss while Hysteria2 doesn't. Its disguise is based on HTTP/3, blending in at the same layer as normal modern web traffic. TUIC takes a "more standard QUIC" approach instead: no aggressive filling, congestion control can be set to bbr, cubic, or new_reno, and it natively defines two UDP-forwarding modes (over stream and native), giving much cleaner forwarding semantics than TCP-based protocols for UDP-heavy traffic like gaming and voice.

The Trade-offs Worth Spelling Out

The QUIC family's costs are just as clear as its benefits. First, it runs over UDP, and some networks throttle or deprioritize UDP traffic — in that case a QUIC protocol can actually end up slower in practice than a plain Trojan connection. Whether this happens is something you can only find out by testing, not predict in advance. Second, a user-space protocol stack plus full encryption means higher CPU usage than TCP-based protocols, which translates directly into faster battery drain on mobile (more on this in Chapter 5). Third, QUIC relies on periodic keep-alive probes to stay active, which wakes a phone's radio more often than a quiet, idle TCP connection would. Bottom line: think of the QUIC family as tools for specific situations, not a default pick.

Chapter 5 · Comparing Connection Speed, Resource Use, and Mobile Battery Drain

How to Read This Comparison

One caveat up front: protocol performance is heavily shaped by server specs and line quality, so any absolute number like "protocol X has Y ms latency" is meaningless without context. The table below shows relative levels under otherwise-equal server and line conditions, meant to answer "how do different node types in the same subscription stack up against each other" — not a performance guarantee for any specific node. VMess here assumes the common WebSocket-plus-TLS setup, and VLESS assumes a REALITY setup.

Why Each Column Looks the Way It Does

First-connection speed comes down to how many handshake layers are involved: SS has none, so the very first packet is data; Trojan needs just one TLS handshake; VMess over WebSocket plus TLS needs TCP, TLS, and WebSocket to all establish in sequence, making it the slowest. The QUIC pair can hit 0-RTT on session resumption, which is a particularly big win when reconnecting. Throughput on poor networks comes down to congestion control: TCP-based protocols follow the OS's standard congestion control and back off conservatively on packet loss, while Hysteria2's proactive-fill strategy backs off the least. CPU use comes down to encryption layers and where the protocol sits in the stack: single-layer-encryption protocols like SS, Trojan, and VLESS are the cheapest, while QUIC's user-space stack is itself a constant computational cost.

A Special Note on Mobile Battery Drain

Mobile battery drain deserves its own section, because what drives it differs from desktop. On phones, Clash keeps a virtual network adapter running in the background via VpnService, and battery drain comes from three sources: CPU time spent processing traffic in the kernel, wake-ups from keep-alive heartbeats, and how often the radio gets woken up. TCP-based protocols go nearly silent when idle, while QUIC's more frequent activity probes can wake the cellular radio each time — and that adds up noticeably over a long standby period. For a full troubleshooting walkthrough and background-optimization tips, see the blog post "Why Is Clash Draining My Phone's Battery So Fast"; for Android's VpnService permissions and keep-alive mechanics, see "Key Things to Know About the Clash Android Client".

Chapter 6 · The Kernel Family: How Original Clash, Meta, and mihomo Relate

Three Generations

"Clash" today refers to at least three different things: a YAML config format, a kernel family, and a set of GUI clients. Understanding the kernel lineage is the key to understanding compatibility issues. The original Clash kernel established the foundational conventions of this whole ecosystem — YAML config, the three-part proxies/proxy-groups/rules structure, rule-based traffic splitting, and proxy groups; its closed-source Premium build added extras like TUN mode. Later, the community fork Clash.Meta kept config compatibility while massively expanding protocol support. After the original repository was archived, the Meta fork carried development forward and was renamed mihomo, which is now the de facto leading kernel — the KERNEL mihomo line in this site's homepage verification badge refers to exactly this kernel.

Feature Comparison

Config Compatibility and Matching Clients

Config compatibility is a one-way street: a config file written for the original kernel will generally run fine on mihomo, which stays well backward-compatible with old fields — but the reverse doesn't hold. A file containing VLESS nodes, newer rule-set formats, or sniffer settings will simply error out on startup with the original kernel. This maps directly to a client-level takeaway: every actively maintained client listed on our Download page (Clash Plus as the top pick on each platform, plus Clash Verge Rev, FlClash, and others) ships with the mihomo kernel and supports all six protocols. The archived, no-longer-maintained Clash for Windows and ClashX Meta entries run on the original kernel and can't recognize QUIC-based or VLESS nodes. If you see an error like unsupported proxy type in your node list, switch to a mihomo-based client per this table rather than editing the subscription. For a full side-by-side of clients, see the Client Comparison page.

Chapter 7 · Subscription Formats and Config Compatibility

Three Common Formats

What people casually call a "subscription" actually comes in three different forms, each with its own compatibility scope. The first is a Clash-native subscription: a complete YAML document with all three sections — proxies, proxy-groups, and rules — which a Clash-based client can consume directly. This is the ideal case. The second is a single-node share link, like a ss://, vmess://, or trojan:// URI — one link describes one node, with no grouping or rule info at all. The third is a generic aggregate subscription: multiple share links Base64-encoded together and served over HTTP, the closest thing to a common denominator across different client ecosystems. Neither of the last two is Clash's native format, and both need converting before use — most subscription providers also offer a Clash-native address, which you should prefer when available. mihomo-based clients generally have built-in parsing for common share-link formats, but the conversion only produces nodes; grouping and rules still need to come from a config file.

Separating Nodes from Config: proxy-providers

A more advanced technique worth knowing is proxy-providers: it declares node sources as external resources, so the main config handles only grouping and rules while the kernel pulls updated nodes on a schedule. The value here is that your custom rules and subscription updates don't step on each other — if you edit the full config a subscription pushes down directly, your changes get wiped out on the next update, whereas a providers-based setup can be maintained long-term. A typical declaration looks like this:

proxy-providers:
  main:
    type: http
    url: "https://example.com/sub?token=xxxx"
    interval: 86400
    path: ./providers/main.yaml
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

Compatibility Notes

Three practical lessons worth noting. First, the same subscription URL can return different content to different clients — servers commonly inspect the request's User-Agent to decide the client type and respond accordingly, so what you see opening the subscription URL in a browser may not match what the client actually receives; don't use a browser to debug subscription issues. Second, whether newer protocol nodes show up depends on both the subscription's output and the client's kernel: even if your client runs mihomo, if the subscription server still only outputs original-kernel fields, Hysteria2 and VLESS nodes simply won't appear in the list — ask your provider for a mihomo-format subscription address in that case. Third, set an auto-update interval after importing a subscription; a subscription that never updates is one of the most common causes of "every node times out." For the full import walkthrough, see Getting Started; for a deeper look at format differences, see the blog post "How to Import a Clash Subscription Link".

Chapter 8 · Protocol Picks by Use Case

A Baseline Assumption Before You Choose

Let's clear up a common misunderstanding first: there's no "pick a protocol" switch anywhere in a Clash client. What we mean by "choosing a protocol" is favoring certain node types within the list a subscription provides — most subscriptions mix multiple protocols, and the same region often offers several node types at once. Proxy groups can also mix nodes of different protocols and auto-switch based on latency. So here's how to use the recommendations below: find your scenario, favor that node type in your list, and keep one fallback type on hand.

Scenario Reference Table

Three Additional Notes

First, gaming and video-call scenarios also involve how traffic gets intercepted, beyond just the protocol: these apps often ignore system proxy settings and need TUN mode enabled in the client to be captured properly. See the blog post "What's the Difference Between Clash TUN Mode and System Proxy" for how the two capture methods differ. Second, when balancing battery life against speed on mobile, lean on the battery column from Chapter 5 as your main guide, and only enable QUIC-based nodes when you genuinely need them for poor networks or heavy traffic. Third, no recommendation here replaces real-world testing — nodes of the same type can vary more between servers and lines than protocols vary from each other, so once you've picked a type, still compare it in practice during your actual usage hours.

Three Steps to Wrap It Up

Everything in this handbook boils down to three steps. First, check your client's kernel: an actively maintained mihomo-based client (Clash Plus is the top pick on every platform, installers on the Download page) gives you all six protocols; switch away from an older kernel first if needed. Second, check what your subscription actually provides: look at which node types show up in your list, and ask your provider for a mihomo-format subscription if the type you need is missing. Third, sort by scenario using the table above and verify with real-world testing, keeping one TCP-based node as a fallback. For step-by-step setup help, see Getting Started; for specific errors, check the FAQ page.