Clash Protocol and Core Selection Reference

IProtocol Lineage: From SOCKS5 to the QUIC Generation

A proxy protocol is the contract between client and server — how data gets packaged, how it's encrypted, how credentials are verified, and whether it rides on TCP or UDP. Clash-family clients are rule executors and protocol implementers: they don't invent protocols, they implement whatever the community has already published and hand traffic off to the rule engine. So picking a protocol really means picking a packaging format both your server and client support — no matter how capable the client is, it can't use a protocol the server doesn't offer.

It also helps to separate the two directions a protocol works in. Inbound is how local apps reach the client: browsers and system proxies connect over HTTP or SOCKS5 ports — these two never show up in a subscription, they're just the front door. Outbound is what this volume is actually about: how the client packages traffic as SS, VLESS, and so on before sending it to the remote server. When people say "which protocol should I use," they always mean the outbound side.

Lineage and origins

SOCKS5 and HTTP proxying are the oldest general-purpose forms — pure relaying, no built-in encryption — and they're still used today as Clash's local inbound protocols. Around 2012, Shadowsocks brought symmetric encryption to proxying: encrypt the traffic, send it to the remote end, let the server decrypt and forward, keeping the protocol itself minimal enough that it's been implemented in over a dozen languages. Around 2016, the V2Ray project shipped its native protocol VMess, taking a different path: full encryption, timestamp-based auth, swappable transport layers — pushing configurability much further. Around 2018, Trojan introduced a disguise-first philosophy: make a proxy connection look, from the outside, exactly like a normal HTTPS visit, with auth reduced to a single password. Around 2020, VLESS arrived as a leaner VMess, handing encryption duties back to TLS for a lighter header; around the same time, QUIC-based Hysteria and TUIC appeared, trading TCP for UDP to squeeze more throughput out of poor connections — Hysteria2 is a later revision of the original Hysteria. These six threads make up most of what you'll see in the proxies section of a Clash config today.

Quick reference

The table below lines up all six protocols for a first impression — details follow in later chapters.

Three axes are all you need from this table: packaging and disguise — does the protocol mimic other traffic, and what shape does it take on the wire; overhead and performance — how many round trips to handshake, how much CPU encryption costs, how throughput holds up under packet loss; and ecosystem support — is it widely offered by servers, implemented in the core, and covered by subscription formats. Every section below expands on one of these three.

How this relates to the rule engine

Keep two layers straight: the protocol decides how a single connection is sent, the rules decide which connection uses which protocol. Clash's rule engine sits above the protocol layer — a single config can hold SS, VLESS, and Hysteria2 nodes side by side, with rules routing traffic by domain, IP range, or process name into different proxy groups, each bound to specific nodes. Choosing a protocol and setting up traffic splitting are two separate jobs; this volume covers the former, and the full walkthrough for the latter is in Clash Rule-Based Traffic Splitting in Practice.

IIShadowsocks: Where Lightweight Encryption Started

Shadowsocks (SS) is the longest-supported proxy protocol in Clash and still the most common one you'll see in subscriptions. Its design goal fits in one sentence: encrypt and forward TCP and UDP traffic to a remote server with as few handshakes and as simple a format as possible.

Design goals and packet format

An SS session skips the handshake entirely: the client encrypts the target address, port, and payload together and sends them straight out; the server decrypts with the same pre-shared key and reads the target address before forwarding. The key is derived from the user's password via a key derivation function, and each connection derives its own subkey from the master key to prevent replay. No handshake means SS has the lowest first-byte latency among TCP-based protocols; the simple format means a full implementation fits in a few hundred lines of code, which is why it's been ported to everything from router firmware to browser extensions.

SS also natively defines UDP relay: the client encrypts UDP datagrams and hands them to the server to send and receive on its behalf — games, voice calls, and QUIC handshakes all depend on this. Setting udp: true in a Clash config turns this on; if a node is meant for gaming, also confirm the provider doesn't restrict UDP relay on their end.

SS also has a plugin ecosystem (simple-obfs, v2ray-plugin, and others) that wraps an extra layer of obfuscation or WebSocket transport around it; mihomo supports some of these via the plugin and plugin-opts fields. Plugins are an add-on layer — they don't change the underlying SS format.

Ciphers: the move to AEAD

Early SS used stream ciphers like aes-256-cfb and chacha20-ietf, which encrypt but don't verify integrity — later shown to be vulnerable to active probing, prompting the community to move wholesale to AEAD (authenticated encryption). The three ciphers in common use today are aes-128-gcm, aes-256-gcm, and chacha20-ietf-poly1305: the first two run at near-zero overhead on desktop and server CPUs with AES-NI; the third doesn't rely on hardware instructions and actually runs faster on phone and low-end router ARM chips. The community later proposed newer ciphers like 2022-blake3-aes-128-gcm, already implemented in both shadowsocks-rust and mihomo, using BLAKE3 for key derivation and stronger replay protection — worth considering for new deployments.

Where it fits and where it falls short

SS's simplicity is also its limitation: the protocol has no disguise layer — encrypted traffic looks like random-length, high-entropy data, nothing like a normal HTTPS TLS record; it also doesn't define multi-user management on the server side, so one port maps to one key. SS is a solid "good enough" general-purpose option — widely implemented, low overhead, low maintenance. If you need traffic disguise, look at Trojan (Chapter 4) or VLESS (Chapter 3) instead.

Client config essentials

In a Clash config, an SS node only needs four required fields — server, port, cipher, password — plus udp to control UDP relay. The cipher must match the server exactly; a mismatched cipher is the number one reason an SS node won't connect, so check this line first, then the password and port. If your provider gives you an ss:// share link, importing it into the client will auto-expand these fields — no manual entry needed.

proxies:
  - name: "ss-aead"
    type: ss
    server: example.com
    port: 8388
    cipher: aes-128-gcm
    password: "your-password"
    udp: true

IIIVMess vs VLESS: Two Generations of the V2Ray Lineage

VMess and VLESS both come from the V2Ray project (which later split into forks like V2Fly and Xray): VMess is the project's original flagship protocol, VLESS is the streamlined rethink that followed. Understanding the trade-off between these two generations gets at a core fault line in proxy protocol design — which layer should own the encryption?

VMess: encrypt everything

VMess's approach is for the protocol itself to handle all security: the request header carries a user UUID, timestamp, and checksum, and the entire session is encrypted with AES-128-GCM or ChaCha20-Poly1305 without relying on an outer TLS layer. Timestamp-based auth requires the client and server clocks to stay within about two minutes of each other — this is the first thing to check when troubleshooting VMess: a wrong device timezone or disabled network time sync will both trigger auth failures. Early VMess used an alterId parameter to derive extra keys, later shown to weaken security; newer implementations have deprecated it, so a non-zero alterId in a config is a sign of outdated practice.

VMess's UUID also doubles as a user identifier, letting the server do multi-user splitting and traffic accounting — which is why vmess:// share links carry the most fields of any protocol: a Base64-encoded JSON blob packing in address, port, UUID, transport, TLS toggle, and disguise domain.

VLESS: handing encryption back to TLS

The name says it all: VLESS strips out VMess's encryption layer, keeping only a UUID and a handful of control fields in the header, and leaves all encryption to the outer TLS. The payoff is twofold: a shorter header means no second round of CPU-side encryption, and paired with XTLS Vision flow control (flow: xtls-rprx-vision), TLS records can be forwarded straight through, saving another encrypt/decrypt copy. The catch is that VLESS requires TLS — a bare VLESS connection offers no confidentiality at all, and cores like mihomo only accept VLESS nodes running over TLS.

The Xray fork later introduced REALITY on top of VLESS: instead of issuing its own certificate, it borrows a real website's TLS handshake, skipping domain and cert maintenance entirely; mihomo supports it via the reality-opts field. It's another trade-off at the TLS layer — simpler deployment, more config knobs — but for most users, whatever the provider's subscription gives you is what you use.

Transport: WS, gRPC, and CDN relaying

Another piece of the V2Ray puzzle is the transport layer (network): ws wraps traffic in WebSocket frames, grpc wraps it in HTTP/2 streams, and both can be layered under TLS to look like ordinary website traffic. The real payoff is that this lets you sit behind a CDN: the domain resolves to the CDN, which proxies back to your server, hiding the real IP and potentially improving routing via the CDN's edge nodes. Clash-family cores fully support both ws and grpc transport, described in config via the network, ws-opts, and grpc-opts fields.

The bottom line

For new deployments, go with VLESS + TLS; keep existing VMess nodes as-is. VMess's full encryption still has value where TLS isn't available, but wherever a certificate is in play, VLESS's lower overhead and pass-through forwarding win across the board. A typical config looks like this:

proxies:
  - name: "vless-vision"
    type: vless
    server: example.com
    port: 443
    uuid: "00000000-0000-0000-0000-000000000000"
    network: tcp
    tls: true
    udp: true
    flow: xtls-rprx-vision
    servername: example.com

IVTrojan: A Disguise-First Design Philosophy

Trojan's design doc opens with a blunt verdict: instead of trying to disguise proxy traffic as something else, just make it actually be that something else. A Trojan connection looks, from the outside, like a standard TLS session, with the protocol itself hidden inside the TLS tunnel and auth reduced to a single password hash.

TLS is the whole disguise

A Trojan server listens on port 443 and presents itself as a normal HTTPS site — valid certificate, standard handshake. When it receives a connection it can't authenticate, it can fall back to serving a real website instead. Once authenticated, the TLS payload carries a minimal Trojan request header: password hash, target address, payload. The protocol adds no encryption of its own — that's entirely TLS's job. This mirrors VLESS's approach, just older and even leaner in format.

Trojan's disguise also depends on a detail that's easy to overlook: the server has to actually look like a website. A site with a valid cert on port 443 but no real content behind it stands out under active probing, so most deployments put a real page behind the fallback. This is server-side operations territory and doesn't concern the client, but it's worth knowing when choosing a provider: how convincing the disguise is depends on how well the server side is set up.

How it differs from VMess + TLS

Both run a proxy inside TLS, but Trojan and VMess + WS + TLS differ in how many layers are stacked: the latter wraps TLS around WebSocket around VMess — three layers; the former is just TLS around Trojan — two. Fewer layers means less overhead and a smaller implementation, but also fewer configuration options — Trojan has no transport-layer variants, just plain TCP + TLS. When you do need CDN relaying, Trojan can also run over WebSocket (most cores support it), but that brings back the multi-layer overhead.

Trojan's UDP support works through an in-protocol command byte: UDP datagrams get wrapped inside the TLS stream, and udp: true in the client config turns it on the same way. Because UDP is tunneled inside TCP, it inherits all of TCP's behavior under packet loss — worth contrasting with the native QUIC-based UDP relay in Chapter 5.

Deployment prerequisites and client config

Trojan's simplicity comes with a prerequisite: whoever runs the server needs a domain and a valid certificate, usually issued automatically via ACME, with the domain pointed at the server. On the client side, none of that is your concern — just fill in server, port, password, and sni. sni must match the certificate's domain exactly; setting skip-cert-verify: true disables certificate validation entirely, which defeats the whole point of TLS — only use it temporarily for testing with a self-signed cert, and keep it false in any real config.

proxies:
  - name: "trojan-tls"
    type: trojan
    server: example.com
    port: 443
    password: "your-password"
    sni: example.com
    skip-cert-verify: false
    udp: true

Performance-wise, Trojan's overhead is basically that of a plain TLS session: two to three round trips to handshake (shorter with TLS 1.3 session resumption), one round of symmetric encryption during transfer. On desktop and servers this is indistinguishable from ordinary HTTPS browsing; on mobile, TLS session keep-alive and TCP keep-alive are the main battery drains — more on that in Chapter 6.

VHysteria2 and TUIC: Speed-Oriented Protocols for the QUIC Era

All four protocols covered so far run on TCP, and TCP's reliability guarantee comes at a cost: when a packet drops, the whole stream stalls waiting for retransmission (head-of-line blocking), which can tank throughput on lossy links. QUIC moves reliable transport into userspace on top of UDP, allowing independent retransmission per stream, plus two bonus features: 0-RTT handshakes and connection migration. Hysteria2 and TUIC are the two most widely implemented QUIC-based proxy protocols.

Hysteria2: throughput first

Hysteria2 is a major revision of the original Hysteria — simplified auth, a leaner control plane, with its core selling point being congestion control. Its built-in Brutal congestion control doesn't back off on packet loss; it just keeps sending at whatever bandwidth target you declare. On links with high packet loss but plenty of raw bandwidth (transoceanic wireless, congested peak-hour exits are typical cases), throughput can be several times that of TCP-based protocols. The trade-off is just as blunt: Brutal doesn't care about network conditions, so setting the bandwidth target too high can crowd out other traffic on the same link, and may trigger ISP throttling policies against UDP. The up and down fields in the config are exactly this bandwidth declaration, in Mbps — set them to your server's actual bandwidth, not as high as possible.

Hysteria2's ecosystem also has a practical feature already implemented in mihomo: port hopping. The server listens on a port range, and the client hops between ports within that range as it sends packets, configured via the ports field as a range. This is used to dodge single-port throttling — it's a link-layer trick and doesn't change the protocol's underlying format.

TUIC: a leaner QUIC wrapper

TUIC has a different goal from Hysteria2: minimize the overhead added on top of QUIC. It natively supports UDP relay with two modes — native maps UDP datagrams directly onto QUIC datagrams, while quic folds UDP packets into the reliable stream instead; the former suits latency-sensitive real UDP use cases like gaming and voice calls. TUIC sticks with QUIC's built-in congestion control rather than pushing aggressive acceleration, behaving more conservatively and degrading more gracefully on networks that throttle UDP.

QUIC makes congestion control pluggable, and TUIC's congestion_control field lets you pick between algorithms like bbr and cubic. Roughly speaking, cubic is the conservative default that works everywhere; bbr models bandwidth and latency and tends to be more stable on links with larger buffers. Most users can just leave the default in place — knowing this knob exists just gives you another thing to try if speed is off. TUIC's heartbeat_interval controls the heartbeat frequency and directly affects idle battery drain — on mobile it's fine to stretch this to several seconds or more.

Connection migration and 0-RTT

QUIC's two headline features deserve their own callout. 0-RTT: reconnecting to a server you've already connected to before lets the very first packet carry payload data, skipping a handshake round trip — a proxy connection's cold start feels close to a direct connection. Connection migration: connections are identified by a Connection ID rather than the usual IP/port tuple, so when a phone switches from Wi-Fi to cellular, or hands off between cell towers and its IP changes, the connection survives without dropping or reconnecting — ongoing downloads and calls don't even notice. Both matter far more on mobile than on desktop, and Chapter 6 comes back to this.

proxies:
  - name: "hy2"
    type: hysteria2
    server: example.com
    port: 443
    password: "your-password"
    up: 30
    down: 200
    sni: example.com

VISpeed, Resource Use, and Mobile Battery: A Side-by-Side Comparison

It's easy to misread a protocol comparison as "which one is fastest." The honest answer: on a decent connection, throughput differences between all six protocols are usually too small to notice — the bottleneck is server bandwidth and ISP routing. Protocol differences only really show up in three edge cases: handshake latency, throughput under packet loss, and device overhead. This chapter compares all six along those three axes.

Another commonly overrated metric is speed test scores. How fast a speed test site can saturate your connection depends more on server egress capacity and peak-hour congestion than on the protocol itself; comparing scores across protocols is far less meaningful than just testing the same link three times per protocol and comparing those numbers directly. If you want to run your own test: fix the server and time window, only swap the protocol, run three tests each and take the median, then repeat at a different time of day — once protocol is the only variable, the results actually mean something.

Handshake and first-byte latency

TCP-based protocols start with a TCP handshake (one round trip); those layered under TLS add a TLS handshake on top (one round trip with TLS 1.3, zero if resuming a session). SS skips protocol-level handshaking entirely and has the lowest overall overhead, with Trojan and VLESS close behind. QUIC-based protocols need one round trip on first connect, and 0-RTT on reconnect. On a transoceanic link with ~200ms latency, Hysteria2 and TUIC's first byte on reconnect can arrive nearly half a second faster than TCP + TLS-based protocols — noticeable when browsing pages or hitting short-lived API endpoints.

CPU, memory, and device overhead

During data transfer, CPU cost is mostly symmetric encryption: on x86 devices with AES-NI, AES-GCM can push several Gbps on a single core, making protocol overhead negligible; on ARM devices without AES instructions, ChaCha20-Poly1305 runs roughly two to three times faster than AES-GCM, which is why chacha20-based ciphers are recommended on mobile. Memory usage per connection is under a few MB for every protocol — the real memory cost comes from the core's rule set and connection tracking table, unrelated to protocol choice. On low-power devices like routers, avoiding double encryption (VMess's internal encryption plus an outer TLS layer) frees up meaningful headroom — a real, practical advantage VLESS and Trojan have over VMess.

Mobile battery life

The biggest battery drain on mobile isn't encryption — it's how often the radio wakes up. Long-lived TCP connections rely on keep-alive packets to maintain address mappings, and every wake costs battery; switching from Wi-Fi to cellular breaks the TCP connection outright, and reconnecting means another round of radio activity. QUIC's connection migration keeps switches seamless, and 0-RTT speeds up whatever reconnects are still needed — together, Hysteria2 and TUIC tend to cost less battery and data than TCP-based protocols on days with a lot of network switching. There's a counterforce too: setting the heartbeat interval too short means more frequent idle wake-ups, so err on the longer side for those parameters.

Six-way comparison table

No single protocol wins across the board: SS wins on ecosystem breadth and low latency, QUIC-based protocols win on poor connections and mobile scenarios, Trojan and VLESS win on disguise and low overhead. In practice, first check what your provider offers (Chapter 8), then weigh the three axes above among whatever protocols are actually available.

VIICore Family Tree: Original Clash, Meta, and mihomo

"Clash" refers to three different things in this ecosystem at once: a core, a config format, and a family of clients. Untangling these three is the key to understanding every compatibility question that comes up. The core is the program that does the actual work — listening on local ports, parsing rules, sending packets per protocol; the client is the core's graphical shell; the config format is the contract between the two.

The original Clash core's retirement

The original Clash core, maintained by Dreamacro and written in Go, established the YAML config format, the rule engine, and the proxy group system that every Clash-family client still follows today. In late 2023, the author archived the repository and stopped maintaining it, and the closed-source Premium fork stopped updates at the same time. Archived doesn't mean broken: the original core still runs today, and older protocols like SS, VMess, and Trojan keep working fine — but newer protocols like Hysteria2, TUIC, and VLESS, and newer features like rule-set rule collections, will never be added to it.

Clash Meta and mihomo's succession

Clash Meta was a community enhancement fork that started before the original stopped updating, aimed at filling in the protocols and features it lacked; once the original was archived, Meta became its de facto successor, and later renamed itself mihomo. Its main additions over the original include: support for VLESS, Hysteria2, TUIC, WireGuard, and other protocols; rule-set rule collections, which compile large rule sets into binary format for on-demand loading instead of line-by-line text matching; finer-grained DNS controls like nameserver-policy and fallback-filter; and system-level capabilities like TUN inbound and process-name matching. Every actively used client today — Clash Plus, Clash Verge Rev, FlClash, Clash Nyanpasu, Clash Meta for Android — runs on mihomo. For the full history of how the ecosystem's projects relate to each other, see Mapping the Clash Open-Source Ecosystem; this volume only covers what's relevant to protocol selection.

Config compatibility

Compatibility only flows one way: configs written for the original core will almost always run unmodified on mihomo, but configs written for mihomo that use newer fields won't be understood by the original. Two things to remember in practice. First, older clients (Clash for Windows, older ClashX builds) only understand original-core fields — a hysteria2-type node in a subscription will get skipped or throw an error. Second, mihomo has changed the semantics of a few fields — for example, making default-nameserver required in the dns section — so if migrating a config from the original core throws a startup error, just check each error line against the official docs; it's usually a matter of adding missing fields, not rewriting anything.

Matching clients to cores

The Downloads page's package list is organized around this: Clash Plus as the top cross-platform pick, Clash Verge Rev and FlClash as popular desktop options, Clash Meta for Android on Android — all mihomo-based. Clash for Windows and ClashX Meta are marked discontinued and stuck on the old core generation, kept only for archival purposes. In graphical clients, switching cores is usually just a toggle: Clash Plus and Clash Verge Rev show the core version and update channel right in Settings, while FlClash bundles the core in and updates it along with the app. Most users never need to manually swap out a core binary; doing so is an advanced move, and after replacing one, always validate the config with the -t flag before starting. The practical takeaway: pick a mihomo-based client for any new setup, and only migrate off an older client once it actually breaks.

VIIISubscription Formats and Config Compatibility

A subscription is the delivery format between provider and client: a single URL the client periodically fetches to get a batch of nodes and rules. Two formats coexist in the ecosystem: native Clash subscriptions (a complete YAML file) and generic share-link subscriptions (a bundle of ss://, vmess://, and similar links). mihomo-based clients can import both, but they carry different amounts of information.

Native Clash subscriptions

A Clash subscription returns a complete or near-complete config.yaml: proxies lists the nodes, proxy-groups comes with pre-built proxy groups, and rules carries the routing rules. Providers pre-arrange groups like auto-select, manual select, and fallback, so users can import and go. The upside is that rules and nodes are maintained together — when the provider updates its rules, users get the update automatically; the downside is that different providers take different approaches to rules, so switching providers means switching your whole traffic-splitting setup. When importing a Clash subscription, mihomo-based clients usually let you choose between importing nodes only or adopting the whole package: the former keeps your local rules, the latter replaces them with the provider's — understanding this toggle avoids the confusion of rules suddenly getting overwritten.

Generic share links and subscription conversion

A generic subscription returns share links, one per line: ss:// and trojan:// are URI-formatted, vmess:// is a Base64-encoded JSON blob, and vless://, hysteria2://, and tuic:// each have their own URI conventions. This kind of subscription contains nodes only — no rules — so the client applies its own built-in rule template on import. The service that translates a generic subscription into Clash format is called subscription conversion: either an online service or a self-hosted tool generates the YAML from a template. Be aware of the privacy angle here: a subscription link contains server addresses and credentials, so running it through a third-party converter means handing that node info to someone else — for sensitive nodes, use a self-hosted converter or your client's built-in parsing (most mihomo-based clients can import generic subscriptions directly).

Core-level field differences

The same node is written roughly the same way across cores, but differences concentrate in three areas. First, newer protocol fields: Hysteria2's up and down, TUIC's udp_relay_mode, and similar fields are only understood by mihomo. Second, nested transport options: fields like headers under ws-opts or service-name under grpc-opts are handled with different default-value tolerances by different parsers. Third, the rules section: rule-providers and rule-set are mihomo extensions that the original core will error out on. When editing a subscription's YAML by hand, running the client's config validator or the core's test flag afterward is faster than debugging by trial-and-error restart:

mihomo -d /etc/mihomo -t

Subscriptions also have a more engineering-oriented form in mihomo configs: proxy-providers declares a node list as an external source, refreshed on an interval, with health-check running periodic latency tests, paired with a url-test group for automatic best-node selection. A provider's subscription is, under the hood, just a remote proxy-provider — once you see it that way, running multiple subscriptions side by side or mixing local nodes with subscribed ones is all just variations on the same mechanism.

A subscription solves where nodes come from; rules solve where traffic goes. If the rules bundled with a subscription don't suit you, you can override them in the client or build your own rule set — for full details on rule syntax, matching order, and the MATCH catch-all, see Writing Custom Clash Rules: A Full Guide and Clash Rule-Based Traffic Splitting in Practice — this volume won't go further into it.

IXPicking by Use Case: Decision Table and General Principles

Before boiling down eight chapters of facts into a decision table, one overarching principle: most of the freedom in protocol choice sits with the provider, not the user. For most people, the real decision order is: see what protocols your subscription actually offers, then pick among those based on your use case. Only someone running their own server has full freedom to choose a protocol — those considerations are covered here too.

Desktop daily use: stability first

On desktop, connections are stable and hardware is plentiful, so protocol differences barely matter — just use whatever node your subscription defaults to. If a subscription offers multiple protocols, prefer VLESS or Trojan (lower overhead) or SS (lower latency). For a client, Clash Plus is the top cross-platform pick: mihomo-based, with a full localized UI and config overrides plus a visual editor — see the Downloads page for details.

Mobile: battery and network switching

The two pain points on mobile are network switching and idle battery drain. If your subscription includes Hysteria2 or TUIC nodes, prefer them on mobile networks: connection migration keeps Wi-Fi/cellular switches seamless, and 0-RTT speeds up whatever reconnects are still needed. If you only have TCP-based nodes, relaxing keep-alive parameters and turning off UDP relay you don't need can still save some battery. For platform-specific clients and import steps on iOS and Android, see the Quick Start Guide.

Gaming and real-time voice/video

Gaming, voice calls, and video conferencing are the most sensitive to UDP support and latency. Prefer nodes with udp: true enabled; QUIC-based protocols (especially TUIC's native mode) tend to be the most stable on mobile networks. If you want your game traffic to go through the proxy, remember to route the game's process or domain to your lowest-latency proxy group — the protocol determines a single connection's quality, but rules decide whether it actually gets used.

Poor connections and high packet loss

Transoceanic links, peak-hour congestion, and wireless relays — anything with consistently high packet loss — is where QUIC-based protocols shine: Hysteria2 keeps sending at its declared bandwidth and holds throughput noticeably better than TCP-based protocols; TUIC behaves more conservatively and suits environments where UDP might get throttled. When using Hysteria2, always set up and down to your actual bandwidth — inflating them just makes congestion worse. If UDP is unusable entirely, fall back to SS or Trojan and accept some throughput loss — that's a physical limitation, not a config problem.

Routers and servers

Routers, NAS devices, and servers have no GUI, so running the mihomo core directly is the cleanest approach — just a config.yaml and a startup service. Protocol choice on low-power routers follows Chapter 6's guidance: prefer SS (chacha20-based) or VLESS, and avoid double encryption; when memory is tight, use rule-set instead of large text-based rule files. For a full deployment walkthrough on an OpenWrt bypass router, see Deploying the mihomo Core on an OpenWrt Router.

Self-hosted servers

The decision chain for self-hosting looks like this: if you have a domain and certificate, go with Trojan or VLESS + TLS for the best disguise and overhead; if you'd rather skip maintaining a domain and cert, SS (2022-series ciphers) is the lowest-maintenance option; if your route has heavy packet loss but UDP works fine, add Hysteria2 alongside a TCP-based option and switch based on the situation. Beyond protocol choice, self-hosting also depends heavily on system updates, key strength, and how exposed your management interface is — outside this volume's scope, but no less important than the protocol itself.

Decision table

Protocol is just one piece of the link, not the whole picture: rules decide whether traffic-splitting is smart, DNS decides whether resolution is clean, and the core plus client define the outer limits of what's possible — all three matter as much as protocol choice. For how nameserver and fallback DNS settings work together, see A Full Guide to Clash DNS Configuration; for troubleshooting common connection issues, see the FAQ page. If you're still unsure after reading this volume, the safest path is to go back to the Quick Start Guide, get the default config running first, then swap things out one at a time.