Latest Clash Client Downloads
for Every Platform

Rule-based routing is Clash's core capability: the rule list in your config file is matched top to bottom, and the first match decides whether a connection goes direct, through a proxy, or gets blocked outright. Common rule types include domain suffixes, keywords, IP ranges, and GeoIP regions, and paired with community-maintained rule sets, local sites load instantly while services outside your region automatically route through a node — with zero conflict between the two. Unlike an all-or-nothing global proxy, rule-based routing saves node bandwidth without slowing down local browsing, which is exactly what sets Clash apart from a typical VPN client. Write the rules once, and they work across every platform's client.

Proxy groups sit above individual nodes as a scheduling layer: a select group lets you pick a node manually, a url-test group auto-picks the lowest-latency node, a fallback group switches automatically when the primary node fails, and a load-balance group spreads requests across multiple nodes. Pin a specific unlock-capable node for streaming while leaving everyday browsing to an auto-latency group, letting different apps follow different strategies. Rules point to proxy groups rather than individual nodes, so adding, removing, or swapping nodes later never requires touching a single rule — keeping config maintenance to a minimum.

A latency test sends a single request to a target address and times the response, producing a number for each node that's then used to rank and filter. Keep in mind low latency doesn't mean high bandwidth — it reflects handshake speed, not download throughput, so check whether latency stays stable before judging by real-world performance. Once nodes are assigned to a url-test group, the client re-tests at a set interval and automatically switches to whichever node currently performs best, no manual checking required. For a deeper look at how latency testing works and what commonly skews the numbers, see the latency testing explainer on this site's blog.

Proxy providers and self-hosted setups typically distribute nodes via a subscription link: paste it into the client to import every node and group in one go, then let it auto-refresh on a set interval so nodes never need manual upkeep. Multiple subscriptions can coexist, and combined with rule sets they can share a single routing setup. A subscription link works like a login credential, so never share it with anyone else. An expired link or exhausted data plan is the most common reason all nodes suddenly stop working — if every node times out at once, refresh the subscription first before troubleshooting anything else; it saves a lot of wasted debugging.

System proxy settings only affect apps that respect them — games, command-line tools, and some desktop apps often bypass them entirely and connect directly. TUN mode creates a virtual network adapter at the OS level that intercepts all traffic at the network layer, handing it to the core for rule-based routing so nothing slips through. The first time you enable it, you'll need to authorize a network component install; it's already built into the leading Windows and macOS clients. Everyday browsing usually doesn't need TUN mode — turn it on only when a specific app refuses to route through the proxy, rather than leaving it on permanently.

DNS is an easily overlooked link in the proxy chain: if resolution gets tampered with, even a great node can't reach the right server. The Clash core has a built-in DNS module that routes queries to different upstream servers based on domain — domains outside your region resolve through the proxy, local domains resolve through your local ISP — with support for encrypted DoH and DoT queries. Configured correctly, it also prevents DNS leaks that would otherwise expose your browsing history. For what fields like nameserver and fallback actually mean, plus two ready-to-use config examples, see the DNS deep-dive on this site's blog.