Protocol & Core Technical Reference

AProtocol Evolution: Three Generations of Design Thinking

These six protocols weren't created at the same time — each was designed to solve the most pressing problem of its era. Grouped by core approach, they fall into three generations. Once you understand this order, the comparisons that follow won't need memorizing — each generation's strengths and weaknesses are a direct consequence of its design goals.

First generation: minimal wrapping

Shadowsocks is the flagship example. The design goal was "lightweight": wrap a TCP stream directly with symmetric encryption, keep the header as short as possible, with no handshake negotiation, no session management, no extra metadata. Server and client only need to agree on four parameters (address, port, cipher, password) to communicate. The trade-off is that the protocol itself carries no identity system and no transport-layer disguise — every later requirement has to be bolted on externally.

Second generation: in-protocol metadata

Vmess is the flagship example. It introduces structured metadata inside the protocol — a user ID (UUID), timestamp validation, command fields — and abstracts the "carrier" into a swappable transport layer: the same Vmess node can run over plain TCP, WebSocket, HTTP/2, or gRPC, with TLS layered on top as needed. Flexibility jumps sharply, but so does configuration complexity — a Vmess node has several times more tunable parameters than a Shadowsocks one, which makes troubleshooting harder too.

Third generation: borrowed shells and swapped foundations

The third generation splits into two branches. One is the "borrowed shell" approach: Trojan and VLESS stop inventing their own encryption wrapper and instead place data directly inside a standard TLS session, so proxy traffic looks identical to ordinary HTTPS traffic from the outside, while also dropping a redundant layer of encryption. The other is "swap the foundation": Hysteria2 and TUIC abandon TCP and rebuild the transport layer on QUIC (UDP), focused on throughput and handshake speed over high-latency, high-loss links. The two branches solve different problems — neither replaces the other.

In one line: there's no do-everything protocol, only different trade-offs for different goals. The first generation wins on simplicity and low resource use, the second on flexibility, the borrowed-shell branch of the third on clean traffic fingerprints, and the swapped-foundation branch on poor-network performance. Choosing a protocol just means matching your use case to one of these goals.

BThe Six Protocols, One by One

This section covers each protocol's design points, key parameters, and where it fits best. Field names follow the Clash-family config file (YAML) convention; all sample values are placeholders and won't connect to anything real.

Shadowsocks (SS)

The leanest of the six. Current implementations universally use AEAD cipher suites (commonly aes-128-gcm, aes-256-gcm, chacha20-ietf-poly1305), providing both confidentiality and integrity checks in one pass. There are only four parameters — server address, port, cipher, password — leaving almost no room for misconfiguration. CPU and memory overhead are the lowest of the six protocols, which is friendly to older devices and embedded environments. The trade-off is equally clear: traffic is encrypted but carries no protocol disguise, and there's no built-in multiplexing — every connection is established independently. Sample config:

proxies:
  - name: "ss-example"
    type: ss
    server: node.example.com
    port: 8388
    cipher: aes-256-gcm
    password: "your-password"

Vmess

The core protocol of the V2Ray ecosystem. Authentication is UUID-based, and early versions required client-server clock drift to stay within roughly 90 seconds — an out-of-sync clock is a classic reason a Vmess node fails to connect. alterId is a legacy field; under current AEAD authentication it should be set to 0. Vmess's real value lies in its transport combinations: the network field can be tcp / ws / h2 / grpc, with tls: true layered on top. WebSocket + TLS is the most widely used combination, since it can sit behind a standard web server and share port 443. More parameters mean more failure points: any mismatch between client and server on path (ws-opts.path), Host header, or SNI will break the handshake.

Trojan

A direct expression of the "borrowed shell" approach. Trojan invents no encryption of its own — the whole session is a genuine TLS connection, the server holds a valid certificate, and authentication is just a password hash. Traffic that fails authentication is silently redirected (fallback) to a real website, so from the outside, a Trojan server behaves identically to an ordinary HTTPS site. Client-side parameters are minimal: address, port, password, SNI. Watch the skip-cert-verify field — it skips certificate validation and should only be used with self-signed certs in test environments.

VLESS

Think of it as "Vmess with the inner encryption layer removed": since TLS already handles the outer layer, the protocol itself skips redundant encryption, keeping only UUID authentication and a minimal header — saving a round of CPU-heavy encrypt/decrypt work. VLESS must be paired with TLS-based transport; it cannot run bare. Its flow field (e.g. xtls-rprx-vision) further optimizes the redundant-encryption issue in TLS-over-TLS scenarios, making it one of today's mainstream low-overhead options. Key limitation: VLESS is not supported by the classic Clash core — only mihomo (Clash Meta) family cores can parse it; see Section E.

Hysteria2

The flagship of the "swap the foundation" branch. Built on QUIC, authentication needs only a password, with a configuration footprint close to Shadowsocks. Its core difference is congestion control: instead of relying on traditional TCP backoff on packet loss, it keeps sending at a configured or measured bandwidth rate, sustaining far higher real-world throughput than TCP-based protocols on high-loss, high-latency links. The trade-off is more aggressive bandwidth usage, and since some networks throttle or drop UDP traffic, performance can degrade noticeably on those networks. Sample config:

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

TUIC

Also built on QUIC, but aimed at "low latency" rather than "high throughput." TUIC uses QUIC's 0-RTT capability, so repeat connections can carry a request in the very first packet, pushing handshake latency close to zero; it offers native UDP forwarding (udp-relay-mode: native), well suited to latency-jitter-sensitive workloads like gaming and real-time voice. Like Hysteria2, it depends on a working UDP path and is affected the same way on UDP-restricted networks. Support is likewise limited to mihomo-family cores.

CConnection Speed & Throughput Compared

"Which protocol is faster" really needs to be split into three separate metrics: handshake latency (how many round trips to establish a connection), sustained throughput (how much of the bandwidth you can actually use), and poor-network degradation (how much performance drops under packet loss). The rankings differ across all three.

Handshake latency

TCP-based protocols (SS, Vmess, Trojan, VLESS) need at least one TCP handshake to open a connection; layering TLS 1.3 on top adds another round trip, for roughly 2 RTT total. QUIC-based protocols (Hysteria2, TUIC) merge the transport and encryption handshakes into one, taking about 1 RTT on first connect, and TUIC can hit 0-RTT on resumed sessions. For workloads with many short connections, like web browsing, this handshake gap shows up directly in time-to-first-byte.

Sustained throughput

On a good link, throughput differences across all six protocols are minor — the bottleneck is usually node bandwidth, not the protocol itself. Two protocol-side factors are noticeable: encryption overhead — on devices with hardware AES support, aes-*-gcm is nearly free, and VLESS's vision flow control saves even more by skipping redundant encryption; and head-of-line blocking — when multiplexing over TCP, one lost packet stalls every stream on that connection, whereas QUIC streams are independent and don't have this problem.

Poor-network degradation

High-packet-loss environments are where QUIC-based protocols shine. TCP's congestion control reads packet loss as congestion and throttles aggressively, which is especially visible on long-haul, high-latency links; Hysteria2's bandwidth-driven approach can maintain several times the effective throughput at the same loss rate. Conversely, on networks that throttle UDP, TCP-based protocols are actually more stable.

One more note: the "latency" number in a client's node list is the total time for a single HTTP request to a speed-test URL — it reflects the current state of the link, not the protocol's quality. Latency fluctuations on the same node at different times have little to do with protocol type. For a troubleshooting approach to unusual latency readings, see the blog post "Troubleshooting Order for Clash Node Connection Timeouts."

DResource Usage & Battery on Mobile

On desktop, resource differences across the six protocols are barely noticeable, but on phones, the choice of protocol and run mode shows up directly in battery stats. Ranked by impact: run mode > keep-alive strategy > encryption overhead.

CPU and encryption overhead

Modern phone SoCs generally include AES hardware instructions, so encrypt/decrypt cost for aes-128-gcm / aes-256-gcm is minimal; chacha20-ietf-poly1305 is designed for older devices without AES instructions and is actually slightly slower on newer hardware. VLESS, having dropped its inner encryption layer, has the lowest per-byte CPU cost of the six. QUIC-based protocol stacks run in user space, and under heavy load (long HD video sessions, large file transfers) CPU usage runs noticeably higher than TCP-based protocols — overhead that translates into heat and battery drain on phones.

Connection keep-alive and background behavior

On mobile networks, long-lived connections need periodic heartbeats to keep NAT mappings alive, and each heartbeat briefly wakes the baseband. TCP-based protocols rely on the system's own stack for keep-alive and tend to be fairly restrained; QUIC connection keep-alive is handled at the application layer, and heartbeat intervals vary a lot between implementations. For everyday background use dominated by messaging traffic, "quiet" protocols like SS / Trojan generally deliver better battery life; Hysteria2 / TUIC are better suited to heavy foreground use.

Impact of run mode

Run mode has a bigger impact than protocol choice: system proxy mode only touches traffic from apps configured to use the proxy; TUN mode intercepts all system traffic, routing every packet through the client process, which raises both CPU and memory footprint. iOS has an additional constraint — the network extension process has a strict memory ceiling, and an oversized rule set or subscription can trigger extension restarts. On mobile, if you don't need to intercept specific apps, system proxy mode is the better default.

ECore Family: Classic, Premium, and mihomo

"Clash" actually refers to a family of cores, and the core baked into each client determines exactly which protocols it can recognize. Sorting out which core you're dealing with before picking a client will save you from a lot of "nodes vanished after importing a subscription" problems.

How the three branches relate

The classic Clash core is where it all started: written in Go, open source, it established the YAML config format, policy groups, and rule-based routing model, supporting SS, Vmess, Trojan, and other mainstream protocols of its time — the repository is now archived and no longer updated. Premium was a closed-source build released by the original author on top of the classic core, mainly adding TUN mode and stronger rule capabilities, and has also stopped evolving. Clash Meta is the community fork that picked up maintenance around when the classic core was archived, later renamed mihomo — it's the only branch that's still actively maintained, and all new protocol support lands here first.

Feature comparison

Which clients use which core

A client is just the GUI shell wrapped around a core — the core determines protocol support, the shell determines usability. Currently active clients — Clash Plus, Clash Verge Rev, FlClash, Clash Nyanpasu, Clash Meta for Android — are all built on the mihomo core, so all six protocols work; discontinued clients like Clash for Windows and ClashX Meta are stuck on an old core or old version and aren't recommended for subscriptions that include newer protocols. See the head-to-head comparison for a detailed breakdown of client trade-offs, and grab installers from the client download page. For a full breakdown of mihomo vs. the classic core, read the blog post "mihomo Core vs. Classic Clash Core: A Full Comparison."

FConfig & Subscription Format Compatibility

All the protocol and core decisions eventually come down to one question: will the subscription you have load fully in the client you're using. This section covers common subscription formats and what matters when migrating across cores.

Three subscription formats

First, Clash YAML subscriptions: a complete config file with three main sections — proxies, proxy-groups, and rules — that Clash-family clients can import directly; this is the recommended format. Second, share-link collections: Base64-encoded text made up of ss://, vmess://, and similar URIs, aimed at broad client compatibility, which Clash-family clients translate into YAML either natively or via a conversion service on import. Third, multi-format endpoints: the same subscription URL returns different formats depending on the requester's User-Agent, more common on the provider side. Whichever format you have, the import steps are covered in step one of the setup guide.

What matters when migrating cores

Moving from an old core to mihomo, almost every field carries over as-is — no YAML rewriting needed. The reverse direction doesn't hold: as soon as a config contains a type the old core doesn't recognize (such as vless, hysteria2, or tuic), the old core throws a parse error and the entire config fails to load, which looks like "all nodes disappeared after a subscription update." This is one of the most common reasons people migrate off Clash for Windows to a currently maintained client. If a subscription references an external node list via proxy-providers, the same rule applies:

proxy-providers:
  main:
    type: http
    url: "https://example.com/subscribe-url"
    interval: 86400
    path: ./providers/main.yaml
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

Common load failure causes

If the subscription fetches fine but nodes misbehave, check three things in order: first, whether your client's core supports every protocol type in the subscription (open the subscription in a text editor and search for type: fields); second, whether the YAML indentation has been broken by editing — YAML is indentation-sensitive, and a single extra space causes a parse failure; third, whether the node names referenced in proxy-groups exactly match the name values under proxies, including spaces and emoji. For subscription fetch failures themselves (timeouts, 403 errors, etc.), see the troubleshooting section of the FAQ.

GProtocol Picks by Use Case

The conclusions from earlier sections come together here as an actionable selection guide. It assumes the same endpoint in your subscription exposes multiple protocol entry points — true for most providers; if your subscription only offers a single protocol, this section can serve as talking points for your provider or a plan switch.

Everyday browsing and office work

The load pattern here is lots of short connections with small payloads. Trojan or VLESS are balanced picks: acceptable handshake cost, clean traffic fingerprint, low CPU use. SS is equally sufficient, and has the fewest parameters, making it the hardest to misconfigure. The felt difference between protocols in this scenario is close to zero — don't overthink it.

HD streaming and large file transfers

The load pattern here is long-lived connections with sustained high throughput. On a good link any protocol can max out the bandwidth; on a long-haul, high-latency link or during peak-hour packet loss, Hysteria2 has the biggest edge, typically delivering significantly higher effective throughput than TCP-based protocols on the same link. Just confirm your network isn't throttling UDP first, otherwise fall back to Trojan / VLESS.

Mobile network commuting

Cellular signal fluctuates and towers hand off frequently, so connection re-establishment is routine. This is exactly where QUIC's connection migration and low handshake cost pay off most: TUIC's 0-RTT makes reconnecting after a drop practically unnoticeable. If battery life is the priority, follow the guidance in Section D — use SS / Trojan during standby periods and switch during heavy-use periods.

Gaming and real-time meetings

The metric that matters here is latency jitter, not bandwidth, and traffic is mostly UDP. TUIC's native UDP forwarding is the first choice, with Hysteria2 as a close second. TCP-based protocols need extra wrapping to carry UDP, which generally means worse jitter. On the client side, pair this with TUN mode to make sure the game's UDP traffic gets intercepted.

Servers and routers running 24/7

In headless environments running the mihomo core directly, prioritize stability: SS or Trojan's long-term reliability and low resource footprint suit round-the-clock uptime best; core installers are in the core section of the download page. On ARM devices like router firmware, make sure to pick the build matching your architecture.

HCommon Misconceptions & Troubleshooting Entry Points

Misconception 1: newer means faster

A protocol determines behavior under specific conditions, not an absolute speed ranking. On a good link, throughput across all six protocols is nearly identical; Hysteria2 won't outrun SS on a clean link, and it can actually be slower on a UDP-throttled network. Figure out where the bottleneck actually is (node bandwidth, local network, or a mismatch between protocol and network) before switching protocols.

Misconception 2: a lower latency number means a better experience

The latency shown in a node list measures a single HTTP round trip — it has no direct relationship to sustained throughput or packet loss rate. A node showing 50ms but suffering heavy peak-hour packet loss can perform far worse in practice than a node showing 180ms on a clean link. Judge node quality by real-world loading speed and stability, not the speed-test number alone.

Misconception 3: global mode is more stable

Global mode simply routes all traffic through the proxy — it doesn't fix any connection-layer issue, and it can actually push traffic that should go direct through an unnecessary detour, amplifying the impact of any node failure. Rule mode combined with sensible routing rules is the standard setup; global mode is best used as a temporary diagnostic to check whether a rule simply isn't matching.

Misconception 4: more encryption layers means more security

VLESS dropping its inner encryption layer doesn't weaken security — the outer TLS 1.3 layer already provides full confidentiality and integrity protection, and a second layer of symmetric encryption on top just adds CPU cost without adding protection. Security depends on whether certificate validation is enabled and whether the password is strong enough, not on how many encryption layers are stacked.

Troubleshooting entry points

• Frequent issues like subscription update failures, launch-at-startup, and mode switching: the FAQ organizes standard fixes by category.
• All nodes timing out, or some nodes timing out: work through the fixed checklist in the blog post "Troubleshooting Order for Node Connection Timeouts."
• Can't make sense of an error in the client logs: check "How to Read Clash Runtime Logs" for what each error means.
• Definitions for terms used on this page (AEAD, SNI, RTT, TUN, etc.): look them up in the relevant category of the glossary.