Protocol Guide: Proxy Protocols and Core Technical Reference

AProtocol Overview: Origins and Design Trade-offs of Six Protocols

The six protocols common in the Clash ecosystem can be arranged along a timeline: Shadowsocks came first, VMess and Trojan represent a middle generation, and VLESS, Hysteria2, and TUIC are the newer directions. Each generation responds to problems exposed by the one before it, so there's no protocol that "wins" outright—only different sets of trade-offs.

Shadowsocks: Minimalist Symmetric Encryption

Shadowsocks (often abbreviated SS) is designed around minimalism: client and server share a single password and encryption method, and data is sent directly after AEAD symmetric encryption—no handshake negotiation, no extra authentication round trips. That gives two clear wins: simple implementation and fast connection setup. The trade-off is that the protocol itself has no disguise layer, so extensibility relies on the SIP003 plugin system (obfs, v2ray-plugin, etc.) to fill the gap. On encryption, aes-128-gcm and chacha20-ietf-poly1305 are the two mainstream choices—the former is faster on x86 devices with hardware acceleration, the latter tends to perform better on the ARM chips found in most phones.

VMess and Trojan: Two Opposite Approaches

VMess comes from the V2Ray project and takes a "feature-rich" approach: dynamic authentication based on a user UUID, freely combinable transport options (TCP, WebSocket, gRPC, and more), and metadata that carries a fair amount of control information. The trade-off is a heavier protocol header, and authentication depends on the client and server clocks being roughly in sync—a large time gap causes the connection to fail outright, which is the first thing to check when a VMess node misbehaves. Trojan takes the opposite approach: it doesn't invent its own encryption at all, just riding on standard TLS so traffic looks identical to visiting an ordinary HTTPS site. The cost falls on the server side—deployment needs a domain and a valid certificate—while users barely notice, and the config has the fewest fields of the bunch.

VLESS, Hysteria2, and TUIC: Trimming Down and Changing Lanes

VLESS is essentially VMess with the fat trimmed: it drops the protocol's own encryption and time-based auth, handing security entirely to the outer TLS layer (plus extensions like REALITY), which slims the header down and cuts forwarding overhead well below VMess. Hysteria2 and TUIC change lanes entirely: both ditch TCP in favor of QUIC, which runs over UDP. Hysteria2's standout feature is an aggressive congestion-control strategy that keeps throughput up even on high-packet-loss, high-latency connections; TUIC focuses on handshake efficiency, using QUIC's 0-RTT to get connections established almost instantly, with native support for UDP forwarding. In the Clash ecosystem, all three are supported only by mihomo-family cores—more on that in Section E.

BTransport Layer Differences: The TCP vs. QUIC Divide

The real dividing line among these six protocols isn't encryption—it's transport: SS, VMess, Trojan, and VLESS are all TCP-based, while Hysteria2 and TUIC run on QUIC. Understanding this split matters more than memorizing each protocol's fields, because it directly shapes how a protocol behaves across different network conditions.

TCP Family: Mature, Conservative, Path-Friendly

The biggest advantage of TCP-based protocols is being "path-friendly": TCP is the most mature transport protocol on the internet, and routers, firewalls, and carrier QoS devices along the way all handle it well, so entire classes of traffic being throttled or dropped is rare. Once Trojan or VLESS is layered with TLS, the traffic looks identical to ordinary web browsing, giving it the best compatibility. There are two costs. First, more handshake rounds—TCP's three-way handshake plus a TLS handshake means at least two or three round trips before a connection is even established, and the farther the node, the more noticeable that initial wait. Second, head-of-line blocking—TCP guarantees strictly ordered bytes, so one lost packet stalls everything behind it, even unrelated requests. On lossy connections, this turns the occasional dropped packet into a noticeable stall.

QUIC Family: Fewer Handshakes, Loss-Resistant, But at the Mercy of UDP Treatment

QUIC rebuilds reliable transport on top of UDP and folds the TLS 1.3 handshake into connection setup, so a new connection typically needs just one round trip—and with 0-RTT on reconnect, data can even ride along with the very first packet. QUIC streams are independent of each other, so a single lost packet only affects the stream it belongs to, not the rest—this structural difference is exactly why it feels better on poor networks. QUIC also supports connection migration: when a device switches from Wi-Fi to cellular, the connection carries over instead of being rebuilt, which matters a lot on mobile. Its weak spot comes from the same place as its strength: some carriers and enterprise networks throttle or deprioritize UDP traffic, and on those paths a QUIC-based protocol can actually end up slower than a plain TLS-over-TCP connection. So claims like "Hysteria2 is always faster than Trojan" don't hold up—speed depends on how the path treats UDP.

Where Multiplexing Happens

TCP-based protocols can use mux settings to multiplex several requests over one connection, cutting down on handshakes—but multiplexing also amplifies the reach of head-of-line blocking, so it's generally only worth enabling on high-latency links, and only as needed. QUIC-based protocols multiplex natively, with no extra configuration and no cross-request blocking—a difference baked into the transport design itself, not something tuning parameters can fix.

CConnection Speed and Resource Usage: A Qualitative Comparison

There are no universal numbers worth quoting for protocol performance—the gap between the same protocol on different lines and devices dwarfs the gap between protocols. So this section sticks to qualitative comparisons: relative ranking assuming "all else equal," plus the structural differences in resource usage.

Connection Setup Speed

The key variable behind "how long until a new site loads" is the number of handshake round trips. Ranked from fewest to most: TUIC and Hysteria2 (QUIC, one round trip, 0-RTT on reconnect) are fastest; SS comes next (no protocol handshake, just TCP's three-way handshake); Trojan and VLESS need both a TCP and a TLS handshake; VMess is typically the slowest to connect in this group due to its header and auth overhead. Note this ranking only affects the time-to-first-byte on new connections—it has no bearing on sustained throughput once a connection is up. Browsing, which constantly opens short-lived connections, is the most sensitive to setup speed; streaming and large downloads, which use long-lived connections, barely notice it.

Throughput and CPU Overhead

The bottleneck for sustained throughput is usually the line itself, not the protocol—protocol differences show up mainly in CPU usage. Encryption is the biggest factor: x86 devices generally have AES hardware acceleration, so aes-128-gcm barely touches the CPU; on most ARM-based mobile chips, chacha20-ietf-poly1305 is actually more efficient. Since VLESS doesn't encrypt anything itself (only the outer TLS layer does), it has the lowest CPU usage at a given throughput, which is why it's favored for high-traffic forwarding. QUIC-based protocols currently handle encryption mostly in user space, without the mature OS-level optimizations TCP enjoys, so CPU usage runs noticeably higher when pushing a link to its limit—a non-issue on desktops, but worth watching on low-power devices.

Memory and Low-End Devices

Memory usage is driven mainly by the core and rule data, with very little variation between protocols. The real memory hogs are GEO databases and large rule sets—on routers and older phones with limited RAM, trimming down rule files does far more for memory usage than switching protocols. If your device is a router with very little RAM, favor a simple protocol like SS or Trojan and use a trimmed-down config with the mihomo core, rather than chasing QUIC's newer features on underpowered hardware. In scenarios with many concurrent connections (heavy multi-tab browsing, P2P), each TCP connection carries its own system overhead—enabling mux or switching to a QUIC-based protocol with native multiplexing cuts the total connection count, which is another angle for choosing a protocol based on resource use.

DMobile Battery Impact: It's Not Just the Protocol

Battery drain on phones often gets blamed on the protocol, but in reality it's the sum of three layers: the protocol's keep-alive behavior, the client's background policy, and how the OS schedules the VPN service. Switching protocols alone, without touching client behavior, usually doesn't save much battery.

Radio Wake-ups: The Real Culprit Behind Mobile Battery Drain

On cellular networks, a phone's baseband chip drops into a low-power state when there's no data flowing, and any packet at all wakes it up and holds it in a high-power window for a while. So what drains the battery isn't how much data moves—it's how often the radio gets woken up. Protocol-level keep-alive pings, the client's periodic latency tests, and policy groups' auto speed tests all trigger these periodic wake-ups. QUIC's connection migration actually pays off here: switching between Wi-Fi and cellular just continues the existing connection, skipping the handshake and wake-up chain that comes with rebuilding it; TCP-based protocols drop every connection on a network switch and rebuild from scratch, and on a commute with frequent switching that gap adds up.

Settings Worth Adjusting on the Client

Client settings usually matter more than protocol choice. First, the auto speed-test interval on policy groups: url-test groups periodically ping every node in the group by default, and setting the interval too short means the phone wakes up and opens a batch of connections every few minutes—on mobile, widen the interval, or switch rarely-used groups to manual selection. Second, TUN mode vs. system proxy: TUN mode takes over all traffic and has a longer processing path, so idle power draw runs a bit higher than system-proxy mode, which only handles browser traffic; if you don't need to capture all traffic, system-proxy mode saves more battery on mobile. Third, rule count: every new connection has to be matched against the rule set, and bigger rule sets mean more matching overhead—mobile configs should avoid piling on rule sets you don't actually use.

iOS's Special Constraints

On iOS, proxy clients run inside the Network Extension framework, and the system enforces a fairly tight memory limit on that process—exceed it and the extension gets killed outright, which shows up as the proxy disconnecting for no obvious reason. That's why iOS clients need to keep rule sets and GEO data lean, and lighter-weight protocols are the safer bet there too. Clash Plus, distributed through the App Store on iOS, is built with this memory constraint in mind and is the top pick on that platform—find it on the iOS section of the download page. On Android, keep an eye on the battery optimization allowlist: when the system freezes the client, the VPN service restarting triggers its own round of reconnect drain—adding the app to the allowlist helps battery life more than switching protocols does.

ECore Families: How the Original, Premium, Meta, and mihomo Relate

The word "Clash" means different things depending on context: sometimes it refers to the core (the command-line program handling traffic in the background), sometimes to the client (the app with a graphical interface). The client is just a shell around the core—protocol support, rule capabilities, and TUN implementation are all determined by the core. Understanding how the core families relate is the key to understanding why a node works in Client A but throws an error in Client B.

The Evolution of Three Core Generations

The original Clash core is where it all started, establishing the three-part config structure of proxies, proxy-groups, and rules, with support for basic protocols like SS, VMess, and Trojan; its upstream repository has since been archived and no longer receives updates. Premium was a closed-source enhanced edition maintained by the original author, adding TUN mode and rule providers; it stopped evolving alongside the original. Clash Meta is a community fork that continued development on top of the original, later renamed mihomo—the two names refer to the same lineage, and mihomo is now the official name. While staying compatible with the original config structure, it added support for newer protocols like VLESS, Hysteria2, and TUIC, and expanded capabilities like rule-sets, domain sniffing, and more robust GEO data management. It's currently the only actively maintained mainline core.

How Clients Map to Cores

Choosing a client is really choosing a core. Among the clients listed on the download page: Clash Plus, Clash Verge Rev, FlClash, Clash Nyanpasu, Clash Meta for Android, and ClashX Meta are all built on mihomo-family cores and support all six protocols in full; Clash for Windows runs on the original/Premium core and is no longer maintained—it will flat-out reject VLESS, Hysteria2, and TUIC nodes as unsupported, and is only worth sticking with if you have a legacy config you don't want to touch. If your subscription already includes any QUIC-based nodes, you need a mihomo-family client—there's no way around it. For a detailed breakdown of interface, platform coverage, and update cadence across clients, see the client comparison page; the short answer is Clash Plus for cross-platform use, and Clash Verge Rev as the runner-up on desktop.

FConfig and Subscription Format Compatibility

A subscription is really just "a config file the server hands you," so compatibility issues split into two layers: whether the core recognizes the fields in the config itself, and whether the client recognizes the format the subscription link delivers. Each layer has its own pitfalls, and mixing them up when troubleshooting just wastes time.

The Config Field Layer: One Structure, Two Field Sets

Every Clash-family core shares the same YAML structure: proxies defines nodes, proxy-groups defines policy groups, and rules defines routing rules. The difference is in the field sets—the original core only recognizes fields for basic protocols, while mihomo extends the same structure with new protocol types and extra parameters. The snippet below shows how old-style and new-style nodes differ within the same config:

proxies:
  - name: "Node-SS"
    type: ss
    server: example.com
    port: 8388
    cipher: aes-128-gcm
    password: "your-password"
  - name: "Node-HY2"
    type: hysteria2
    server: example.com
    port: 443
    password: "your-password"
    sni: example.com

Hand this config to the original core, and hitting type: hysteria2 triggers an "unsupported proxy type" error that rejects loading the entire config—it doesn't just skip that one node, the whole config fails. This explains a common pattern: a subscription works fine in a newer client but shows "zero nodes" in an older one. Going the other way, a config with only basic protocols runs just fine on mihomo—compatibility only flows one direction: newer cores understand older configs, but older cores don't understand newer fields.

The Delivery Layer: Format and User-Agent

A subscription link commonly returns one of three formats: Clash YAML (usable directly), a Base64-encoded list of share links (needs client-side conversion), or JSON from another ecosystem like sing-box (not directly supported by Clash-family clients). Many subscription servers decide which format to serve based on the User-Agent in the request header—the same link might return YAML to a Clash-family client but Base64 when opened in a browser. That creates a subtle problem: if the server doesn't recognize a particular client's UA, it may serve the wrong format or refuse to respond at all, which shows up as "the link works in another client but fails to import here." If that happens, try setting a custom UA string in the client's subscription settings, or check with the subscription provider about which clients they officially support.

A step-by-step checklist for concrete issues like subscription import errors and nodes dropping to zero after an update is covered separately in the technical note "Six Reasons Clash Subscriptions Fail to Load or Parse, and How to Check Each One"—we won't repeat it here.

GPicking a Protocol by Use Case

The conclusions from earlier sections come together here as actionable recommendations. One more reminder: line quality matters more than protocol choice, and every recommendation below assumes "the same server offers multiple protocol entry points"—only under that assumption does picking a protocol by scenario actually make sense.

Let Policy Groups Handle It, Not Manual Switching

The way to act on protocol choice isn't switching nodes by hand every time—it's baking the decision into policy groups. A common setup: create separate groups for different purposes—browsing routed through a url-test group (auto-picks the lowest-latency node), downloads routed through a manual select group (pinned to a node with good throughput)—then use rules to route different domains to the right group. That way the protocol decision only needs to be made once, and rules handle the rest automatically. Mixing protocols within a group is fine—url-test's auto testing will compare their real-world performance for you; just keep in mind that auto testing mainly reflects connection latency, so throughput differences still need to be confirmed by hand.

Two Situations Not Worth Overthinking

First: if your subscription only offers one or two protocols, there's no real choice to make—just use what's there. Don't chase a protocol switch just because "the guide says QUIC is faster"; the benefit is uncertain while the hassle is guaranteed. Second: on a wired desktop connection with a good line, the experience gap between all six protocols shrinks to the point of being unnoticeable—your time is better spent organizing rules and policy groups (see the routing section of the tutorial) than switching protocols back and forth. The real payoff from these recommendations shows up at the edges: weak networks, mobile, low-end devices, and UDP-restricted connections are the four situations where following the table above actually makes a noticeable difference.

HCommon Pitfalls and Troubleshooting Clues

This final section rounds up the most common misconceptions about protocols and cores, along with a "symptom → diagnosis → where to go" index. Only the diagnostic clues are covered here—full troubleshooting steps live in their respective dedicated articles.

Three Widely-Repeated Myths

Myth one: "newer protocol means faster, period." Newer protocols solve problems specific to certain conditions (weak networks, handshake latency, UDP forwarding)—they don't speed everything up universally. The line's own bandwidth, congestion, and physical distance set the ceiling on your experience; the protocol only affects how close you get to that ceiling. Myth two: "stronger encryption means safer, so pick whichever protocol has the most complex encryption." All six protocols use modern AEAD or TLS 1.3 at the cryptographic level, and all are strong enough—the differences lie in features and overhead, not "security tier." Choosing a heavier protocol for imagined extra security is a pure loss. Myth three: "the number in the latency test reflects real-world experience." The latency test built into most clients times a single HTTP request, which reflects connection setup and round-trip time—not throughput, packet loss, or how UDP gets treated. Two nodes can show identical latency numbers and still feel very different to use. These numbers are useful for comparing nodes on the same protocol, but comparing across protocols needs more caution.

Diagnosing by Symptom

Node shows "unsupported proxy type" or nodes drop to zero after loading a subscription: suspect the core doesn't support that protocol type—check Section E to confirm your client's core family, and switch to a mihomo-family client if needed (available for every platform on the download page). Only VMess nodes fail while everything else works: check whether your device's system clock has drifted too far from the correct time. QUIC-based nodes (Hysteria2/TUIC) noticeably slow down or drop on a specific network, then work fine after switching networks: this matches UDP being throttled—switch to a TCP-based protocol on that network. Every single node times out: this is usually about your local network, the subscription server, or client state, not protocol choice—work through it near-to-far using the order in "All Clash Nodes Timing Out? Here's How to Fix It". Proxy shows connected but pages won't load: this usually gets stuck at the system proxy, DNS, or rule-matching step—check off each item in "Clash Connected But No Internet Access".

Where to Go From Here

Terminology questions (policy groups, TUN, GEO data, REALITY, and more) are organized by category in the glossary; scattered questions about installation, config, and everyday use are grouped into four categories—basics, setup, usage tips, and Troubleshooting—in the FAQ; platform-specific installation details (macOS network extension permissions, Windows TUN mode) are covered step by step in the Platform Guide series of technical notes. This page gets revised as the core and protocol ecosystem evolves, so treat the current version as the source of truth.