Protocol Guide: A Technical Reference for Protocols and Core Selection

CL-01About This Guide and How to Read It

First, where this guide fits on the site. Clash Library's content is organized like a reference library: the Download Center hosts client installers by platform, the tutorial covers the core path of importing a subscription, picking a mode, and confirming the connection works, the client comparison lines up clients side by side, and this page tackles the layer underneath all of that — the protocols and cores running inside your client. Most users have run into the ss, vmess, trojan, vless, hysteria2, and tuic type labels in a node list and wondered what they actually mean. They're not just different names — they determine how fast a connection establishes, how the connection holds up on a bad network, how much battery your phone burns, and whether a given node loads at all on an older core.

You don't need to read this guide start to finish. Each of the eight chapters stands on its own: CL-02 is a "profile card" for each of the six protocols, covering where they came from and what trade-offs they make; CL-03 and CL-04 compare performance side by side — the former on speed, the latter on resources and battery; CL-05 covers core families — how original Clash, Clash Premium, Clash Meta, and mihomo relate to one another, which is the key to understanding why the same config errors out on one client but not another; CL-06 covers subscription formats and config field compatibility; CL-07 rolls everything up into a pick-by-scenario table; CL-08 lists the most common mistakes people make when choosing a protocol. Each chapter opens with a short intro — read that first, then decide whether to dig deeper.

Two notes on how this guide is written. First, this is a technical reference for protocol selection, not a discussion of network policy in any country — comparisons are strictly engineering-level: handshake overhead, encryption cost, transport-layer characteristics, and ecosystem maturity. Second, this page avoids dumping large config blocks — protocol parameters can run to dozens of fields, and copying them verbatim doesn't help much. Minimal examples are included only where needed to identify field structure; for full setup steps, head to the tutorial page. Any server address or password shown here is a placeholder and should not be used as-is. If a term still feels unfamiliar after reading, search for it in Technical Notes, then come back here.

CL-02Protocol Overview: Origins and Design Trade-offs of Six Protocols

A protocol is the agreed-upon "language" between a client and a server. The six mainstream protocols emerged in different eras to solve different problems, so there's no single "best" — only different trade-offs. Start with the summary table below, then read each entry in detail.

Shadowsocks: The Minimalist's Starting Point

Shadowsocks is the oldest of the six, and its design philosophy is "do less": client and server share a password, traffic gets wrapped in symmetric encryption, and it's shipped straight through — no handshake negotiation, no certificate infrastructure. Modern implementations use AEAD cipher suites (aes-128-gcm, chacha20-ietf-poly1305) that balance integrity checking with performance. This minimalism has two clear upsides — the lowest CPU cost and the simplest implementation, which is why almost every core and client supports it. The trade-off is that its traffic pattern has been studied extensively over the years, so it offers limited cover on its own; in practice it's often paired with plugins like obfs or v2ray-plugin to dress up the transport layer. As a baseline, SS is still the top pick for old hardware, low-end routers, or anyone prioritizing battery life.

VMess: The Pioneer of Transport-Layer Flexibility

VMess comes from the V2Ray project, and its core contribution was decoupling the "protocol body" from the "transport layer": the same VMess session can run over plain TCP, WebSocket, or HTTP/2, then optionally wrap in TLS on top. That modularity made it the go-to for flexibility for a long time. The trade-off: its header carries a user ID, an encryption method declaration, and a timestamp check, so per-packet overhead is noticeably higher than SS. The timestamp check also requires client and server clocks to stay within roughly 90 seconds of each other — an inaccurate phone clock will cause the handshake to fail outright, which is the first thing to check when a VMess node mysteriously times out. VMess today is usually deployed as WebSocket + TLS, which is highly compatible but doesn't match newer protocols on raw performance.

Trojan: Hiding in Plain HTTPS

Trojan takes the opposite approach from the first two: instead of inventing its own encryption wrapper, it reuses standard TLS directly. Client and server complete a genuine TLS handshake, and the resulting traffic looks nearly identical to ordinary HTTPS; connections that fail authentication get handed off to a real website by the server, making the protocol harder to fingerprint. This keeps the implementation extremely thin — the protocol body is just a password hash plus a target address, with almost no extra overhead, putting performance close to the theoretical ceiling of raw TLS. The catch is on the server side: you need a domain and a valid certificate, which makes setup more involved than SS. On the client side, make sure the sni field matches the server's certificate — a mismatch throws a TLS handshake error. For client-side users, Trojan is a solid, low-overhead, well-behaved option.

VLESS: A Next-Gen Framework Built by Subtraction

VLESS is a streamlined successor to VMess, born out of the same ecosystem. It strips out everything considered redundant in VMess: no built-in encryption (that's delegated to an outer TLS layer), no timestamp check, and a header trimmed to the bare minimum. With the protocol body this light, security depends entirely on the transport layer it's paired with — common combos are VLESS + TLS + Vision flow control, or VLESS + REALITY (a handshake scheme that borrows a real website's TLS fingerprint instead of needing its own certificate). The trade-off is clear: zero encryption in the protocol body in exchange for minimal packaging overhead, with modern transport making up the security difference. Note that VLESS's various flow-control and transport combinations evolve fairly quickly, and older cores often don't recognize the newer fields — which is why it's the most core-version-sensitive of the six, covered in more detail in CL-05 and CL-06.

Hysteria2: Built for Bad Networks

Hysteria2 runs on top of QUIC, meaning the entire protocol travels over UDP, with encryption handled by TLS 1.3. What sets it apart is an aggressive built-in congestion control scheme: traditional TCP backs off sharply when it sees packet loss, which tanks real throughput on lossy links well below the available bandwidth; Hysteria2 instead keeps sending at the configured bandwidth and fights packet loss with redundancy and fast retransmission. The engineering takeaway is straightforward — on long cross-border links, during peak-hour congestion, or on weak Wi-Fi/cellular signal (high-latency, high-loss conditions), Hysteria2's throughput often beats TCP-based protocols by a wide margin; on an already-smooth network the advantage is negligible, and its aggressive sending can even crowd out other devices on the same segment. Its hard requirement is a working UDP path: some ISPs and public Wi-Fi networks throttle or block UDP outright, which breaks Hysteria2 completely — always keep a TCP-based protocol as a fallback.

TUIC: The Lightweight Take on QUIC

TUIC also runs on QUIC, but takes a "standardized, lightweight" route: it leans on QUIC's native multiplexing and 0-RTT handshake rather than rewriting congestion control from scratch like Hysteria2, instead offering standard algorithms like BBR and Cubic to choose from. 0-RTT means reconnecting to a previously visited server barely costs a round trip, which is especially useful on phones that hop between networks constantly; QUIC's native UDP forwarding also makes it a more natural fit for gaming and voice traffic. Its weak point is ecosystem maturity: TUIC is relatively young, with less server-side deployment and provider support than the other five, and it shares Hysteria2's dependency on a working UDP path. Think of it as the "gentler QUIC option" — if you want QUIC's low-latency benefits without Hysteria2's aggressive sending behavior, TUIC is the answer.

CL-03Speed and Throughput: Three Factors Behind the Experience

When someone says a node "feels fast," that's actually three separate things: connection setup speed (how long before a new site starts loading), steady-state throughput (how fast downloads and video streams run), and concurrency (whether dozens of simultaneous requests on a page start blocking each other). Each is driven by different factors, so they need to be evaluated separately to draw any reliable conclusion.

Connection Setup: Handshake Round Trips Add Up

The time to establish a proxy connection is basically "handshake round trips × link latency." SS has no handshake at all — the first packet sent is the connection, making it the theoretical fastest. Trojan, VLESS + TLS, and VMess + TLS all need a full TLS handshake, which under TLS 1.3 is one round trip; VMess layered over WebSocket adds an HTTP Upgrade round trip on top, making it the slowest connection setup among the TCP-based protocols. The QUIC camp — Hysteria2 and TUIC — merges the transport handshake and the TLS handshake into a single round trip, and can achieve "data on the first packet" on repeat connections via 0-RTT. The higher the link latency, the more this matters: on a low-latency, nearby link the handshake gap is barely noticeable, while on a high-latency, distant link it gets multiplied several times over, showing up as the difference in that blank-screen wait before a new page loads.

Steady-State Throughput: Congestion Control and Encryption Cost

Once a connection is established, the bottleneck for sustained large-volume transfers (downloads, HD video) shifts to congestion control and encryption overhead. On a clean link, the six protocols' steady-state throughput is nearly identical — all can get close to the link's bandwidth cap — so encryption cost becomes the deciding factor: SS and Trojan have the thinnest wrapping, while VMess's per-packet header overhead puts it at a slight disadvantage on small-packet-heavy pages (image-dense sites, for example). The moment a link starts dropping packets consistently, the picture flips: TCP-based protocols (SS/VMess/Trojan/VLESS over TCP) are bound by the kernel TCP stack's backoff behavior, so throughput drops sharply as packet loss climbs; Hysteria2's custom congestion control keeps throughput close to the configured bandwidth even under the same packet loss, and TUIC running BBR also clearly outperforms traditional TCP. This is the technical reason QUIC-based protocols "just feel better" during peak-hour congestion.

Concurrency and Head-of-Line Blocking

A modern web page routinely fires off dozens of requests at once. Multiplexing over a single TCP connection (like VMess's mux) suffers from head-of-line blocking: one dropped packet stalls every request sharing that connection. QUIC solves this natively at the transport layer — each stream retransmits independently, with no cross-contamination — which is why Hysteria2 and TUIC feel noticeably smoother on pages that fire off a lot of small concurrent requests. TCP-based protocols work around this by skipping multiplexing entirely and opening a separate connection per request, which, paired with connection pooling, can still deliver decent concurrency — at the cost of more frequent connection setup overhead. When benchmarking, it helps to separate test types: use a large file download for throughput, an image-heavy page for concurrency, and a fresh domain for connection setup time. A single latency number (ping) only reflects link distance and doesn't map to any of the three — more on this misconception in CL-08.

CL-04Resource Use and Mobile Battery Drain

Desktop users rarely think about how much CPU a proxy core eats; phone users think about battery life every single day. This chapter breaks "resource use" down into three factors — encryption compute, protocol stack layer, and radio wake-ups — and closes with practical advice for mobile.

Encryption Compute: Hardware Acceleration Is the Dividing Line

Symmetric encryption is a fixed cost of proxying traffic. Phones and computers from the last decade or so almost universally have AES instructions built into the CPU, so encrypting/decrypting with a suite like aes-128-gcm barely registers as CPU load; older devices without hardware acceleration (some low-end routers, older streaming boxes) should use chacha20-ietf-poly1305 instead — it's optimized for software-only implementations and can be several times faster than software AES at the same security level. At the protocol level, SS and Trojan apply a single encryption layer and carry the lowest compute cost; VMess's built-in encryption stacked with an outer TLS layer means double encryption, making it the most CPU-expensive combination per unit of traffic among the six; VLESS's "no built-in encryption" design exists specifically to eliminate that redundant layer. When running the mihomo core on a router, this is exactly what decides whether the device can max out its bandwidth or not.

QUIC's Userspace Cost

The TCP stack runs inside the operating system kernel and has been optimized over decades; QUIC today is mostly implemented in userspace, which generally means higher CPU usage — and slightly higher memory usage — than TCP-based protocols at the same traffic level. This difference is a non-issue on desktop, but on a phone, sustained heavy traffic over Hysteria2/TUIC will run noticeably warmer and drain more battery than SS/Trojan. The takeaway isn't "don't use QUIC on mobile" — it's "spend QUIC's benefits where they matter": on a bad network, the experience gain far outweighs the battery cost; on a good network, there's no need to pay the battery tax for anti-packet-loss capability you're not using. In clients that support smart-switching policy groups, mix QUIC and TCP nodes in the same group and let rules pick as needed.

Radio Wake-Ups and Heartbeats: The Real Battery Hog on Mobile

The real source of battery drain on a phone usually isn't compute — it's the cellular/Wi-Fi radio being repeatedly woken up from sleep. If a long-lived connection sends frequent heartbeats, even tiny ones of a few dozen bytes, it keeps the radio from entering deep sleep. This is where QUIC-based protocols have an often-overlooked edge: connection migration. When a phone switches between Wi-Fi and cellular, a TCP connection has to tear down and rebuild (triggering a full handshake and retransmitting in-flight traffic), while a QUIC connection can migrate in place to the new network without a restart — the constant reconnects during a commute are a real source of both battery drain and stutter. Practical advice: on mobile, favor mihomo-based clients like Clash Plus or FlClash on Android, and toggle TUN mode on only when you need it (running the virtual network adapter full-time adds ongoing background overhead — see the TUN mode guide in Technical Notes for how it works); also avoid setting the auto speed-test interval too aggressively — a health check every few hundred milliseconds is a textbook battery killer on a phone.

CL-05Core Families: How Original Clash, Meta, and mihomo Relate

The "core" is the engine underneath the client's interface that actually handles the traffic. Every Clash-based client on the market shares the same config syntax, but the engines fall into distinct generations — without understanding how they relate, there's no way to explain why the same subscription works fine on client A but throws an error on client B.

The Three-Generation Lineage

The original Clash core laid the entire foundation of this ecosystem: YAML config, proxy groups (policy groups), and rule-based traffic splitting. It supported mainly SS, VMess, Trojan, Socks5, and HTTP. The original author later maintained a closed-source Premium build that added advanced features like TUN mode and rule providers. After the original repo stopped receiving updates, the community fork Clash Meta picked up the torch, massively expanding protocol support while staying actively developed; the Meta project later renamed itself mihomo — so today, "Clash Meta core" and "mihomo" refer to the same project's same main line. Once you understand this lineage, the selection rule boils down to one sentence: config syntax is backward-compatible, protocol support only ever grows, and for any new protocol, look for mihomo.

Feature Comparison

How Clients Map to Cores

A client is just a graphical shell around a core — choosing a client really means choosing a core. The active clients listed in our Download Center — Clash Plus (top pick across all platforms), Clash Verge Rev, FlClash, Clash Nyanpasu, and Clash Meta for Android — are all built on the mihomo core, so all six protocols work. The clients in the archive section, Clash for Windows and ClashX Meta, are no longer maintained; their original/Premium cores can't load VLESS, Hysteria2, or TUIC nodes, and a subscription containing those protocols will throw an "unsupported proxy type" error or fail to load entirely. That's exactly why "Clash for Windows alternative" is such a common search — the old software isn't broken, the protocol ecosystem simply moved forward. For a feature-by-feature breakdown of each client's interface and capabilities, see the client comparison; server and router users can grab the mihomo core binary directly from the Download Center and run it without a GUI.

CL-06Subscription Formats and Config Compatibility

Beyond protocols and cores, subscription format is the third common trip-up point. The same batch of nodes can be packaged into several different distribution formats, and whether a given client can actually load a subscription — and how much detail survives the load — follows clear, predictable rules.

Three Common Distribution Formats

Subscriptions in circulation generally fall into three categories. The first is a full Clash YAML config: a complete YAML file containing proxies, proxy-groups, and rules, which Clash-based clients can import directly with the most information preserved — this is the default format used in our tutorial. The second is a Base64-encoded link bundle: individual node URIs (ss://, vmess://, trojan://, etc.) encoded and concatenated line by line. It's the most universally compatible format, but it only carries connection parameters — no routing rules or policy groups — so it needs converting before importing into a Clash-based client. The third is formats from other ecosystems, like sing-box JSON, which Clash-based clients don't support natively and require a conversion service to translate. To figure out which type you're holding, just open the subscription link in a browser and look at what comes back: YAML has clean, indented structure, while Base64 is one long block of letters and numbers with no spaces.

Field Compatibility: Generational Differences Within the Same YAML

Clash YAML syntax is broadly backward-compatible, but fields added by mihomo will be rejected or silently ignored on the original core. Typical examples: type values for newer protocols (vless, hysteria2, tuic), the rule-providers block, the sniffer section, GEOSITE-style rules, and VLESS-related transport fields like flow and reality-opts. The reverse direction is fine — an old config written for the original core loads without issue on mihomo. To identify a node's protocol type, just check its type field; here's a minimal example for reference (all values are placeholders, shown only to illustrate structure):

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

  - name: "Example-Shadowsocks"
    type: ss
    server: ss.example.com
    port: 8388
    cipher: aes-128-gcm
    password: "your-password"

Subscription Conversion and Managing Multiple Configs

When a format doesn't match what your client expects, that's where "Clash subscription conversion" comes in: a conversion service reads the raw subscription, outputs it in the target format, and can apply a remote template during conversion to fill in policy groups and routing rules. Two things to watch for when using a conversion service: your subscription link passes through a third party, so if privacy is a concern, ask your subscription provider for a native Clash YAML format instead; and the conversion template determines the final policy group structure — an overly complex template slows down config loading, so a simpler template is usually the better choice. For naming, updating, and switching between multiple subscriptions, see the Profile basics article in Technical Notes; for exactly where a given client's import button lives or how to set the update interval, head to the platform-specific section of the tutorial — not repeated here.

CL-07Picks by Use Case

The conclusions from the previous six chapters come together here. The right order to make a decision: confirm your core first (a mihomo-based client covers all protocols), then pick a protocol based on your main use case, and finally keep a different-transport protocol as a fallback. Below are reference picks for five common scenarios.

Desktop Work and Everyday Browsing

Link quality is usually stable here, so connection setup speed and concurrency matter more than peak throughput. Go with Trojan or VLESS + TLS: single-layer encryption, thin overhead, stable behavior, and a one-round-trip TLS 1.3 handshake that makes new pages snap open. SS works just as well here and runs with zero friction on any client. For policy groups, put several nodes on the same protocol into a url-test auto-select group with a health check interval of a few minutes — desktop doesn't mind the background traffic, but checking too often still puts needless load on the node side. Pick a client following the order in the Download Center's Windows section; Clash Plus is the top recommendation.

Mobile Commuting and Battery Priority

On mobile, the two things that matter most are network switching and battery life. Pick either TUIC or Trojan: TUIC's 0-RTT and connection migration are practically built for the moment you step out of an elevator and the connection would otherwise drop and reconnect; Trojan wins on lowest energy cost per unit of traffic. VMess is the least efficient choice on a phone — double encryption drains battery, and its timestamp check is easily tripped by a phone's clock drift, causing handshake failures. Pair your protocol choice with the battery checklist in CL-04; Android users can grab Clash Plus or FlClash from the Download Center's Android section, and iOS users can follow the App Store link in the iOS section to install Clash Plus.

Weak Networks, High Packet Loss, and Peak-Hour Congestion

The signs: latency all over the place, download speed far below your bandwidth, video buffering constantly. This is where Hysteria2 shines — its custom congestion control's throughput advantage on lossy links was already covered in CL-03, and the real-world difference is often the gap between "can't watch anything in HD" and "streams fine." Two things worth confirming first: that your network's UDP path isn't throttled (a common issue on public Wi-Fi and some cellular networks), and that the bandwidth parameter configured on the node side actually matches the real line — an inflated bandwidth value causes excessive wasted retransmissions and can end up slower. Always keep a fallback ready: put a Trojan or SS node in the same policy group and switch to it manually or via rule when UDP isn't getting through.

Gaming, Real-Time Voice, and Low-Latency Needs

Real-time apps care most about UDP forwarding and latency jitter. TUIC is the top pick: QUIC's native UDP forwarding path is clean, and its standard congestion control doesn't trade smoothness for throughput the way Hysteria2 does — better suited to a steady stream of small packets. Hysteria2 is the second choice. TCP-based protocols need extra wrapping to forward UDP traffic, adding a notch of latency and jitter — best avoided here if possible. Also watch your routing rules: game traffic should be pinned to a fixed node by process or destination subnet rather than left to an auto speed-test group — a connection migration mid speed-test switch is invisible during a download but means a dropped connection mid-match. Rule syntax examples are in the rules section of the tutorial.

Older Hardware, Routers, and Always-On Services

Devices like a Raspberry Pi, a travel router, or a NAS are constrained by CPU and memory. Go with SS (pair with the chacha20 suite if there's no hardware AES) or Trojan, and avoid QUIC's userspace overhead and VMess's double encryption. Run the core directly as the mihomo binary, picking the build for your device's architecture (AMD64/ARM64/ARMv7/MIPS) with no GUI involved. For always-on services, also watch config complexity: thousands of rules and dozens of policy groups can noticeably drive up memory use — a router should run a trimmed-down rule set, leaving complex routing logic to desktop.

CL-08Common Pitfalls and Where to Go Next

This last chapter covers the most frequently asked misconceptions and points to where to dig deeper on the site. What these all have in common: the conclusion sounds reasonable on the surface, but the reasoning behind it is missing a step.

Pitfall 1: Newer Always Means Better

A protocol being "newer" means it solves a specific problem in a specific scenario, not that it's a strict upgrade across the board. VLESS is a clear simplification over VMess, but Hysteria2 and TUIC aren't a generational leap over Trojan — on a clean network, all three feel nearly identical, and QUIC-based protocols actually pay two extra costs: userspace CPU and UDP availability. The right approach is matching your scenario to CL-07's picks, not chasing whatever's newest by default. The flip side applies too: writing off a protocol as "outdated" doesn't always hold up — SS is the oldest of the six, yet it's still the best option for low-spec devices, no contest.

Pitfall 2: Latency Numbers Equal Real-World Experience

The latency test in a client (typically the time to complete an HTTP request to a test URL) only tells you how fast a round trip to that node is right now — it says nothing about throughput, packet loss, or concurrency. A node with a great-looking latency number can still have tiny bandwidth, and a node with heavy packet loss during peak hours can still test well at 2am. Test a node across multiple times of day, and follow up with an actual download test before trusting it for heavy use; if every node is timing out, don't rush to switch subscriptions — follow the diagnostic order in Technical Notes, starting with your own local network, since that's where most problems actually live.

Pitfall 3: More Layers of Encryption Means More Security

VMess's double encryption over TLS is a historical leftover, not a security benefit — the inner encryption layer adds no real confidentiality once the outer TLS layer is already established, and only burns CPU. VLESS strips out its own encryption entirely and trusts TLS 1.3 completely, with no loss in security strength — this is exactly the modern consensus in protocol design: one reliable layer of encryption beats several redundant ones stacked together. Judge security by cipher suite and implementation quality, not by counting layers.

Pitfall 4: Blindly Chasing the Newest Core, or Refusing to Ever Update

Both extremes come with a cost. Sticking with a core that's stopped receiving updates has already been covered in CL-05 — new protocols simply won't work. On the other end, a major core version update occasionally comes with config field changes, so jumping to update the moment a new version drops can mean your old config needs small fixes. The safer approach: keep your client on an actively maintained version line (the Download Center's recommended order reflects this), test a major update against a backup config first, and only then switch it into daily use. See the note linked at the end of CL-06 for how to back up configs and manage multiple profiles.

Where to Go From Here

Now that you've read through this guide, here's where to go next depending on what you need: grab an installer from the Download Center by platform; for first-time setup, follow the three-step path in the tutorial; if you're torn between clients, check the side-by-side client comparison; for deep dives on TUN mode, DNS leaks, macOS permissions, and similar topics, search by tag in Technical Notes. This page gets revised periodically as the protocol ecosystem evolves — check the catalog card at the top of the page for the current version.