R-01Client, Core, Protocol: Three Layers You Need to Separate First
The Client Is Just the Shell
Clash Plus, Clash Verge Rev, FlClash, Clash Nyanpasu — these names all refer to graphical clients. A client's job is to show the node list, switch proxy modes, and toggle the system proxy; it never actually establishes a proxy connection itself. Differences between clients only affect the user experience, not how the connection actually behaves. Import the same subscription into two different clients and you should get the same node list, the same latency test results, and the same routing outcomes; if you don't, the issue is almost always in your settings, not a difference between the clients.
The Core Is the Engine
The component that actually talks to the remote server is the core: a background process that starts alongside the client. Nearly every actively maintained client on our download page bundles the mihomo core (formerly Clash Meta). As long as the core version is close enough across clients, the same node configuration will behave the same way — same connection behavior, same protocol support, same rule matching results. So "choosing a protocol" really means "choosing from what the core supports," not something you pick in the client's UI. To check which core your client is running, open Settings or the About page — the core name and version are listed there. If you see mihomo or Clash Meta, protocol support follows the R-08 section below.
The Protocol Is the Encapsulation Rule
SS, VMess, Trojan, VLESS, Hysteria2, and TUIC labeled on a node are protocol types. A protocol defines three things: how data is packaged, how it's encrypted, and whether it runs over TCP or UDP. When you import a subscription, the client parses each node into a proxy entry in the core's config, and the core handshakes with the server and forwards traffic according to that protocol. Your protocol choice only affects the client-to-node leg of the connection; what happens between the node and the destination site is entirely up to the server side — the client has no say in it.
That clears up how this page relates to the tutorials: quickstart.html is the follow-along path to getting connected, and this page is the reference manual you check when you need to understand something. If you hit a config field you don't recognize, check the glossary first, then come back to the relevant section here.
R-02How Proxy Protocols Evolved
General-Purpose Proxies: SOCKS5 and HTTP
The earliest proxy protocols were general-purpose. SOCKS5 just forwards traffic — no encryption, no content verification — and is typically used locally or on a LAN; HTTP proxies work the same way and mainly serve browsers. Both are still present in Clash-based configs today, but as inbound entry points — where local apps connect to the client's listening port — not as outbound connections to a remote server. The mixed-port setting is a combined SOCKS5/HTTP inbound port, and allow-lan controls whether devices on your LAN can connect.
# Local inbound settings (for apps connecting to the client, not node config)
mixed-port: 7890
allow-lan: false
mode: ruleThree Shifts in Dedicated Protocol Design
Protocols built specifically for remote proxy servers have gone through roughly three design shifts. First, Shadowsocks established the "lightweight encrypted stream" approach: encrypt the payload only, skip any extra structure, and run on just four parameters. Second, VMess went "features first": timestamp verification, multiple transport layers, and built-in encryption were all baked in — more capable, but heavier. Third, the path split in two: Trojan and VLESS hand encryption off to TLS so traffic looks like ordinary HTTPS from the outside; Hysteria2 and TUIC moved to QUIC over UDP, trading for better throughput on bad networks and connections that survive network switches.
Six Protocols, All Still in Use
The six protocols you'll see most often in subscriptions today are still SS, VMess, Trojan, VLESS, Hysteria2, and TUIC. None of them wins on every metric: low overhead tends to come with more obvious traffic patterns, strong disguise depends on a domain and certificate, and aggressive speed depends on a UDP-friendly network. These protocols are trade-offs, not upgrades over each other — which is exactly why a proper comparison is worth having.
R-03Shadowsocks (SS): A Lightweight Encrypted Stream
Origins and Design Goals
SS launched around 2012 with an extremely restrained design goal: add a layer of stream encryption on top of the SOCKS5 forwarding model so transmitted data becomes unreadable, and nothing more. A single SS node needs just four pieces of information: server address, port, password, and cipher. A working SS client can be implemented in a few hundred lines of code, which is a big reason it spread quickly and ended up supported by nearly every core and client.
AEAD Encryption and Current Usage
Early SS used stream ciphers (like aes-256-cfb), which turned out to have weaknesses that made active probing possible, so the community moved to AEAD (Authenticated Encryption with Associated Data). Three ciphers are common today: aes-128-gcm, aes-256-gcm, and chacha20-ietf-poly1305. Most desktop CPUs have AES hardware acceleration, so both AES-GCM options run at basically zero cost; most phone SoCs lack that instruction set, so chacha20-ietf-poly1305 runs faster and drains less battery on mobile. SS also supports UDP forwarding (the udp field in config), but it requires the server side to have it enabled too.
proxies:
- name: "Example-SS-Node"
type: ss
server: example.com
port: 8388
cipher: chacha20-ietf-poly1305
password: "your-password"
udp: trueStrengths and Limits
SS's advantages are all engineering advantages: it has the lowest protocol overhead of the six, its implementation is mature, every core supports it, and it's the best performer for mobile battery life. Its limits are just as clear: the protocol has no built-in disguise layer, so its traffic pattern is fairly consistent; it only handles encryption, not identity or certificates, so the server's authenticity is entirely up to whoever deployed it. As an everyday general-purpose protocol, SS remains a solid default, and it's still the go-to choice for older devices and routers.
R-04VMess: A Feature-First, All-in-One Design
Design Background
VMess is the native protocol of the V2Ray project, and its design philosophy is the opposite of SS: authentication, timestamp checking, encryption, and transport disguise are all built into the protocol itself. Every request carries a timestamp, and requests too far off from the server's clock get rejected outright — replay protection built right into the protocol layer. A UUID serves as the user identifier, so a single server can host multiple independent users and track them separately.
Transport Layers and Structural Overhead
VMess supports multiple transport layers, including TCP, WebSocket, and gRPC. The WebSocket variant can wrap proxy traffic inside the structure of an ordinary web service, which pairs well with CDN relaying — a common setup. The gRPC variant borrows HTTP/2 multiplexing. The price of all this capability is complexity: a long handshake process, the largest header overhead of the six protocols, and a harder implementation. VMess also has its own built-in encryption, so stacking TLS on top creates double encryption — that noticeably raises CPU usage for limited security benefit.
Where It Stands Today
VMess is still common in existing subscriptions, and mihomo fully supports all of its transport variants. Newly deployed servers tend to favor the lighter-weight VLESS instead, with VMess gradually settling into legacy configs. There's no need to actively avoid it on the client side — if a node connects and passes speed tests, protocol age isn't a reason to switch. If you're editing configs by hand, watch the alterId field: newer servers and cores have it fixed at 0, and non-zero values from older tutorials no longer apply.
proxies:
- name: "Example-VMess-Node"
type: vmess
server: example.com
port: 443
uuid: 00000000-0000-0000-0000-000000000000
alterId: 0
cipher: auto
network: ws
ws-opts:
path: /rayR-05Trojan and VLESS: The TLS Disguise Route
Shared Approach: Skip Designing Your Own Encryption
Trojan and VLESS follow the same path: the protocol layer doesn't implement encryption itself — it borrows TLS, the same security layer HTTPS runs on. The server holds a real domain and a valid certificate, and the connection between client and server is a standard TLS connection: handshake, encryption, and certificate validation all rely on mature, battle-tested implementations, so from the outside it looks basically identical to visiting an HTTPS site. mihomo also supports a client-fingerprint field (e.g. chrome) that uses uTLS to mimic a specific browser's TLS fingerprint, making the handshake look even more like a real browser's.
Trojan: Minimal by Design
Trojan is designed to be almost "protocol-less": once the TLS handshake completes, the client sends a hash of the password within the session to authenticate, and everything after that is forwarded as-is. The less structure a protocol adds on top, the closer it looks to normal HTTPS, and the lower the overhead. Configuration only needs three things — domain, port, password — and the sni field usually matches the domain.
VLESS: A Lighter VMess
VLESS is essentially a stripped-down rewrite of VMess: it drops the protocol-layer encryption and timestamp, keeping only the UUID for identity, and hands encryption entirely off to the outer TLS layer. Its structure is much lighter than VMess, with header overhead in the same range as Trojan; paired with transport optimizations like XTLS, it avoids an extra data copy between the core and the TLS library, giving better throughput on high-bandwidth connections. One thing worth stressing: VLESS must be used with TLS — a plaintext VLESS node serves no purpose and shouldn't show up in a normal subscription.
Shared Requirement: Domain and Certificate
The TLS route depends on a real domain and a valid certificate, which is why it's mostly used by self-hosted or more professionally managed servers. There's really only one thing to watch on the client side: the node's sni (or servername) field must match the certificate's domain — a mismatch means the handshake fails outright. Nodes imported through a subscription already have this field filled in correctly; it only matters if you're adding or editing nodes by hand.
proxies:
- name: "Example-Trojan-Node"
type: trojan
server: example.com
port: 443
password: "your-password"
sni: example.com
udp: true
- name: "Example-VLESS-Node"
type: vless
server: example.com
port: 443
uuid: 00000000-0000-0000-0000-000000000000
tls: true
servername: example.com
client-fingerprint: chromeR-06Hysteria2 and TUIC: The UDP Route Over QUIC
What QUIC Changes
QUIC is a modern transport protocol built on top of UDP, and it's the foundation of HTTP/3. It rolls encryption, congestion control, and multiplexing into the transport layer itself: the handshake usually completes in a single round trip, with 0-RTT session resumption supported; connections are tracked by a connection ID rather than a source-address four-tuple, so a session can keep going when you switch from Wi-Fi to cellular instead of reconnecting from scratch. Hysteria2 and TUIC both build on QUIC, but they make different trade-offs.
Hysteria2: Congestion Control That Pushes Bandwidth Aggressively
Hysteria2's core is a custom congestion control algorithm called Brutal: instead of probing for available bandwidth the traditional way, it sends at a preset target bandwidth regardless. On lines with heavy packet loss and high latency, this approach can push throughput noticeably higher than any TCP-based protocol — TCP-based protocols back off exponentially on packet loss, and Brutal simply doesn't. The trade-off is just as clear: it sends aggressively, which places real bandwidth demands on the server, and the up and down values in the config need to closely match your actual line speed — set them too high or too low and real-world speed suffers. The protocol also supports port hopping (cycling through a port range) to dodge single-port rate limiting, configured via the ports field in mihomo.
TUIC: Multiplexing and Low Latency
TUIC is designed for low latency and low overhead: it multiplexes multiple TCP-style connections over a single QUIC session, so opening a new connection in-app doesn't require a fresh handshake; it natively supports UDP relaying, which directly benefits latency-sensitive traffic like gaming and voice calls. Its congestion control follows the standard QUIC algorithm family, behaving more conservatively than Hysteria2 — less intrusive on the connection, and friendlier to servers without much bandwidth to spare.
Where the UDP Route Falls Short
Both protocols depend on UDP actually getting through. Some networks throttle UDP heavily or block it outright, in which case these protocols simply stop working or slow to a crawl — there's no client-side workaround, and you'll need to fall back to a TCP-based protocol. Resource use is another factor: QUIC does encryption, retransmission, and congestion control entirely in user space, so CPU usage runs higher than plain TCP protocols, and on mobile you may notice more heat and battery drain during long, heavy downloads.
proxies:
- name: "Example-Hysteria2-Node"
type: hysteria2
server: example.com
port: 443
password: "your-password"
sni: example.com
up: 50
down: 200
- name: "Example-TUIC-Node"
type: tuic
server: example.com
port: 443
uuid: 00000000-0000-0000-0000-000000000000
password: "your-password"
alpn: [h3]R-07Side by Side: Speed, Resources, and Battery
Connection Setup
TCP-based protocols (SS, VMess, Trojan, VLESS) complete a TCP handshake first, plus a TLS handshake on top for the ones that use TLS — usually one to three round trips to get connected. QUIC-based protocols combine the transport and encryption handshake into one, typically a single round trip, with 0-RTT possible on session resumption. Day-to-day browsing won't show much difference; for scenarios with lots of short-lived connections — refreshing a feed, an app hammering an API — QUIC-based protocols have a real edge.
Throughput and Overhead
Header overhead runs roughly, from smallest to largest: SS < Trojan ≈ VLESS < VMess; QUIC-based protocols aren't small on headers either, but multiplexing spreads the handshake cost out, so actual throughput comes down more to congestion control strategy. On the same line: with stable, low packet loss, SS, Trojan, and VLESS perform pretty close to each other; under heavy packet loss, Hysteria2 leads on throughput, TUIC comes second, and TCP-based protocols fall off noticeably.
CPU and Memory
On desktop (Windows, macOS, Linux), all six protocols use a negligible amount of CPU, so performance shouldn't factor into your choice there. Mobile is different: the efficiency gap between AES and ChaCha20 on a phone SoC's small cores is real, and QUIC's user-space retransmission and congestion control keep the CPU busier. Memory use doesn't vary much by protocol either — core memory usage mostly comes down to rule count and active connection count, not protocol type.
Mobile Battery Life
Relative battery drain for the same amount of traffic runs roughly, from most efficient to least: SS (chacha20-ietf-poly1305) < Trojan ≈ VLESS < VMess < TUIC < Hysteria2. For mostly-idle background usage like push notifications and messaging, the differences barely register; for sustained video streaming or large downloads, the gap becomes noticeable. Clash Plus on iOS and the various Android clients all run the same mihomo core, so these results hold across platforms; for how to get set up on iOS specifically, see our technical note (How to Use Clash on iPhone).
| Protocol | Transport | Encryption | Header Overhead | High Packet Loss | Mobile Battery Life | Best For |
|---|---|---|---|---|---|---|
| SS | TCP / UDP | AEAD stream cipher | Lowest | Average | Most efficient | Everyday use |
| VMess | TCP / WebSocket, etc. | Built into protocol | Highest | Average | Moderate | Legacy configs |
| Trojan | TCP + TLS | TLS | Low | Average | Moderate | TLS disguise |
| VLESS | TCP + TLS | TLS | Low | Average | Moderate | TLS disguise |
| Hysteria2 | UDP(QUIC) | TLS | Medium | Best | Higher | Lossy connections |
| TUIC | UDP(QUIC) | TLS | Medium | Good | Higher | Low-latency use |
How to Test Speed Properly
Before choosing a protocol, test under consistent conditions: same time window, same destination, same device. A client's built-in speed test measures latency, which reflects handshake and round-trip cost; test actual downloads to check throughput. Single-connection downloads are more affected by protocol overhead, while multi-connection downloads are more affected by congestion control — checking both numbers is more reliable than looking at latency alone.
R-08Core Family Tree: Clash, Clash Meta, and mihomo
Where the Original Clash Stands Today
The original Clash core stopped receiving updates in 2023 and its repository is archived. It supports early protocols like SS, VMess, and Trojan, but doesn't recognize VLESS, Hysteria2, or TUIC. There was also a closed-source enhanced edition, Clash Premium, with TUN mode and scripting support — also discontinued. If you're still on a discontinued client like Clash for Windows or ClashX Meta, you're running a core from this era or an early fork of it — existing nodes still connect, but you won't get new protocols or features, and any newer-protocol nodes in your subscription will simply be skipped.
From Meta to mihomo: What Carried Over and What's New
Clash Meta was the community's actively developed fork of the original, renamed mihomo in late 2023. It fully inherits the original's YAML config format, adds support for VLESS, Hysteria2, and TUIC, and brings enhanced TUN mode, rule providers (rule-providers), and an extended external controller. TUN mode captures system-wide traffic through a virtual network adapter — how it works and how to turn it on is covered in a separate technical note (What Is Clash TUN Mode). The actively maintained clients on our download page — Clash Plus, Clash Verge Rev, FlClash, and Clash Nyanpasu — all bundle the mihomo core.
Config Compatibility
Compatibility only goes one way: mihomo can run old original-Clash configs directly; the reverse doesn't work — a config with newer-protocol nodes or newer fields (like rule-providers) will fail to parse on the original core. Subscription conversion tools usually offer both a "Clash" and a "Clash Meta" output option: pick the Meta output if you're on a mihomo-based client. Pick the legacy format by mistake, and newer-protocol nodes get silently dropped during conversion — which shows up as "the subscription clearly has this node, but it's missing after import."
| Core | Maintenance Status | Protocol Support | Config Format |
|---|---|---|---|
| Clash (original) | Discontinued | Early protocols like SS, VMess, Trojan | Clash YAML |
| mihomo (formerly Clash Meta) | Actively maintained | Adds VLESS, Hysteria2, TUIC, etc. | Backward-compatible, with extensions |
R-09Subscription Formats and Picking a Protocol by Use Case
Three Subscription Format Types
A subscription link typically returns content in one of three forms. The first is a Base64 node list: one ss:// or vmess:// share link per line — the most universally compatible format, but it doesn't carry Clash's policy groups or rule structure, so the client has to organize everything itself after import. The second is Clash YAML: a full config with proxies, proxy-groups, and rules sections — ready to use on import, and the preferred format for mihomo-based clients. The third is output from an online subscription converter: it turns a Base64 list into Clash YAML, giving older subscriptions a full structure too, but the conversion service sees your nodes in plaintext, so pick one you trust. For details on getting and importing a subscription, see our technical note (How to Import a Clash Subscription Link).
| Format | Content Structure | Advantages | Things to Watch |
|---|---|---|---|
| Base64 List | One share link per line | Most universally compatible | No policy groups or rules |
| Clash YAML | proxies / proxy-groups / rules | Ready to use on import | Tied to core generation |
| Converted Output | YAML from an online converter | Works with older subscriptions too | Converter sees plaintext nodes |
Picking a Protocol by Use Case
- Everyday browsing and video: SS or Trojan/VLESS. Low overhead and battery-friendly, works well on both desktop and mobile.
- High-packet-loss connections: Hysteria2. Its throughput advantage is most obvious on transcontinental links or during peak-hour congestion, as long as your network doesn't restrict UDP.
- Gaming and voice chat: TUIC or Hysteria2. UDP relaying keeps latency low — just make sure UDP forwarding is enabled in your client.
- Switching networks often: QUIC-based protocols. Connections survive network switches, meaning noticeably fewer drops during your commute.
- Older devices and routers: SS. Lowest CPU usage, the most mature implementation, and the most stable for long-running setups.
Three Common Misconceptions
"Newer protocols are always faster" isn't true: speed depends on line quality and congestion control, not release date — on a stable connection, SS and the newest protocols barely differ. "More layers of encryption means more secure" isn't true either: stacking TLS on top of VMess's built-in encryption just adds CPU overhead, since security is determined by the outermost layer. "Switching clients changes how a protocol performs" doesn't hold up either: protocol behavior is identical under the same core — clients only affect the user experience. For a proper client-to-client comparison, see our technical note (Comparing the Major Clash Clients).
Wrapping Up: A Four-Step Way to Choose
- Confirm your client's core is mihomo (every actively maintained client on the download page qualifies).
- Import your subscription and browse the node list by protocol type.
- Run a speed test for each candidate protocol on the network you actually use — check both latency and throughput.
- Set whichever performed best as your policy group default, and keep the rest as backups.
That covers protocols. For everything else — importing a subscription, choosing a mode, enabling the system proxy, verifying the connection — head back to the setup guide and follow the steps; to grab a client, go to the download page; and if you run into an unfamiliar term, check the glossary.