▶Protocol Guide: Choosing Among 6 Protocols and 3 Kernel Generations

Protocol Landscape: Where the 6 Mainstream Protocols Came From and What They Solve

Start with one throughline: the history of proxy protocols is really a history of repeatedly balancing encryption, camouflage and speed. The six protocols commonly seen in client subscriptions — Shadowsocks, VMess, Trojan, VLESS, Hysteria2, TUIC — belong to three generations, each a direct response to the shortcomings of the one before it. Once you understand where each one starts from, every comparison table that follows will make sense.

Shadowsocks: The Lightweight Encryption Starting Point

Shadowsocks (often shortened to SS) is the oldest of the six. Its design goal fits in one sentence: wrap TCP traffic in symmetric encryption with as little overhead as possible. There's no handshake negotiation, no session concept — client and server agree on the same password and cipher method ahead of time, and ciphertext flows directly once the connection opens. The upside is immediate: dead-simple implementation, low CPU usage, mature implementations on nearly every platform. The trade-off is just as clear — the traffic pattern is relatively fixed and there's no metadata-level camouflage. The community later added AEAD cipher suites (such as aes-128-gcm and chacha20-ietf-poly1305), fixing the integrity flaws of early stream ciphers — which is why modern configs recommend AEAD methods only.

VMess and VLESS: Two Generations With a Session Layer

VMess comes from the V2Ray project and takes SS a step further: it introduces a user ID (UUID), timestamp validation and dynamic metadata, so no two connection headers look alike, and it supports transports like WebSocket and gRPC. Flexibility is its biggest selling point — and complexity is its biggest burden. Header computation is heavier, and the timestamp mechanism requires client and server clocks to stay closely in sync; a phone with the wrong time failing to connect is a classic VMess complaint. VLESS is the same community's "stripped-down" answer to VMess: it drops built-in encryption and timestamp checks, outsourcing encryption entirely to the underlying TLS layer and keeping only identity and routing info in the protocol body. The result is a smaller header and faster forwarding — but it must be paired with TLS (or a derivative like REALITY); bare VLESS offers no confidentiality at all.

Trojan: Hiding Inside Ordinary HTTPS Traffic

Trojan took a different approach: instead of inventing a new encryption format, make proxy traffic look identical to ordinary HTTPS. It reuses the standard TLS handshake directly, the server carries a real certificate, and failed validation attempts get quietly redirected to an ordinary website. To an observer, a Trojan connection is indistinguishable from a normal page load. That comes with trade-offs: it needs a domain and a valid certificate, raising the deployment bar above SS; every byte passes through a full TLS layer, so single-core encrypt/decrypt throughput runs slightly below lighter protocols — in exchange for the most reliable way to blend into the background.

Hysteria2 and TUIC: The QUIC-Era Speed Boosters

The first four protocols all run on TCP and are bound by its congestion control and head-of-line blocking: lose one packet, and the whole connection waits for a retransmit. Hysteria2 and TUIC swap the foundation for UDP-based QUIC. Hysteria2's core is an aggressive built-in congestion-control strategy aimed squarely at high-loss, high-latency long-haul links, and the throughput gain on poor networks is very noticeable. TUIC is more "by the book," sticking close to the QUIC spec for multiplexing and 0-RTT fast handshakes, chasing low latency while keeping protocol behavior gentle. Both share the same weak spot: some networks throttle or block UDP outright, and in that environment QUIC-family protocols end up less stable than plain old TCP — so they're a "situational speed boost," not a mindless default.

Transport-Layer Trade-offs: Three Paths — TCP, TLS and QUIC

Protocol comparisons often get reduced to "which one is faster," but the real first variable behind the experience is the transport-layer path. Split the six protocols into three camps by their foundation, and a lot of behavior suddenly makes sense.

The Direct-TCP Camp: SS and Bare VMess

SS and VMess without TLS send custom ciphertext straight over TCP. Pros: best compatibility — it runs on any network that allows TCP, and the implementation is light enough for older devices and routers to handle. Cons: the custom ciphertext is itself a detectable pattern, and TCP head-of-line blocking on a lossy link noticeably drags down felt speed — latency numbers might not look bad, but page loads stutter, which is exactly the "good numbers, bad experience" pattern broken down in How to Read Latency Test Numbers.

The TLS-Wrapped Camp: Trojan, VLESS and WebSocket VMess

This camp puts traffic inside a standard TLS session. It looks identical to normal HTTPS and has the highest success rate getting through middleboxes; paired with a CDN front (common with VMess/VLESS + WebSocket) it can also hide the real server address. The cost is more handshake round trips: TCP's three-way handshake plus a TLS handshake means first-byte latency is naturally a notch higher than the direct camp, and every byte crosses a TLS encrypt/decrypt pass, so throughput ceiling depends noticeably on single-core CPU performance.

The QUIC Camp: Hysteria2 and TUIC

QUIC merges the encryption handshake with the transport handshake, so ideally one round trip is enough to connect — even faster with 0-RTT — and stream-level multiplexing sidesteps head-of-line blocking entirely, so a lost packet on one stream doesn't touch the others. When a mobile network switches (Wi-Fi to 5G), QUIC's connection migration also makes reconnecting smoother. The weak spot, as noted above: UDP is a "second-class citizen" on some networks, and throttling causes performance to fall off a cliff.

Connection Speed and Resource Use: The Patterns Behind the Numbers

The conclusion first: on the same server and same line, the "maximum bandwidth" gap between the six protocols is usually smaller than the line's own fluctuation. What actually drives the felt difference is first-byte latency, packet-loss recovery and CPU bottlenecks. Let's take them one at a time.

First-Byte Latency: Handshake Round Trips Set the Floor

Opening a new website requires the client to connect to the proxy server first. SS needs only a TCP three-way handshake before sending data — the fewest round trips; Trojan/VLESS must complete a TLS handshake on top of TCP, adding one to two round trips; Hysteria2/TUIC fold both steps into one via QUIC, a clear win on long-haul links, and TUIC's 0-RTT can send data with the very first packet on a repeat visit to the same server. At 50ms of link latency these gaps barely register; above 200ms, every round trip saved is visibly faster.

Throughput and CPU: The Cost of the Encryption Path

At full download speed, the bottleneck is often the encrypt/decrypt path rather than the line itself. SS with an AEAD suite has the lowest per-byte overhead and can get an old router close to line speed; the TLS path in Trojan/VLESS is manageable on modern CPUs with AES-NI support but hits its ceiling before bandwidth does on low-end ARM devices; QUIC-family protocols are mostly implemented in userspace today, so at the same throughput their CPU usage generally runs higher than TCP stacks whose kernel-level optimizations are already mature — which is why "Hysteria2 benchmarks fast, but the fan spins up too." Desktops usually don't notice; soft routers and TV boxes need to take this seriously.

Packet-Loss Recovery: The Dividing Line on Poor Networks

On links with over 1% packet loss, TCP-family protocols get throttled hard by congestion algorithms, and every request sharing that one connection stalls together; Hysteria2's aggressive compensation strategy can often pull usable bandwidth back several times over in that environment, and TUIC's stream isolation ensures one stuck request doesn't drag down the others. Conversely, on a good low-loss link the real speed gap between the three camps is negligible, so protocol choice should be driven by camouflage and compatibility, not benchmark numbers.

Mobile Battery Impact: How Protocol Choice Affects Battery Life

A phone running a client and draining all night has protocol choice as one variable, but usually not the biggest one. This section isolates the protocol-related factors specifically; for system-level checks (battery whitelisting, background policy, probe interval) see the blog's Android Battery Drain Checklist.

Radio Wake-ups: Packet Frequency Is the Hidden Culprit

A phone's baseband chip has a sleep/wake state machine, and every send or receive can pull the baseband out of a low-power state — and it then stays awake for a while afterward. So battery drain has little to do with total data volume and a lot to do with "how often a packet arrives." The more frequent the heartbeats, keep-alives, or probes built into a protocol or its upper layer, the harder it is for the baseband to sleep, and the more it drains overnight on standby.

Battery Profiles of the Three Protocol Camps

TCP-family protocols carry no mandatory heartbeat of their own, so an idle connection produces almost no extra wake-ups — good for standby. Worth watching: WebSocket-based VMess/VLESS, where some servers configure periodic ping frames, and too short an interval turns into a classic battery drain. QUIC-family protocols typically carry built-in keep-alive probes to maintain the NAT mapping and enable connection migration, so idle wake-up counts naturally run higher than TCP-family. The payoff is not having to tear down and reconnect on a network switch — for a commute scenario that flips between Wi-Fi and cellular often, one full reconnect (fresh handshake, fresh node probing) can drain more than a few extra keep-alives would. So the conclusion isn't one-sided: heavy mobile switchers may actually save power with QUIC-family protocols, while users who sit on one network for long stretches do better with TCP-family.

Practical Battery-Saving Rules

• Mostly-idle devices: prefer SS or Trojan, and avoid WebSocket configs with an aggressive heartbeat interval.
• Frequent network switching on commutes: try TUIC or Hysteria2 to leverage connection migration and skip re-handshakes.
• Regardless of protocol: push the policy group's auto speed-test interval to over ten minutes — the probing itself is a wake-up source too.
• Keeping TUN mode always-on takes over all system traffic, so higher battery use than proxying select apps only is expected; enable it as needed.

Kernel Family: How Original, Meta and mihomo Relate

One fact to nail down first: these three names aren't three competing products — they're three stages on the same line of development. Understanding the family tree clears up most client-choice and config-compatibility confusion. For a fuller timeline, see the blog's Kernel Differences Compared.

Original Kernel: Founder of the Rule-Based Routing Paradigm

The original Clash kernel established the skeleton every derivative still uses today: YAML config, a proxies node list, proxy-groups policy groups, a rules section, and the paradigm of deciding traffic destination by domain and IP rules. It natively supported the mainstream protocols of its time — SS, VMess, Trojan — but never supported the later-arriving VLESS, Hysteria2 or TUIC. The original repository has stopped updating; the original kernel is now a "historical stage," and new users shouldn't build an environment around it.

Meta Fork: The Community-Driven Feature Expansion

While the original was still active, the community-maintained Clash.Meta fork was already moving in parallel: adding support for newer protocols (VLESS, the Hysteria family, TUIC), enhancing TUN mode, extending DNS and sniffing capability, and introducing more flexible rule syntax like sub-rules. It stayed backward-compatible with original configs — old config files generally run fine on the Meta kernel — but not the other way around: a config using Meta's extended fields throws "unsupported"-style errors on the original kernel.

mihomo: The Current Name for the Same Kernel

After the original repository was archived, the Meta fork was renamed mihomo and development continues under that name. **mihomo is the current name for Clash.Meta; they are the same project**, with the config format, CLI behavior and API all carried forward unchanged. Today's mainstream clients — including Clash Plus, the top recommendation on the Downloads page, along with Clash Verge Rev, FlClash, Clash Nyanpasu and Clash Meta for Android — all run on the mihomo kernel or a derivative of it. Seeing "based on the mihomo/Meta kernel" in a client's description means all six protocols and features like TUN and sniffing are supported.

Config Fields and Kernel Compatibility: What Only Newer Kernels Recognize

The most common failure with a subscription or a hand-written config is a field the kernel doesn't recognize. This section walks the compatibility boundary field group by field group; for a full field-by-field read of a config file's structure, see Anatomy of a Config File.

Skeleton Fields Common to All Kernels

Top-level fields like port, socks-port, mixed-port, allow-lan, mode, log-level and external-controller have carried over from the original era and are recognized by any kernel. Basic node syntax for SS, VMess and Trojan under proxies is likewise universal. A config using only these fields will run on any client.

Extended Fields Supported Only by Meta/mihomo

If any of the following appear, the config only runs on a Meta/mihomo-family kernel: nodes with type vless, hysteria2 or tuic; a full tun block (including stack, auto-route, dns-hijack); a sniffer block; GEOSITE-style rules and some extended rule types; and the enhanced parameters of proxy-providers and rule-providers. A minimal Hysteria2 node example:

proxies:
  - name: "Example-Hysteria2"
    type: hysteria2
    server: hy2.example.com
    port: 443
    password: "your-password"
    sni: hy2.example.com

Compared with a universally-supported Shadowsocks node, you can see the extended protocol just adds a few fields — the skeleton is identical:

proxies:
  - name: "Example-SS"
    type: ss
    server: ss.example.com
    port: 8388
    cipher: chacha20-ietf-poly1305
    password: "your-password"

Three-Step Compatibility Troubleshooting

1. Confirm the kernel: open the client's settings page and check the kernel label — mihomo or Meta means it's a modern kernel. It's usually shown right next to the version number.
2. Read the error keyword: "unsupported type" or "unknown field" in the log basically confirms an older kernel hit a newer field.
3. Upgrade, don't downgrade: switch the client to a version built on the mihomo kernel (every actively maintained client on the Downloads page qualifies) rather than stripping fields from the config to appease an old kernel.

Subscription Format Compatibility: What Happens When You Switch Clients

A subscription is a mechanism where one URL turns into a full set of node configs — but the format isn't universal across ecosystems. Understanding the three common forms means switching clients or platforms won't leave you puzzled.

Clash YAML Subscriptions: The Native Format for This Ecosystem

A subscription link returns a full YAML config (or at least a proxies block), which the client loads directly. This is the native format for Clash-family clients and carries the most complete field information — node parameters, policy group structure and the rules block can all ship together. The one thing to watch: if the returned config includes Meta's extended fields, an older kernel client will fail to load it, with the error behavior described in the previous section.

Share Links and Base64 Bundles: The Cross-Ecosystem Common Denominator

Single-node share links starting with ss://, vmess:// or trojan://, plus Base64-bundled subscriptions made of a pile of such links, are the universal exchange format across client ecosystems. They describe only the nodes themselves, with no policy groups or rules included. Most mihomo-family clients can recognize these subscriptions directly and apply a default policy group automatically; reverse compatibility depends on the target client — the share-link format for some protocols (especially Hysteria2 and TUIC) varies in implementation detail between vendors, so losing a parameter on cross-ecosystem import is a fairly common occurrence.

Subscription Conversion: Convenient, But Know What Gets Lost

Subscription conversion services translate one format into another, commonly used when "the provider only offers a generic subscription but the client wants a full YAML." Three things worth knowing: first, conversion generates policy groups and rules from a template, so any routing logic not in the original subscription was added by the template, not intended by the provider; second, uncommon protocol parameters (like Hysteria2's bandwidth hint field) can get silently dropped during conversion — suspect this first if a node won't connect; third, a subscription link contains credentials, so handing it to a public conversion service means handing over your node info — self-hosting or using a client's built-in local conversion is safer. More subscription-related Q&A is in the Help Center.

Scenario-Based Picks: Ready-Made Answers

Everything above funnels into this section. Find your own scenario, try the recommendations in order in the client, and whichever connects and stays stable first is the right answer for your environment.

Everyday Desktop Use: Browsing, Office Work, Development

What to do: prefer Trojan or VLESS + TLS, with SS as a backup. Desktop CPUs have plenty of headroom, TLS overhead is imperceptible, and camouflage matters most. What you'll see: stable latency, no drops on long-running sessions. Pair it with Clash Plus on Windows or macOS, and the default rule setup from the Getting Started Guide is enough.

Mobile: Commuting and Outdoors

What to do: pick TUIC or Hysteria2 for frequent network switching to take advantage of QUIC's connection migration; pick SS or Trojan if you sit on one network and care most about battery life. What you'll see: faster recovery after a network switch, or overnight standby drain tightening up. Tune this together with the probe-interval settings from the battery section above.

Poor Networks and Long-Haul Links: High Loss, High Latency

What to do: Hysteria2 first, TUIC second. What you'll see: throughput noticeably recovers on the same bad line, and video scrubbing stops spinning. If your network throttles UDP (showing up as all QUIC nodes timing out or dropping speed sharply), fall back to Trojan.

Routers and Always-On Servers

What to do: prefer SS (AEAD) for the lowest CPU cost; consider Trojan if the device has headroom to spare. Run the mihomo CLI build for the kernel directly — the Kernel section of the Downloads page offers packages for every architecture. What you'll see: even a low-end ARM device can forward close to line speed. QUIC-family protocols run heavier on CPU on soft routers, so be cautious about keeping them always-on.

One Subscription, Multiple Protocols: Recommended Setup

Most providers offer multiple protocol entry points for the same node. Recommendation: group same-region nodes across different protocols into one policy group in the client, and manually switch between them for a few days to compare; pick a client built on the mihomo kernel so all six protocols are available and you never have to pick a client to accommodate a protocol.

Common Misconceptions and Further Reading

One last pass through the most frequent misunderstandings — each one maps to a real pattern of help requests.

Misconception 1: Newer Protocols Are Always Better

Not true. Hysteria2 and TUIC are specialized solutions for specific conditions (poor networks, frequent switching) — on a good wired connection they offer no felt advantage over Trojan and cost more CPU and battery. Pick a protocol based on fit with your environment, not its release date.

Misconception 2: Low Latency Means a Fast Protocol

Not equivalent. The latency a client shows is a single probe round trip and carries no information about throughput, packet-loss recovery or handshake cost. SS and Trojan on the same node can show nearly identical probe numbers while the real-world experience on a poor network differs by several times. See the mechanics in Decoding Latency Numbers.

Misconception 3: Meta and mihomo Are Two Separate Kernels to Choose Between

They're two names for the same project at different points in time. Whichever name shows up in a client's description, the capability set is identical — there's no choice to make.

Misconception 4: A Subscription That Works in Client A Will Always Work in Client B

It depends on the overlap between subscription format and kernel version. A YAML subscription with extended fields gets rejected by an older kernel; a generic subscription imported cross-ecosystem can lose parameters. If a switch breaks the connection, run through the three-step method in the config compatibility section first, then check the matching entry in the troubleshooting category of the Help Center.

Misconception 5: Routing Failures Are the Protocol's Fault

Probably not. Routing is decided by the rules block and DNS behavior, not the node's protocol; the most common root cause of broken routing is a DNS leak or a misconfigured fake-ip setup — see the troubleshooting path in DNS Leak Detection and Fixes.

After reading this page, you have everything you need to choose a protocol and kernel. Next step: grab a client for your platform from the Downloads page, then follow the Getting Started Guide through importing a subscription, choosing a mode and verifying the connection.