Clash Guide: Installation, Configuration and Rule Routing

Strip a Clash-style client down and it does three things: opens a local listening port to catch traffic, checks a rule list to decide where each connection should go, and forwards the connections marked for proxy to a remote node. Every setting in the chapters ahead maps back to one of these three jobs. This chapter doesn't touch any settings — it just builds the vocabulary you'll need later.

What a Proxy Client Actually Does

Once running, the client listens on one or more local ports — most commonly a mixed HTTP/SOCKS5 port. Your OS or browser sends requests to that port; the client checks them against its rule list: matches for direct connection go straight out through your network adapter, matches for proxy get wrapped up and sent to a remote proxy server, which fetches the target on your behalf. To every other app on your machine, the client just looks like a normal local proxy. To the destination site, the request appears to come from the remote node.

The mistake beginners make most: installing a client doesn't mean you have proxy access. The client itself ships with zero nodes — it's the dispatcher, not the exit. Nodes come from a subscription or manual entries; that's covered in Chapter 4.

Kernel: mihomo Is the Active Mainline

Clash has two kernel lineages. The original Clash kernel has long been discontinued and archived. The community mainline is Clash Meta, later renamed mihomo — every GUI client on this site's download hub runs on it. mihomo extends the original with more proxy protocols, more rule types, and stronger TUN support, while staying config-compatible, so old config files mostly carry over as-is. The full breakdown lives in the blog post "Clash Kernel Differences: Original Clash, Clash Meta and mihomo" — the short version here: for any new install, pick a mihomo-based client.

Nodes, Rules, Subscriptions: The Three Building Blocks

Node (Proxy) is a remote proxy server plus its connection details: address, port, protocol, credentials. Common protocols include Shadowsocks, VMess, Trojan, and Hysteria — the client handles the protocol wrapping, so you don't need to worry about the internals.

Rule is a routing condition, like "if the domain suffix matches X, connect directly." The rule list is an ordered list, covered in depth in Chapter 6.

Proxy Group sits between rules and nodes: a rule doesn't point straight at a node, it points at a proxy group, and the group decides which node to actually use — either picked by hand or chosen automatically by latency. Covered in Chapter 5.

Subscription is a URL that returns a config file on a schedule, bundling nodes, proxy groups, and rules together. One subscription gets you all three at once — covered in Chapter 4.

The Full Path of a Single Request

Take a browser loading a page as an example: the browser sends the request to whatever local port your system proxy setting points to; the client intercepts the connection and checks it against the rule list from top to bottom; a match hits the "Proxy" group, and the group picks a node based on its own logic; the client opens an encrypted connection to that node and forwards the request; the response comes back the same way. All of this happens locally — the browser never knows.

There's no universally "best" client — only the right fit for your platform and habits. This chapter gives platform-by-platform picks; for a full side-by-side feature comparison, see the client comparison page; installers for every platform are on the download hub.

Picks by Platform

Windows: Clash Plus is the top pick — UI and kernel updates stay in sync. Alternatives: Clash Verge Rev (most feature-complete panel), FlClash (consistent cross-platform experience), Clash Nyanpasu (distinct UI style).

macOS: Clash Plus, with separate builds for Apple Silicon and Intel. Alternatives: Clash Verge Rev and FlClash, both also split by chip architecture — installing the wrong build will still launch, just with worse performance.

Android: Clash Plus. Alternatives: Clash Meta for Android (same-name kernel client, frequently updated), FlClash, Surfboard (minimalist UI).

iOS: Clash Plus is on the App Store — search and install directly; platform notes are also on clashplus.io. On iOS, the client works as a system-level VPN configuration, giving you the same experience as desktop.

Linux: use Clash Verge Rev or FlClash on desktop (deb and rpm packages provided). For headless setups — servers, routers — deploy the mihomo kernel directly, manage it with a config file and an external controller. Covered in Chapter 9.

Kernel Lineage: Original vs. mihomo

After the original Clash kernel stopped receiving updates, the classic clients built on it stopped too: Clash for Windows on Windows, ClashX Meta on macOS. The download page keeps both for reference only, tagged "discontinued." New users don't need to worry about the history — just pick a maintained mihomo-based client, which supports the widest range of protocols and the newest rule types.

Migrating Away From a Discontinued Client

If you're still on Clash for Windows or ClashX Meta, it'll keep working for now, but it won't get support for new protocols or rule types — that's the first thing to suspect if nodes stop connecting. Migration is cheap: note your existing subscription link, install a mihomo-based client, and re-import the subscription. The proxy groups and rules bundled in the subscription come along automatically — no need to copy anything by hand.

This chapter covers install steps and post-install checks by platform; download links aren't repeated here — grab them from the download hub. For a general walkthrough of first-time setup across all four major platforms plus common beginner pitfalls, see the blog post "Clash First-Time Install and Setup".

Windows

Download the .exe and run the installer. Most clients also offer a portable build — unzip and run, no registry writes, handy for USB drives or moving between machines. Check each card on the download page for exact requirements; most clients need Windows 10 or later. If a firewall prompt appears on first launch, allow the client to communicate on private networks — even for local-only use, this avoids extra confusion during later troubleshooting.

macOS

Download the dmg matching your chip: arm64 for Apple Silicon, x64 for Intel. Drag the app into Applications and open it — if macOS says it "cannot verify the developer," go to System Settings → Privacy & Security and click "Open Anyway." A menu bar icon confirms it launched successfully.

Android and iOS

On Android, grab the apk from the download page and install it directly — the system will ask you to allow "install from unknown sources," which you can revoke once installed. On first connection, Android will prompt a VPN connection request — this is the standard way proxy clients work on Android, and you must allow it, or the client won't be able to intercept any traffic. On iOS, install Clash Plus from the App Store, and allow the VPN configuration prompt the first time you add a profile.

Linux

Install Clash Verge Rev or FlClash via deb or rpm on desktop distros, then launch from your app menu. For headless setups — servers, routers — skip the GUI entirely: download the mihomo binary for your architecture, pair it with a config.yaml, run it under systemd for auto-start and management via external controller. Details in Chapter 9.

Four Things to Check on First Launch

Before importing a subscription, spend two minutes confirming these four things:

• Interface language: most clients let you switch languages from settings on first launch.
• Launch at startup: turn this on in settings so you don't have to launch it manually every time.
• Where the system proxy toggle lives: locate it now — you'll need to flip it on after importing a subscription in Chapter 4 for traffic to actually route through the client.
• The mixed port number: write it down (commonly 7890 by default) — you'll need it later for routing command-line tools through the proxy or sharing it on your LAN.

Once all four are confirmed, installation is done — move on to Chapter 4 to import a subscription.

Nodes, proxy groups, and rules — all three arrive in one shot through a subscription link. This chapter covers what a subscription is, how to import one, how to keep it updated, and the order to troubleshoot in when updates fail.

What a Subscription Link Is

A subscription link is a URL that returns a config file — the text contains a node list, proxy groups, and a rule list. The client periodically fetches this URL for the latest config. Subscription links come from your node provider; the client itself never ships with any nodes. These links usually embed your account credentials, so treat them like a password: don't post them anywhere public, don't import subscriptions from unknown sources, and when switching devices, move the link manually rather than forwarding it through chat.

Three Ways to Import a Subscription

URL import (most common): copy the subscription link, open the client's "Profiles/Subscriptions" page, create a new profile, paste the URL, name it, and save. Clipboard import: some clients detect a subscription link on your clipboard and offer a one-click import when you open the app. Local file import: if you already have a config.yaml, choose "Import Local File" from the profiles page, or drop the file straight into the client's config directory.

Importing just adds it to the list — you still need to mark it "active" for the client to actually run on it. Multiple subscriptions can coexist; switching the active profile switches the whole set of nodes and rules at once.

Updating Subscriptions and Auto-Update

Nodes come and go, rules get revised — subscriptions need regular updates. Most clients offer both a manual "Update" button and an auto-update interval; turn on 24-hour auto-update and get in the habit of manually updating whenever nodes feel off. If an update fails, the client keeps running on the old config — no sudden disconnect — but repeated failures mean the node list is stuck on an old snapshot, and dead nodes will pile up over time.

Subscription Update Fails: A Four-Step Check

① Reachability: can you even reach the subscription URL? Turn off the system proxy and try direct — some subscription URLs are actually blocked while proxied. ② Link validity: has the link expired, been reset, or has the plan run out — check with your provider. ③ Client fingerprint: some providers serve different formats based on client UA — try a different client, or update to the latest version. ④ System clock: TLS certificate checks depend on the system clock; too much drift breaks the handshake outright — sync the time and retry.

A subscription's returned config text looks roughly like this (snippet):

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

proxy-groups:
  - name: PROXY
    type: select
    proxies: ["example-node", "DIRECT"]

rules:
  - GEOSITE,cn,DIRECT
  - MATCH,PROXY

Learn to spot these three sections in any config and later chapters won't feel intimidating: proxies is the node list, proxy-groups is the group setup, rules is the rule list.

The three proxy modes control whether — and how — the rule list gets used. The toggle usually lives on the client's home screen or tray menu; you can switch anytime, and it takes effect instantly with no restart needed. To check which mode you're in, look at the mode indicator on the home screen or tray icon.

Rule Mode

The default and what you should leave running day to day. Every connection is checked against the rule list top to bottom: a proxy match routes through a node, a direct match goes out your local network adapter. Domestic sites stay fast via direct connection, sites outside China stay reachable via proxy — neither interferes with the other. The rule list bundled with your subscription already covers the common cases, and most people never need to touch it.

Global Mode

Every connection goes through whatever node the proxy group picks, and the rule list is ignored entirely. Two real use cases: quickly testing whether a node works at all, or accessing a service that requires everything to exit through the same node. Leaving Global mode on long-term routes domestic traffic through an overseas node too, which slows things down and can trigger anti-bot checks on some sites — switch back to Rule mode when you're done.

Direct Mode

Every connection skips proxying entirely — the client just passes traffic through without touching nodes at all. Use case: diagnostics. If you're unsure whether the problem is a bad node or a broken client, switch to Direct — if sites load fine, the client and rules are fine and the problem is the node. Also useful for briefly turning off proxying on a fully trusted network.

Proxy Groups: Grouping Containers for Nodes

A proxy group sits between rules and nodes. A rule doesn't point at a node directly — it points at a group, and the group decides which node to actually use based on its type. Four common types:

• select (manual): lists nodes for you to pick by hand — the most common type, good for a fixed "main node + backup" setup.
• url-test (auto-latency): periodically pings every node in the group and switches to whichever has the lowest latency — good when you have a lot of nodes and don't want to babysit them.
• fallback (failover): uses the first available node in list order, automatically moving to the next if one drops — good when you want stability over raw speed.
• load-balance: spreads connections across multiple nodes in the group — good for heavy download traffic.

A proxy group in config looks like this:

proxy-groups:
  - name: PROXY
    type: select
    proxies: ["Auto", "example-node", "DIRECT"]
  - name: Auto
    type: url-test
    proxies: ["example-node"]
    url: http://example.com/generate_204
    interval: 300

The proxy groups bundled with a subscription are usually enough on their own: one manual-select group for daily use, one auto-latency group as a fallback. Custom grouping by region or purpose is hand-written config territory, covered in Chapter 9.

Rule routing is the core capability of a Clash-style client, and what sets it apart from "everything through one tunnel" tools. This chapter covers every rule type, explains match order in detail, and walks through a working domestic/overseas split config plus how to verify it. For more worked examples of rule syntax, see the blog post "Clash Rule Routing in Practice".

Rule Type Reference

mihomo supports many rule types; these are the ones you'll actually use day to day:

• DOMAIN: matches one exact domain, e.g. DOMAIN,example.com,PROXY — matches only that domain itself.
• DOMAIN-SUFFIX: matches a domain suffix, e.g. DOMAIN-SUFFIX,example.com,PROXY — matches that domain and all its subdomains, the most commonly used domain rule.
• DOMAIN-KEYWORD: matches if a keyword appears anywhere in the domain, e.g. DOMAIN-KEYWORD,example,PROXY — broad coverage, also broad for false positives, use with care.
• GEOSITE: matches against a domain classification set, e.g. GEOSITE,cn,DIRECT matches the bundled set of mainland China domains — one line stands in for tens of thousands of hand-written rules.
• IP-CIDR: matches a target IP range, e.g. IP-CIDR,192.168.0.0/16,DIRECT routes all LAN addresses direct. A rule with the no-resolve flag skips DNS resolution and only matches raw IP connections.
• GEOIP: matches by IP geolocation, e.g. GEOIP,CN,DIRECT — domains get resolved to an IP first, then checked against the geolocation database.
• PROCESS-NAME: matches by the process that opened the connection, desktop-only — useful for pinning a specific download tool to always use the proxy.
• DST-PORT / SRC-IP-CIDR: matches by destination port or source IP range — common in LAN sharing and gateway setups.
• MATCH: the catch-all — matches everything, and must be the very last line in the rule list.

Match Order: Top to Bottom, First Match Wins

The rule list is an ordered list: each new connection is checked from the top down, and whichever rule matches first is the one that applies — nothing below it gets checked. This gives you two hard rules: ① put more specific rules first, broader ones later; ② MATCH as the catch-all always goes last — move it up and every rule below it stops working. When some site is routing the "wrong way," the first thing to check is order — is a broader rule sitting above it stealing the match?

A rule's target can be a proxy group or a reserved keyword: DIRECT for a direct connection, REJECT to block the connection outright (commonly used for ad/tracking domains), or a proxy group name to let that group decide the exit.

GEOSITE and GEOIP Data Files

GEOSITE and GEOIP rules rely on two classification data files (geosite.dat and the GEOIP dataset), shipped with the client and kept updated by the community. Stale data files mean new domains get misclassified — showing up as "a domestic site went through the proxy" or the reverse. Most clients have an update button for these data files in settings — pair it with your monthly subscription update routine, see Chapter 8.

In Practice: A Domestic/Overseas Split Config

A typical domestic/overseas rule list (excerpt, order matters):

rules:
  # LAN and reserved addresses go direct
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  # Domestic domains and IPs go direct
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT
  # Everything else goes to the proxy group
  - MATCH,PROXY

Build on this base as needed: to force a specific overseas site through the proxy, add a line like DOMAIN-SUFFIX,target-domain.com,PROXY above the GEOSITE line; to block a category of ad domains outright, add GEOSITE,category-ads-all,REJECT near the top. When your subscription already includes a rule list, add extras through the client's "Override/Custom Rules" feature rather than editing the subscription file directly — the next update will wipe out any manual edits.

Verifying the Routing Result

Always verify after changing rules. Open the client's "Connections" panel, visit the target site, and check the new connection entry — the panel shows which rule matched, which proxy group it went through, and which node was used. If the match doesn't match your expectation, go back and reorder based on the rule name shown there. Set the client's log level to debug for even finer-grained rule evaluation output.

System proxy has a natural blind spot: it only works for apps that "respect the system proxy setting." Browsers and most desktop apps do; but command-line tools, some games, apps that manage their own network stack, and nearly all UDP traffic bypass it entirely and connect direct. TUN mode is what closes that gap.

What TUN Is

TUN mode creates a virtual network adapter on your system and rewrites the routing table so that all TCP/UDP traffic on the whole machine flows through that adapter into the client first, which then routes it by rule. The takeover happens at the network layer, so it doesn't depend on apps cooperating — command-line tools, games, system services, and UDP traffic all get covered. On Android, the client already works as a VPN service by default, achieving the same effect; TUN is mainly a desktop-only (Windows/macOS/Linux) enhancement toggle.

How It Divides Work With System Proxy

The two don't conflict and can run together: system proxy handles "well-behaved" apps, TUN handles everything else. Most clients automatically sort out the relationship between the two when TUN is on — you don't need to manually pick one. If you mostly browse and only occasionally use the command line, system proxy alone is enough; if you regularly run CLI tools, play games on overseas servers, or need UDP forwarding, keep TUN on all the time.

Requirements to Enable It

TUN touches the system network stack, so it needs more privilege than a normal proxy. On Windows, most clients implement this via a "service mode": follow the prompt in settings to install the service once, and after that the TUN toggle works normally without needing to launch the client as administrator every time. macOS asks for your system password the first time to authorize the helper install. Linux desktop clients need similar authorization; on servers, running the kernel directly with TUN requires the process to have the right network privileges.

Example Configuration

In GUI clients, TUN is usually just a toggle, but underneath it maps to a tun block in the config — hand-written, it looks like this:

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

Key fields: stack is the protocol stack implementation for the virtual adapter, mixed is a common choice balancing compatibility and performance; auto-route lets the client configure the routing table automatically; auto-detect-interface auto-detects the outbound network interface to avoid routing loops; dns-hijack intercepts all DNS queries on port 53 system-wide and routes them into the client's DNS module — pairs with the DNS setup in Chapter 9.

Things to Watch For

① Conflicts with other VPNs/accelerators: two virtual adapters both rewriting the routing table at once leads to unpredictable traffic paths — only keep one active at a time. ② Firewall blocking: some security software blocks the virtual adapter driver — if the network drops right after enabling TUN, check this first. ③ Clean shutdown matters: an unexpected exit can leave stale routing table entries that break connectivity — toggling TUN off and on again, or restarting the machine, fixes it. ④ Not needed for everything: if you're just browsing, skip TUN — one less layer of interception means one less category of things that can break.

Once the client is set up, the real time sink isn't configuration — it's upkeep: subscriptions need updating, data files go stale, nodes die, and the client itself keeps shipping new releases. This chapter gives a maintenance checklist you can just follow, plus a self-diagnosis path for common problems. The FAQ page has more scattered Q&A; this chapter covers the recurring maintenance routine.

Maintenance Checklist

Subscription updates: keep 24-hour auto-update on; if nodes fail en masse, the first move is always a manual subscription update — ruling out the most common cause, a stale node list.

GEOSITE / GEOIP data updates: once a month, from client settings. These files control how accurately domains and IPs get classified — leave them stale too long and routing decisions drift from reality.

Client updates: follow the built-in update prompt. Kernel updates often carry protocol and security fixes, so it's not a good idea to sit on an old version long-term. No need to uninstall first — your config carries over.

Config backups: keep the subscription link somewhere safe like a password manager or encrypted notes; export a copy of any hand-written config (custom rules, overrides). With a saved subscription link plus an override backup, restoring after a reinstall or new machine is complete and painless.

Handling a Dead Node

If just one node stops working, switch to a backup in the proxy group manually first — don't rush to edit config. If the whole group times out, check in order: manually update the subscription → switch to Global mode to rule out a rule mismatch → switch to Direct mode to confirm your local network is fine → try a different network (like a phone hotspot) to rule out an ISP-side issue. If all four steps come up empty, contact your node provider.

Logs and the Connections Panel

The client gives you two powerful diagnostic tools. Connections panel: lists every connection in real time with process, destination, matched rule, exit node, and traffic count — this is where "why didn't this site go through the proxy" gets answered instantly. Logs: default info level logs key events; switch to debug when troubleshooting something tricky to see rule-by-rule evaluation and DNS resolution detail — switch back to info once you're done, since debug logs are large and record what you visited, not something to leave on permanently.

Common Issue Self-Check Table

Anything not covered here, check the FAQ page by category — the blog's troubleshooting tag also has issue-specific write-ups, like "Clash DNS Leak Testing".

After the first eight chapters, day-to-day use has no roadblocks left. This chapter gives users who want to go deeper a roadmap, ordered from light effort to heavy, each stop with a clear goal and matching resources on this site.

Stop 1: Overriding the Subscription Config

The config bundled with your subscription is maintained by the provider — edit it directly and the next update wipes your changes out. The right approach is the client's "Override/Mixin" feature: define your own supplemental snippet — extra rules, tweaked proxy groups, a changed port — and the client automatically merges it in after every subscription update. This is the first step from "using a subscription" to "managing your own config," and it pays off immediately for very little effort.

Stop 2: Rule Providers (rule-providers)

Once you have a lot of rules, cramming them all into the rules list gets hard to manage. mihomo supports rule-providers: package a category of rules (say, every domain for one app) into a standalone rule-set file or online source, then reference it by name in your config — and update that rule set independently. Paired with proxy groups, you can build a clean "one app, one rule set, one exit" structure.

Stop 3: The DNS Module

DNS is the foundation of accurate routing. The client's built-in DNS module intercepts domain resolution: nameserver sets the standard resolver, fallback sets a backup resolution path for overseas domains, and enhanced-mode controls the enhanced resolution behavior. Configured correctly, it eliminates DNS tampering interference with GEOIP matching and prevents resolution requests from leaking outside the proxy tunnel. There's a lot to this stop — read the two dedicated blog posts directly: "Clash DNS Configuration Explained" covers the parameters, "Clash DNS Leak Testing" covers verification and fixes.

Stop 4: LAN Sharing and Gateway Setup

With allow-lan: true enabled in your config, other devices on your LAN (phones, tablets, TVs) can point their proxy settings at this machine's IP and mixed port to share the same client. Take it a step further and deploy the client on a router or an always-on box, pairing it with TUN to take over the whole subnet — that's a home gateway setup, where every device on the network gets routed with zero per-device configuration.

Stop 5: Deploying mihomo on Servers and Routers

For headless setups, run the kernel directly: download the mihomo binary for your architecture, prepare a complete config.yaml, and run it under systemd for auto-start and crash recovery. With external-controller enabled, you can manage it remotely via API or a web dashboard — switching nodes, checking connections, viewing logs, all without logging into the server. Example unit file:

[Unit]
Description=mihomo proxy core
After=network.target

[Service]
ExecStart=/usr/local/bin/mihomo -d /etc/mihomo
Restart=on-failure

[Install]
WantedBy=multi-user.target

Put config.yaml and the GEOSITE/GEOIP data files in the /etc/mihomo config directory. After editing config, run systemctl restart mihomo to apply it, and journalctl -u mihomo to check logs.

Where to Keep Learning

Advanced content is kept updated in three places on this site: the FAQ page organizes frequent questions under "Basics / Setup / Usage Tips / Troubleshooting"; the blog keeps publishing new posts on kernels, configuration, DNS, and troubleshooting; the tutorial page is the fast route to walk a new teammate or new device through. If something here doesn't cover your situation, check the FAQ's category navigation first, then browse blog tags.