Windows
Windows is the primary focus. Compare Clash Plus, Clash Verge Rev, FlClash, Clash Nyanpasu, and archived clients, and distinguish graphical clients from standalone cores before installing.
Go to Downloads
OPEN SOURCE CLIENT ROUTE
Clash for Windows
Clash for Windows
Download & Configure
Organized around Windows while covering desktop and mobile platforms. Choose a client first, then configure subscription imports, rule-based routing, and Fake-IP DNS through the relevant menus and configuration fields.
Free forever
Open source
Chinese documentation
Rule mode
PLATFORMS: WINDOWS / MACOS / ANDROID / IOS / LINUX
CORE: MIHOMO
MODE: RULE / GLOBAL / DIRECT
CONFIG: YAML
PLATFORM ENTRY
Choose your system for client downloads
The homepage routes you to the right platform instead of listing installers here. Select an operating system to open the download page and switch to that platform automatically; client variants, supported architectures, maintenance status, and installation methods are explained there. Confirm your device and OS first, then choose a graphical client—it is faster than repairing a mismatched package later.
macOS
Choose an installer architecture for Apple Silicon or Intel. Graphical clients suit everyday menu-bar use, while standalone cores are better suited to terminals, automation, and service deployments.
Go to DownloadsAndroid
Suitable for phones and tablets. Check the device architecture and OS requirements before downloading. After importing a subscription, grant permission for a local VPN connection; battery-saving policies may also affect background connectivity.
Go to DownloadsiOS
Install Clash Plus through the app store. After installation, import a configuration from its subscription URL and choose a policy group for your needs; explicitly approve the network configuration request when the system displays it.
Go to DownloadsLinux
Desktop environments can use a GUI client, while servers, software routers, and containers typically run the mihomo core directly. Check the processor architecture first, then choose a deb package or archive.
Go to Downloads
WINDOW PANE ROUTER
Four Configuration Areas, Explained
Clash is rarely difficult because of a single switch; the challenge is how configuration files, policy groups, rules, and DNS interact. The sections below follow a practical troubleshooting order: identify the matching rule, check the selected policy group, then inspect DNS and subscription updates. Switch topics on the left while the right side preserves real YAML or rule snippets.
Rule-Based Routing: Match Order Is Execution Order
Rule mode checks requests from top to bottom and stops at the first match. Domain rules work well for specific services, GEOIP handles geographic ownership, and MATCH catches everything left over. Put specific rules first and the fallback rule last; an overly broad rule can otherwise capture traffic too early. Unlike clients that offer only a global switch, Clash lets you define direct connections, proxying, and blocking in one readable rule table. Connection logs can then reveal which rule matched.
DOMAIN-SUFFIX,github.com,PROXY
DOMAIN-SUFFIX,local,DIRECT
GEOIP,CN,DIRECT
MATCH,FallbackPolicy Groups: Rules Choose Where Traffic Goes, Groups Choose Which Proxy to Use
PROXY in a rule is often the name of a policy group rather than a fixed node. select is suited to manual choice, url-test selects automatically from test results, and fallback tries alternatives in order of availability. First confirm that every group referenced by rules exists, then check that its nodes or child groups are complete. Separating traffic categories from individual nodes means changing subscription nodes does not require rewriting the entire rule set—an especially maintainable structure for long-lived configurations.
proxy-groups:
- name: PROXY
type: select
proxies:
- Auto
- DIRECT
- name: Auto
type: url-testFake-IP DNS: Domain Mapping Works with the Connection Phase
Fake-IP mode returns a reserved address first; during connection setup, the core restores the original domain and applies the rules. This makes domain-based routing more consistent, but it requires the system DNS, client listening port, and rules to agree. If LAN devices behave oddly, specific apps cannot connect, or DNS results bypass the rules, check fake-ip-filter, nameserver, and respect-rules first instead of repeatedly changing nodes. Diagnose DNS problems separately from proxy-node problems.
dns:
enable: true
enhanced-mode: fake-ip
respect-rules: true
fake-ip-filter:
- "*.lan"Rule Blocking: Stop Explicit Requests at the Routing Layer
REJECT directly denies matching connections and is useful for confirmed tracking domains, telemetry endpoints, or destinations you do not want to access. Keep the scope narrow: prefer exact domains or maintained rule sets, and avoid broad suffixes that could break login, payment, or messaging services. When part of a page fails to load, look for a matching REJECT entry in the connection log and temporarily switch the rule to verify it. Blocking should be traceable and reversible, not a black box built from vague rules.
DOMAIN,telemetry.example,REJECT
DOMAIN-SUFFIX,tracker.example,REJECT
DOMAIN-SUFFIX,service.example,PROXY
MATCH,FallbackSubscription Profiles: Updates Affect the Profile, Not an Individual Node
A subscription URL usually returns a complete configuration containing nodes, policy groups, rules, and DNS. After importing it, review the update result and confirm which Profile is active; “update succeeded” does not necessarily mean the new configuration is active. When multiple subscriptions coexist, name them by source and purpose instead of keeping default names. Before editing a remote configuration, check whether the client will overwrite local changes during the next update. For long-term customization, manage an override layer separately from the remote subscription.
profile:
store-selected: true
store-fake-ip: true
mode: rule
log-level: info
OPEN SOURCE LINEAGE
The Open-Source Ecosystem and Its Cores
In practice, “Clash” can refer to a rule system, configuration format, core branch, or several graphical clients. Separating these layers makes it easier to tell whether a guide covers interface steps, YAML fields, or core capabilities.
Original Clash Established the Configuration Model
The original Clash brought proxy nodes, policy groups, rule routing, and DNS together in one configuration model. Many clients adopted this approach, which is why familiar fields such as proxies, proxy-groups, and rules still appear today. Project history explains the shape of the configuration, but installation choices require more than the word “Clash”: check whether the client is maintained, which branch supplies its core, and whether it matches your target system.
Graphical Clients Handle Interaction; Cores Handle Execution
Graphical clients provide subscription management, system-proxy switches, policy-group selection, connection logs, and settings screens. The core is what parses configuration, handles connections, and executes rules. Two clients can look completely different yet share highly similar routing behavior when they use compatible configurations and similar cores. Conversely, identical option names in their interfaces do not guarantee the same core capabilities, configuration compatibility, or update cadence.
mihomo Continues and Extends Meta Capabilities
mihomo is one of the active cores commonly used in today’s Clash ecosystem. It follows the Clash.Meta lineage while extending protocol, rule, DNS, and transparent-proxy capabilities. Desktop users generally access these features through a GUI client that integrates mihomo; servers, routers, and automated environments may run the core directly. Choose a GUI or core based on your needs first, then evaluate protocol and configuration support—do not mistake a core archive for a desktop installer.
Track Client, Core, and Subscription Updates Separately
Client updates fix interface and system-integration issues; core updates affect protocol, rule, and DNS behavior; subscription updates change nodes and remote configuration. These are separate actions. When something breaks, note which layer changed most recently: the client, the core, or the subscription. That tells you whether to roll back the application, switch cores, or restore a Profile instead of blaming every problem on a failed node.
QUICK DIAGNOSIS
Frequently Asked Questions
Break the problem down by symptom instead of reinstalling immediately. Check the client interface, subscription profile, system proxy, DNS, and proxy path separately to locate the fault faster.
No Nodes After Importing a Subscription?
Review the Profile update notice and returned content first, then confirm that the newly imported configuration is active. An expired URL, incompatible format, empty remote response, or an update that did not switch Profiles can all appear as an empty list. Do not keep clicking Update; read the error message first.
View Installation and Configuration FAQs →Clash Is Enabled but the Internet Does Not Work?
Check in order that the configuration loaded successfully, the system proxy or TUN is enabled, the policy group has a usable selection, and the connection log is not matching REJECT. If every request fails, switch to DIRECT for a baseline test and use the result to distinguish a proxy-path problem from a local network problem.
View Troubleshooting Guide →Rule Mode or Global Mode?
Use rule mode for everyday traffic, letting the configuration decide between DIRECT, PROXY, and REJECT. Global mode is useful for temporarily verifying the proxy path, not as a long-term troubleshooting conclusion; direct mode can test the local network. Mode switching is a diagnostic tool, not a scale where stronger is always better.
View Getting Started Guide →Why Does It Still Lag with Low Latency?
A client latency test usually measures only one handshake path to a test address. It does not represent sustained bandwidth, packet loss, congestion, or routing to the destination site. Choose nodes using region, multiplier, protocol, and real workload tests as well; a single millisecond figure is useful only for initial screening.
View Latency Deep Dive →
FIELD NOTES
Latest Practical Guides
No “magic settings.” Each article focuses on one concrete problem and explains the configuration structure, decision order, and commonly misunderstood concepts. The three guides below cover subscription formats, node selection, and latency testing—the three most common sources of confusion in everyday use.
Clash Subscription Formats Explained: Base64, YAML, and Generic Formats Compared and Converted
Compare Clash YAML, base64 share content, and generic subscription structures, including strategy groups, rules, and extension fields that may be lost during conversion, plus compatibility checks to make before migrating clients.
Continue Reading →How to Choose a Clash Node: Practical Criteria for Latency, Multipliers, Region, and Protocol
Latency is only for initial screening; the multiplier determines traffic cost, region affects content and routing, and protocol affects stability and device load. This guide offers a more reliable selection order than simply chasing the lowest number.
Continue Reading →Where Clash Latency Numbers Come From: Why a 60 ms Node Can Still Buffer Video
Breaks down how client latency tests actually work, distinguishing handshake round trips, sustained throughput, packet loss, and routing to the destination site. A good-looking number does not guarantee a stable experience under load.
Continue Reading →