Clash Protocol & Kernel Reference

Chapter 1 · Start Here: How to Use This Page and How It Differs from the Tutorial

This site has two main tracks. The Tutorial page is the setup track: install a client, import a subscription, pick a mode, verify routing — follow it through and you're up and running, no need to understand protocol details along the way. This page is the other track — a systematic reference that answers "why" and "which one": what each protocol type in your node list actually is, where the speed differences come from, which one saves more battery on mobile, and how the various kernels are actually related to each other. The two pages complement each other: for first-time setup, go through the Tutorial page first; once things are running and you want to understand the options in your node list, come back here and work through it chapter by chapter.

This page is organized around selection decisions, not alphabetically. Chapters 2 and 3 cover the protocols themselves: first the origins and design tradeoffs of the classic trio — Shadowsocks, VMess, and Trojan — then the specific problems the newer VLESS, Hysteria2, and TUIC each set out to fix. Chapters 4 and 5 make direct comparisons: connection speed, throughput bottlenecks, CPU and memory use, and the battery behavior mobile users care about most. Chapters 6 and 7 move to the software layer that carries these protocols: kernel lineage, configuration compatibility, and why a subscription format works in one client but throws an error in another. Chapter 8 rolls everything up into a scenario-based selection checklist.

There are three reading paths, depending on who you are. If you're new to Clash, read Chapters 2 through 4 in order to build the three-layer mental model — protocol is the transport scheme, kernel is the execution engine, client is the interface — everything else hangs off this framework. If you're already using Clash but hit a specific issue like "this type of node won't connect" or "this protocol drains battery fast," jump straight to Chapter 5 and Chapter 7, paired with the matching entries in Troubleshooting. If you're just picking a client for family or friends and don't plan to dig deeper, the kernel comparison table in Chapter 6 and the scenario checklist in Chapter 8 are enough — ten minutes and you're done.

A quick note on terminology. On this page, "protocol" refers specifically to a node's transport protocol type — the value of the type field under proxies in the config file; "kernel" refers to the core program that actually handles traffic; "client" refers to the graphical software shell around it. Full definitions of individual terms live in Concept Reference, and step-by-step fixes for specific issues live in Troubleshooting — this page doesn't repeat them, so just look up any unfamiliar term as you go.

One more boundary worth stating up front: this page only discusses engineering tradeoffs — handshake round trips, encryption overhead, battery use, compatibility — and doesn't evaluate any provider or touch on where nodes come from. Which protocol a node uses is decided by the subscription provider; the two real choices readers have are picking a client whose kernel covers everything their subscription uses, and knowing which node type to switch a proxy group to when a subscription offers several protocols at once. Every recommendation on this page comes from those two decision points.

Chapter 2 · The Classic Trio: Origins and Tradeoffs of Shadowsocks, VMess, and Trojan

Start with the three veterans. They appeared early, are deployed everywhere, and are supported by nearly every kernel — the most common types you'll find in any subscription. Understanding their design starting points is what lets you see exactly what's "new" about the newer protocols later on.

Shadowsocks: The Art of Doing Less

Shadowsocks (written as ss in config files) was the earliest of the three to take shape, and its design philosophy is "do less": client and server agree on a pre-shared key, and traffic is wrapped and forwarded directly with symmetric encryption — no extra session negotiation, no complex metadata structures. Current implementations generally use AEAD cipher suites (such as aes-128-gcm and chacha20-ietf-poly1305), which handle both encryption and integrity checking. Doing less pays off directly in speed and efficiency: there's almost no protocol-level round trip added to connection setup, encryption overhead is negligible on modern CPUs, and it runs fine even on Raspberry Pi-class routers. The tradeoffs are just as clear: the protocol carries no transport-layer multiplexing of its own, so each connection is independent, and there's little room to extend it — adding capability means stacking a plugin on top. In one line: light, fast, most friendly to old hardware, and the fallback choice for "just needs to work" scenarios.

VMess: Fields Borrowed from an Ecosystem, and the Weight They Carry

VMess comes out of the V2Ray ecosystem, and its approach is the opposite of Shadowsocks — do everything. It comes with its own user ID system, built-in encryption, and a freely combinable transport layer (plain TCP, WebSocket, HTTP/2, and more can all be layered on), and the richer field set lets servers do fine-grained user and routing management. But more fields also means more baggage: VMess's authentication depends on timestamp checks between client and server, and a large clock drift between the two causes the handshake to fail outright — the classic symptom of "every VMess node times out while other protocols work fine" is, nine times out of ten, a local clock that's off, and the full diagnostic flow is in Node Timeout: A Diagnostic Checklist. VMess is also commonly paired with WebSocket + TLS, which adds encapsulation layers, so its connection setup takes more round trips and more CPU than Shadowsocks. In short: a mature ecosystem and flexible configuration, but a "heavy" option — new deployments are increasingly moving to VLESS instead.

Trojan: Borrowing the Well-Worn Path of HTTPS

Trojan takes yet another approach: instead of inventing its own encryption, it puts traffic directly inside a standard TLS connection, so the server behaves exactly like an ordinary HTTPS website. The engineering payoff is real — TLS is the most thoroughly vetted encrypted channel on the internet, its handshake path is mature, it's compatible with virtually every kind of network middlebox, and client implementations are simple. The cost is that the deployment burden shifts to the server side: it needs a valid domain certificate, and an expired certificate or broken DNS will take the whole node down — a failure mode the client can't fix, only the subscription provider can. From a user's standpoint, Trojan nodes are typically stable day to day with predictable latency, making them a safe choice for browsing and video.

Chapter 3 · Next-Gen Protocols: What VLESS, Hysteria2, and TUIC Each Fix

None of the three newer protocols appeared out of nowhere — each targets a specific pain point from the previous chapter. When looking at them, focus on one question: what did it move out of the protocol layer, and what did it add weight to instead?

VLESS: Trimming VMess Down

VLESS can be thought of as VMess with things subtracted: it drops the built-in encryption and timestamp check, hands confidentiality entirely to the outer TLS layer, and keeps only the minimal user identifier and routing info in the protocol itself. With one less encryption layer, CPU overhead drops noticeably, and handshake failures from clock drift disappear — the two things VMess users complained about most, solved in one move. It's often paired with newer transport schemes, such as transports optimized around TLS session characteristics, and whether those combinations work depends on the kernel version — more on that in Chapter 7's discussion of subscription compatibility. One rule of thumb: if a subscription has both VMess and VLESS nodes and the client's kernel supports it, pick VLESS — it's close to a pure win with no downside.

Hysteria2: A QUIC-Based Design for Poor Links

Hysteria2 (written as hysteria2 in config files) changes the foundation entirely: instead of TCP, it's built on QUIC (a modern transport protocol running over UDP), paired with an aggressive custom congestion control strategy. This combination targets one specific scenario — high-packet-loss, high-jitter links, such as mobile networks or long-distance cross-carrier connections. Traditional TCP backs off sharply on packet loss, causing throughput to fall off a cliff; Hysteria2's strategy is to keep pushing at a preset bandwidth and simply retransmit whatever's lost, which often gives it noticeably better throughput than TCP-based protocols on weak links. There are two tradeoffs: its constant bandwidth estimation and retransmission logic give it no advantage on "good" links while still burning more resources, and because it runs over UDP, a few network environments throttle or interfere with UDP traffic, in which case it performs worse than TCP-based protocols. In short: a weak-link powerhouse, unremarkable on good links.

TUIC: Making Full Use of QUIC's Multiplexing

TUIC is also built on QUIC, but with a different focus: it makes full use of QUIC's native multiplexing and 0-RTT session resumption — multiple proxy requests share a single QUIC connection without blocking each other, and a server you've connected to before can resume the session in nearly zero round trips, making a second connection almost instant. This gives a noticeable boost for high-frequency, small-request scenarios like web browsing and instant messaging. Compared with Hysteria2, TUIC's congestion control is closer to a conventional implementation — it doesn't aggressively grab bandwidth, so its ongoing overhead is gentler. Because it also runs over UDP, it inherits the same environmental dependency as Hysteria2: performance suffers on networks that are unfriendly to UDP.

Chapter 4 · Speed & Resource Use: The First Byte Comes Down to Handshake Round Trips

"Which protocol is faster" is the most-asked and most-often-misanswered question. Start by splitting "fast" into two halves: connection speed (the brief moment between clicking a link and content starting to load) and sustained throughput (the steady rate you get downloading a large file or watching a high-bitrate video). The two are governed by completely different factors, so weigh them separately when choosing.

Connection Speed: Count the Round Trips

Connection speed comes down almost entirely to how many round trips the client and server need before data can flow, and each round trip costs one RTT (round-trip time). Roughly counting: Shadowsocks runs over TCP and can send data right after one TCP handshake; Trojan and VLESS need an additional TLS handshake on top of TCP, adding a round trip; VMess, when paired with WebSocket+TLS, stacks on yet another upgrade handshake, giving it the most round trips of all. The QUIC-based Hysteria2 and TUIC merge the transport and encryption handshakes into a single exchange, completing the first connection in one round trip; TUIC's 0-RTT resumption goes a step further, costing almost no round trips at all when reconnecting to a server it's talked to before. When the underlying physical latency is already high — say, an intercontinental link with RTT over 200ms — this round-trip gap gets magnified into a very noticeable difference: QUIC-based nodes in the same subscription feel "instant on click" while TCP-based ones "hesitate before moving," and this is usually why.

Sustained Throughput: The Bottleneck Is Rarely Encryption

During sustained transfer, modern CPUs can do AEAD encryption far faster than home broadband can push data, so encryption itself is rarely the bottleneck. What actually drives the gap is how the transport layer reacts to packet loss: TCP-based protocols (SS, VMess, Trojan, VLESS) are governed by the OS's TCP stack congestion control and slow down whenever packets are lost; Hysteria2 pushes through with its custom strategy and leads on weak-link throughput; TUIC sits somewhere in between. The conclusion is counterintuitive: on good links, throughput differences across all six protocols are small; on bad links, the differences come mainly from the transport layer, not the protocol itself.

Memory & CPU: A Rough Ranking

For resource use, a rough ranking is enough. CPU overhead from low to high is roughly: SS ≈ VLESS < Trojan < TUIC < VMess ≈ Hysteria2 — VMess loses out to its layered encapsulation, Hysteria2 to its constant bandwidth probing. Memory differences come mainly from connection count rather than protocol: QUIC-based protocols carry many requests over a single connection, so the total connection count is lower, which actually favors memory use; on devices with memory measured in single-digit MB, like routers, Shadowsocks's minimalist implementation remains the only safe bet.

Chapter 5 · Mobile Battery: Three Sources of Drain, Protocol Is Just One

"My phone drains faster with Clash on" is the most common mobile complaint. Start by breaking down where the drain actually comes from: three independent layers — the protocol's own keep-alive behavior, the client's health-check strategy, and how the system keeps the process resident. Check each layer separately, or you'll end up blaming the protocol unfairly.

Protocol Layer: UDP Keep-Alive Is a Hidden Battery Drain

QUIC-based protocols (Hysteria2, TUIC) need to send periodic keep-alive packets to maintain their UDP sessions, and Hysteria2's bandwidth-probing logic keeps running while a connection is active. Every packet sent briefly wakes the device's radio module, and radio wake-ups are the single biggest drain on mobile battery. TCP-based protocols (SS, Trojan, VLESS) can stay silent for long stretches when idle, letting the system drop into a deeper power-saving state. So for battery-conscious use, the conclusion complements Chapter 4 nicely: use QUIC-based protocols freely when plugged in or on Wi-Fi; prefer lightweight TCP-based protocols on battery over mobile data.

Client Layer: Health-Check Interval Is the Easiest Win

url-test-type proxy groups run a speed test against every node in the group on an interval cycle. Set that interval too tight (say, 60 seconds) and you're waking up dozens of nodes to test them every single minute. On mobile, widening the interval to 600 seconds or more makes almost no difference in felt latency, and the battery payoff is immediate:

proxy-groups:
  - name: Auto Select
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 600        # Recommended ≥600s on mobile
    tolerance: 80        # Don't switch when latency diff is under 80ms
    proxies: [Node A, Node B]

It's worth setting tolerance too: without it, two nodes with similar latency will keep flip-flopping, and every switch triggers a fresh connection setup. If your subscription is hosted by a provider and you can't edit the config, you can get the same effect by manually switching an auto-test group to a fixed select-type node in the client UI.

System Layer: TUN Persistence and Manufacturer Background Policies

TUN mode sets up a virtual network interface to take over all traffic, which means the process must stay resident, and Android manufacturers' aggressive background-kill policies will repeatedly try to kill and relaunch it — that kill-and-relaunch cycle drains more battery than staying quietly resident ever would. The mechanical differences between TUN and system proxy mode are broken down layer by layer in TUN Mode vs. System Proxy: How They Actually Differ; for a full checklist of tracking down drain sources via Android's battery stats and shutting them off one by one, see Android Battery Drain: A Troubleshooting Checklist. A good enough rule: if you don't need full traffic takeover on your phone, use system proxy mode and save TUN for desktop.

Chapter 6 · Kernel Families: How the Original, Meta, and mihomo Actually Relate

A lot of compatibility confusion comes from treating "Clash" as a single piece of software. It's actually a family: the kernel handles traffic according to the config, and the client is just an interface wrapped around it. Once the family tree is clear, the compatibility issues in Chapter 7 become obvious.

Family Tree: One Fork, Two Names

The original open-source project was the original Clash kernel, alongside a closed-source Premium build that added capabilities like TUN. After the original repository stopped being maintained, the community-run Clash.Meta fork took over as the main line of development, continuously adding new protocols and rule types, and was later renamed mihomo — so "Clash.Meta" and "mihomo" are two names for the same lineage at different points in time; "the Meta-family kernel" in everyday use refers to it. Today, mihomo is the only branch still actively maintained and supporting all six protocol types. The first thing to check when picking a client is which kernel it's built on.

Capability Differences at a Glance

One note on rules: mihomo stays backward compatible with the original kernel's common fields (port, mode, DOMAIN-SUFFIX, GEOIP, MATCH, and so on), so an old config fed directly into mihomo generally works as-is. It doesn't work the other way around — the moment a config contains even one line of mihomo-only syntax, the original kernel will error out and refuse to load it:

rules:
  - GEOSITE,category-ads-all,REJECT   # Only recognized by mihomo, errors on the original kernel
  - GEOIP,CN,DIRECT                   # Works on both kernel families
  - MATCH,Manual Select                # Works on both kernel families

Which Clients Use Which Kernel

On the Client Downloads page: Clash Plus (the top pick across all platforms), Clash Verge Rev, FlClash, Clash Nyanpasu, and Clash Meta for Android are all built on Meta-family capabilities, with all six protocols available; ClashX Meta is also Meta-family but no longer maintained; Clash for Windows runs on the original kernel and is no longer maintained — it's currently the most common cause of "subscription has new-protocol nodes but fails to load." If you're still using it, the full migration path to Clash Verge Rev is in Installing Clash Verge Rev on Windows: Full Walkthrough. The selection logic boils down to one line: if a subscription ever contains VLESS, Hysteria2, or TUIC, the client must be Meta-family — there's no second answer.

Chapter 7 · Subscription Formats & Field Compatibility: Why Switching Clients Throws Errors

There's another layer between protocol and kernel: the subscription itself. When the same subscription link shows a full node list in Client A but comes up completely empty in Client B, the problem almost always lives in this layer. This chapter lays out subscription formats and their failure modes.

Two Forms of Subscription

What a subscription link returns falls into two categories. The first is a complete Clash config (a full YAML file with proxies, proxy-groups, and rules) that a client can use as-is, with routing already written by the provider. The second is a generic node list (commonly a Base64-encoded bundle of share links), which Clash-family clients can't use directly — it needs to go through a subscription-conversion service to be translated into Clash format. That conversion step is a hidden variable: the template it uses determines which kernel family's syntax the output config speaks, and an outdated template can silently drop Hysteria2 nodes or output fields the original kernel doesn't recognize. When the node count looks wrong, confirm the subscription format first, then check the conversion config — don't do it in the reverse order.

Field Compatibility: One Field Can Sink an Entire Config

A YAML config loads as a whole, and different kernel implementations handle an unrecognized node type or field differently: lenient ones skip the node (fewer nodes show up), strict ones refuse to load the whole file (subscription import fails, node list is entirely empty). Take a Hysteria2 node as an example — the original kernel doesn't recognize any of its dedicated fields:

proxies:
  - name: Example-HY2
    type: hysteria2          # Not recognized by the original kernel
    server: example.com
    port: 443
    password: your-password
    sni: example.com

There's a pitfall in the other direction too: some clients "helpfully" rewrite the config on import, filling in default fields, and since the rewrite logic differs between clients, the same subscription can end up behaving slightly differently across them. When only one specific client misbehaves, the fastest way to pin down the cause is to open the subscription link directly in a browser and check the raw content.

Troubleshooting Order for Import Failures

Four fixed steps, in order: ① Confirm the subscription hasn't expired — most expired subscriptions return empty content or an error page rather than throwing an error; ② confirm the client is Meta-family (check against the table in Chapter 6); ③ check whether the subscription went through conversion and whether the conversion template supports every protocol in it; ④ check the YAML error line number in the client's log to pin down the exact field. The first two steps resolve most cases; the two most common symptoms — "node list is empty" and "every node times out" — each have their own complete walkthrough in Troubleshooting and Node Timeout: A Diagnostic Checklist, so just follow along.

Chapter 8 · Picks by Scenario: A Quick-Reference Checklist

The conclusions from the previous seven chapters are rolled up into a scenario-based table. How to use it: find your main scenario in the left column, then set or group your proxy groups in "first choice → fallback" order; if a subscription lacks the first choice, just fall back to the second — no need to force it.

Beyond the table, three general principles are worth keeping in mind. First, protocol choice always comes after node choice: quality differences between different nodes on the same protocol are usually bigger than differences between protocols on the same node, so filter your node pool with latency tests and real downloads before worrying about protocol preference. Second, lock in decisions with proxy groups instead of picking manually every day: group weak-link-friendly QUIC nodes into one set and battery-friendly TCP nodes into another, then switch groups when your scenario changes instead of hunting through dozens of nodes — how to set up proxy groups is covered step by step in the advanced section of the Tutorial page. Third, revisit periodically: providers adjust the protocol mix in their subscriptions and kernels keep evolving, so while this page's qualitative conclusions are stable, it's worth re-checking what's optimal for your specific subscription every few months.

Once you've decided, only two steps remain: grab a Meta-family client for your platform from the Client Downloads page — Clash Plus is the top pick across all platforms, with Clash Verge Rev or FlClash as alternatives on Windows/macOS/Linux — then head back to the Tutorial page to finish importing your subscription and verifying routing. If you get stuck anywhere along the way, Troubleshooting is indexed by category, and unfamiliar terms can be looked up in Concept Reference. That covers everything worth highlighting in this reference.