Clash Protocol and Kernel Technical Reference

Clash-family clients don't invent protocols themselves — they're a "multi-protocol outbound framework": each node in the config file declares its own type, and the kernel calls the corresponding protocol implementation. So the first step in choosing a protocol isn't arguing over which one is "fastest," but understanding what each protocol trades away by design and what it gains in return. The six mainstream protocols can be roughly grouped along two axes: whether the transport layer runs over TCP or UDP (QUIC), and whether the protocol relies on TLS for encryption.

Shadowsocks: Minimalist Encrypted Forwarding

Shadowsocks is the oldest of the six, and it was designed with a single goal: build an encrypted SOCKS forwarding channel between client and server with as little code as possible. Its header is extremely short, there's no handshake negotiation phase, and ciphertext flows immediately once the connection is up. The early stream-cipher schemes have been phased out; current implementations uniformly use AEAD cipher suites (such as aes-128-gcm and chacha20-ietf-poly1305), which provide both confidentiality and integrity checking. Its trade-off is clear: it sacrifices protocol-level extensibility (no multiplexing, no built-in UDP-over-TCP) in exchange for the lowest implementation complexity and the smallest per-packet overhead. It remains the go-to choice on low-power devices and older routers, and it's the "fallback node" type in many subscriptions. The SS2022 suite hardens key management and replay resistance, and at the kernel level it's treated as a different cipher under the same ss type.

VMess: The Feature-Rich Protocol of the V2Ray Era

VMess was born alongside the V2Ray project, and its positioning is the opposite of SS: it would rather be complex than lack features. Its header carries metadata such as user ID, encryption method, and timestamp, supports features like dynamic ports, and pairs naturally with V2Ray's transport plugin system (WebSocket, gRPC, HTTP/2). The cost is a heavier header than SS, and early versions relied on client-server time synchronization — if the local clock drifts too far, the handshake fails, which is a classic checklist item when a VMess node won't connect. VMess's real value lies in its ecosystem: a large number of panels and subscription-conversion tools were built around it, giving it broad compatibility. Judged purely as a protocol, its encryption and encapsulation design already feels heavy, which is exactly what led to VLESS.

Trojan: Hiding Inside the Shape of HTTPS

Trojan's approach is subtraction: since TLS already provides solid encryption, the protocol layer doesn't re-encrypt anything — it just sends a simple authentication header plus raw traffic inside the TLS tunnel. From the outside, a Trojan connection looks highly similar to ordinary HTTPS traffic in shape; connections that fail authentication get redirected by the server to a real website as a fallback. Its trade-off: it strongly depends on having a usable domain and certificate, raising the deployment bar above SS, but the client implementation is extremely thin and cheap to run. For end users, Trojan nodes behave predictably and consistently — the TCP + TLS combination has the best compatibility across all kinds of networks, and there's almost no risk of an ISP throttling this traffic specifically.

VLESS: A Leaner Next-Generation Framework

VLESS is the Xray ecosystem's rework of VMess: it drops the protocol's own encryption (leaving that to TLS), removes the timestamp dependency, and shrinks the header to the bare minimum, keeping only UUID authentication and the routing information that's strictly necessary. That makes it a "thin shell" — the real differentiation comes from whatever transport scheme it's paired with. XTLS Vision uses flow control to cut down the double-encryption overhead of TLS-in-TLS, while REALITY removes the requirement to hold your own certificate. Worth noting when choosing: VLESS itself has almost no overhead, so performance depends entirely on which combination the server is configured with — two nodes labeled vless in the same subscription can behave very differently in practice. The client side needs a kernel that supports the matching transport features, which is one reason the kernel section below emphasizes mihomo.

Hysteria2: A QUIC Protocol Built for Lossy Networks

Hysteria2 is built on top of QUIC, and its core selling point is custom congestion control: traditional TCP congestion algorithms back off dramatically on lossy links, and real throughput on transoceanic links is often a small fraction of the available bandwidth. Hysteria2 uses a much more aggressive sending strategy, letting users declare upstream/downstream bandwidth directly, and can hold close to the stated speed even on links with 5%+ packet loss. The trade-off is just as clear: aggressive sending crowds out other users' bandwidth on congested networks, and some ISPs apply QoS throttling to sustained high-volume UDP sessions — in that kind of network, QUIC-family protocols can actually be less stable than TCP-family ones. It's a good fit for "poor link quality but no UDP restrictions," not something to set as a mindless default.

TUIC: Another QUIC Path, Focused on Low Latency

TUIC belongs to the same QUIC family as Hysteria2, but with a different focus: instead of aggressively grabbing bandwidth, it leans fully on QUIC's native capabilities — 0-RTT handshakes make reconnects almost unnoticeable, in-connection multiplexing avoids head-of-line blocking, and native UDP relaying (native mode) is especially friendly to small, frequent packets from gaming and real-time voice apps. Congestion control can be set to cubic, new_reno, or bbr, and its behavior is gentler than Hysteria2's. Its weak point is a smaller ecosystem — fewer providers offer TUIC nodes than other protocols, and client support requires a kernel from the Meta lineage. In latency-sensitive scenarios without severe packet loss, TUIC generally feels the best of the six.

Split the six protocols by transport layer, and most of what comes up in performance discussions can be traced back to this layer. The mainstream forms of SS, VMess, Trojan, and VLESS run over TCP, while Hysteria2 and TUIC run over QUIC on top of UDP. The differences between the two paths show up in four areas.

Handshake Cost

Establishing a new TCP + TLS 1.3 connection needs a TCP three-way handshake plus a TLS handshake, putting time-to-first-byte at around two RTTs; QUIC merges the transport and encryption handshakes, needing just one RTT for a first connection and 0-RTT to send data straight away when resuming a session. On a transoceanic link with 200ms of physical latency, this gap is clearly noticeable in scenarios with frequent connection setup, such as the dozens of concurrent requests fired the instant a webpage opens. TCP-family protocols mitigate this with connection multiplexing (mux), but mux introduces the next problem.

Head-of-Line Blocking

TCP is a single ordered byte stream: one lost packet stalls all subsequent data on that connection, even data that belongs to unrelated requests. Multiplexing over a TCP connection means tying multiple requests to the same stream that can be stalled by a single point of failure, which actually makes the experience worse on lossy networks — this is the reasoning behind "don't casually turn on mux." QUIC transports data over independent streams within the protocol itself, so packet loss on one stream doesn't affect the others, making multiplexing a native, zero-cost capability.

Middlebox Friendliness

TLS traffic on TCP port 443 is the most common traffic shape on the internet, and any network has to allow it through; long-lived UDP sessions, on the other hand, get QoS-throttled, have their NAT timeouts shortened, or are outright dropped by some ISPs and enterprise networks. That's the root cause of QUIC-family protocols being "blazing fast one moment, unusable the next." Bottom line: TCP-family protocols are the safe bet in an unknown network environment, while QUIC-family protocols need real-world testing first.

Where Disguised Transports Fit In

Transport plugins like WebSocket and gRPC are optional shells that wrap TCP-family protocols, commonly used to route through a CDN; the cost is that every layer of wrapping adds latency and overhead, and CDN origin-fetching itself introduces an extra hop. QUIC-family protocols don't use this system at all. If two nodes with the same protocol name in a subscription use different transport shells, their latency can differ by a factor of two — treat them separately when testing speed.

The encryption/decryption overhead of these protocols is small on modern hardware; what actually creates the gap is the handshake model, congestion control, and the number of encapsulation layers. The table below is a qualitative comparison under equivalent link conditions — the direction of each comparison is reliable, but the exact multiplier varies by environment.

Two clarifications. First, QUIC-family protocols having higher CPU usage isn't encryption's fault — it's that the QUIC stack runs in user space, giving it a longer packet send/receive path than kernel-space TCP; this is unnoticeable on desktop hardware but measurable on low-power devices. Second, the gap in the "throughput on a lossy link" row is far larger than the table can express: on the same link with 10% packet loss, TCP-family protocols might only manage a tenth of the available bandwidth, while Hysteria2 can hold onto more than half. Link quality determines which row in this table actually matters to you.

Suggested testing method: running a latency test on nodes with different protocols from the same provider inside a client only reflects the handshake RTT, not throughput; throughput needs to be verified with an actual download or streaming test, done once during off-peak hours and once during peak hours. Every client on the download page has a built-in latency test, and Clash Plus's group speed test can benchmark every node in a group at once.

Battery usage from a proxy client on a phone comes from three parts: the baseline cost of keeping the VPN service resident, the CPU cost of the protocol stack processing traffic, and — most importantly — cellular/Wi-Fi radio wake-ups triggered by network activity. The third item is the biggest contributor. A protocol's effect on battery life is mostly transmitted through its heartbeat and reconnection behavior.

Heartbeats and Keepalives

TCP-family protocols depend on the NAT mapping staying alive, and clients or servers usually maintain it with a keepalive every few dozen seconds; each heartbeat can wake a dormant cellular modem into a high-power state for several seconds. QUIC-family protocols also need keepalives, but QUIC's connection migration lets a connection survive a network switch (between Wi-Fi and cellular) without a full reconnect; TCP-family protocols have to rebuild every connection from scratch after each network switch, triggering a burst of handshake traffic and radio activity. For usage patterns that switch frequently between Wi-Fi and cellular, QUIC-family protocols generally deliver better battery life.

Encryption and Protocol Stack Overhead

AEAD encryption/decryption is accelerated by hardware instructions, so the gap between protocols is negligible. The extra CPU cost of QUIC's user-space stack on mobile chips is measurable but not significant, and only shows up during sustained high-volume transfers (long video sessions); it's negligible for light browsing.

Factors That Matter More Than the Protocol

In practice, client configuration has a far bigger impact on battery drain than protocol choice: an auto-update interval that's too short for rule sets, a debug-level log setting, an aggressive concurrent DNS resolution strategy, or too-frequent automatic node speed tests can each drain more battery than the difference between protocols by an order of magnitude. See the blog article Troubleshooting Heavy Battery Drain from Clash on Mobile for a step-by-step checklist, including specific settings for the Android battery-optimization whitelist and iOS on-demand connections.

The name "Clash" refers to at least three things today: the original kernel project, which is no longer developed; its community-enhanced fork, Clash.Meta; and mihomo, which is simply Meta renamed and continued to this day. GUI clients (Clash Plus, Clash Verge Rev, FlClash, and others) are all graphical shells wrapped around a kernel, and the kernel is what determines the range of supported protocols and the ceiling on configuration syntax. Here's the lineage and the differences between the three.

Three Generations of Kernels

The original Clash established the YAML configuration format, the rule-based routing model, and the RESTful control API, and it supported the mainstream protocols of its time, such as SS, VMess, and Trojan; once development stopped and the repository was taken down, the original kernel stopped receiving any updates and simply doesn't support new protocols. Clash.Meta is the community's enhanced fork built on top of the original, adding newer protocols like VLESS, the Hysteria family, and TUIC, along with a large set of extra routing capabilities; it was later renamed mihomo to avoid a naming dispute, with the project itself, its configuration format, and its development team all continuing without interruption — mihomo simply is Meta under a new name. The only Clash-family kernel actively maintained in today's ecosystem is mihomo, and all the mainstream GUI clients have already migrated to it. For the full history of all three kernel generations, see the blog article Comparing the Original, Meta, and mihomo Clash Kernels.

Feature Comparison

Configuration Compatibility

mihomo is largely backward-compatible with original-kernel configs: a YAML file that runs on the original kernel can usually be loaded directly by mihomo. The reverse doesn't hold — as soon as a config contains a mihomo extension field (such as the hysteria2 node type, a TUN block, or an enhanced DNS field), the original kernel will error out and quit. To check whether a config depends on mihomo, search it for fields like these:

proxies:
  - name: hy2-node
    type: hysteria2      # not recognized by the original kernel
    server: example.com
    port: 443
    password: your-password

tun:                     # this block doesn't exist in the original open-source kernel
  enable: true
  stack: system
  auto-route: true

The conclusion here is direct: there's no reason to newly install the original kernel today. Protocol coverage, TUN mode, and maintenance status all point to mihomo; every GUI client on this site's download page is based on mihomo or a derivative of it, and the kernel section also offers bare mihomo builds for every platform, for server and router users.

A subscription is how a provider distributes nodes to a client, and format mismatches are the number-one cause of import failures. There are currently three main subscription formats in circulation.

Three Subscription Formats

The first is a Clash YAML subscription: a full or partial Clash config file with sections like proxies, proxy-groups, and rules. Clash-family clients support it natively, it carries the most complete information, and providers can pre-configure groups and routing rules. The second is a generic Base64 subscription: node share links such as ss:// and vmess:// are concatenated line by line and encoded as a whole; it contains only nodes, no rules, but has the longest history and the widest compatibility. Modern Clash clients can mostly auto-detect and convert it, but after conversion the client has to fill in its own groups and rules. The third is a proprietary format from another ecosystem (such as sing-box's JSON), which Clash-family clients don't support directly and needs to go through a subscription-conversion service first.

How Protocol Support Affects Subscriptions

A correct format doesn't mean every node will work: if a YAML subscription includes hysteria2, tuic, or vless nodes but the client's kernel is an old version or the original one, those nodes get silently dropped at best, or the entire config fails to load at worst. This shows up as "the subscription imported fine but I have fewer nodes than expected" or "the client errors out after updating the subscription." Order of investigation: first confirm the client's kernel is from the mihomo lineage, then check whether the subscription URL includes provider-specific Clash parameters (many providers serve different formats from the same subscription URL via URL parameters).

Managing Subscriptions with proxy-providers

For users who maintain their own config by hand, it's worth using proxy-providers to decouple "where nodes come from" from "group rules": nodes are pulled periodically from a subscription URL, while groups and rules are written into the local config, so a subscription update won't overwrite personal customizations. A minimal example:

proxy-providers:
  main:
    type: http
    url: "your-subscription-url"
    interval: 86400        # fetch interval in seconds — keep this from being too short on mobile
    path: ./providers/main.yaml
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

Pulling together everything above, here's a decision flow you can act on directly. Assumption: the node protocol is decided by the provider, so the advice below is for "which one to pick when the same provider offers multiple protocols" and "what to check first when switching providers."

Everyday Desktop Use (Work / Browsing / Video)

Prefer Trojan or VLESS. The TCP + TLS combination has the best compatibility on any network, low overhead, and stable behavior, with no surprises over long uptimes. When packet loss is noticeable (transoceanic links during peak hours) and the network doesn't restrict UDP, set a Hysteria2 node as backup and switch to it manually during peak hours. For a client, Clash Plus has group speed tests and rule management ready to go out of the box; if you prefer an open-source desktop option, Clash Verge Rev is a good pick.

Mobile (Phones / Tablets)

Choose Trojan / VLESS in environments with a stable signal; for scenarios with frequent network switching, like commuting, prefer TUIC (connection migration cuts down on reconnects, and 0-RTT reduces recovery latency after a switch). Avoid running Hysteria2 in the background long-term — its aggressive sending model isn't kind to battery life. Client configuration matters more than the protocol here: tighten update intervals and log levels according to the battery section above. iOS users can get Clash Plus through the App Store; see the tutorial page for the process.

Poor Networks and Lossy Links

Hysteria2 was designed for exactly this scenario and pays off the most; fill in the bandwidth parameters based on your real link — overstating upload bandwidth only makes packet loss worse. If UDP is being throttled (showing up as periodic drops in a QUIC node's speed), fall back to a TCP-family protocol and prefer nodes whose server side runs BBR congestion control.

Gaming and Real-Time Applications

Focus on UDP forwarding and latency jitter: TUIC (native UDP mode) and Hysteria2 natively forward UDP and are the top tier here; SS needs UDP support enabled on the server side; VMess / Trojan's UDP capability depends on the server implementation and generally lags behind the QUIC family. Before choosing, check whether your game uses UDP or TCP — turn-based and browser games run over TCP, where protocol differences barely matter.

Servers and Routers

For running the bare mihomo kernel, choose SS (lowest resource usage) or Trojan as the protocol; on low-power devices like MIPS / ARMv7, avoid the user-space stack overhead of QUIC-family protocols. Kernel builds for every architecture are in the kernel section of the download page, run from the command line:

mihomo -d /etc/mihomo    # start with a specified config directory

Quick Decision Table

Misconception 1: Some protocol is "fastest" across every scenario. There's no such thing. Speed is determined jointly by link quality, server load, and congestion control — the protocol is just one variable. The same protocol can rank completely differently on different links; the only reliable conclusion comes from repeated testing on your own link.

Misconception 2: A newer protocol is always better than an older one. SS is the oldest of the six, but it's still the lowest-overhead choice on low-power devices and stable links; the VLESS + REALITY combination is quite new, but requires matching kernel and server versions, and is harder to troubleshoot when something goes wrong. A protocol is a tool — matching it to the scenario matters more than chasing novelty.

Misconception 3: The client determines protocol performance. A GUI client is just a shell around the kernel — under the same mihomo kernel, different clients show no fundamental difference in protocol throughput. What differs between clients is the interface, platform adaptation, and configuration management; at the protocol level, all that matters is the kernel version.

Misconception 4: A low latency number means a good experience. The latency figure shown in a client is usually the RTT of a single HTTP handshake — it doesn't reflect throughput, packet loss, or stability. A node with 80ms latency but heavy packet loss during peak hours is a worse experience than one with 150ms latency that stays stable all day.

Misconception 5: Blame the protocol first when a config throws an error. Most load failures come from YAML indentation mistakes, a subscription format mismatch, or an outdated kernel version — the protocol itself being the actual problem is the least likely cause. Checking in the order "format → kernel → node → protocol" is the most efficient way to troubleshoot.

For handling specific error messages, see the troubleshooting category in the help center; every term used on this page has a matching entry on the glossary page. Once you've settled on a protocol, head back to the tutorial page to complete the import and verification steps, or go straight to the download page to get a client.