Open-source ecosystem · Cross-platform clients and configuration guides
Choose a client based on your current system and use case, then import a subscription, select a policy group, and enable network interception. The focus is on cross-platform downloads, rule routing, and troubleshooting in English, making it easier to find the right steps during initial setup and ongoing maintenance.
Windows、macOS、Android、iOS、Linux
Compatible with Clash configurations while extending rule, protocol, and network interception capabilities.
The core code is public, allowing the community to review configuration behavior and version changes together.
Network permissions, background behavior, and package formats vary by platform. Open the relevant platform section first, then choose a client based on whether you need a desktop GUI, a persistent mobile connection, or a server deployment.
Ideal for desktop users who need tray controls, system proxy switching, startup launch, and TUN interception. The download page compares the maintenance status and use cases of Clash Plus, Clash Verge Rev, FlClash, Clash Nyanpasu, and archived clients.
Go to downloadsSupports both Apple Silicon and Intel Macs. When choosing an installer, verify the processor architecture and review system proxy permissions, login items, and network extension authorization. If you need to intercept apps that ignore system proxy settings, enable TUN after understanding its routing impact.
Go to downloadsAndroid clients typically use the system VpnService to intercept app traffic. In addition to importing a subscription, configure background operation, battery-optimization exceptions, always-on VPN, and per-app routing; otherwise, the connection may be interrupted when Android reclaims the process after the screen is locked.
Go to downloadsiPhone and iPad use system network extensions to establish proxy connections, while installation and updates are managed through the App Store. The download page provides the Clash Plus store link and official site information; after importing a configuration, switch exits through its policy groups.
Go to downloadsDesktop distributions can use a graphical client, while servers, software routers, and containers are better suited to running the mihomo core directly. Before installation, confirm the CPU architecture, package format, service permissions, and the locations used to store configuration files and logs.
Go to downloadsFor ordinary desktop use, choose a maintained graphical client first, then download the package for your processor architecture. On mobile, verify the app store or package source before configuring background permissions. Direct management of the mihomo core, configuration files, and service process is only needed for servers, routers, or automated environments.
Rule mode does not simply send all traffic through one exit. The client checks rules from top to bottom and passes each connection to the specified policy group when the first match is found. Understanding match order, rule types, and the scope of network interception keeps configuration behavior explainable.
Domain rules are useful for websites, API hostnames, and content services. A configuration can match a full domain or a domain suffix, then send the request to Direct, Proxy, or a custom policy group. Compared with checking only the destination IP, domain rules better reflect the service users actually access and are easier to read and maintain.
Put more specific rules first and broader suffix rules later. For example, if one subdomain should connect directly while other requests under the same parent domain should use a proxy, place the full-domain rule first. Also check the DNS resolution path: if the domain is lost before reaching the core, matching may fall back to IP rules. Domain routing and DNS settings should therefore be reviewed together.
IP-CIDR rules evaluate the address range containing the destination IP. They are commonly used for local networks, reserved addresses, fixed server ranges, and connections that cannot be identified reliably by domain. They express a continuous range clearly, are easier to maintain than listing individual IPs, and help separate home networks, corporate intranets, and public traffic.
Verify the prefix length when configuring a rule. A range that is too broad may include addresses that should use a proxy, while one that is too narrow can leave connections unmatched. A rule with no-resolve generally avoids triggering DNS resolution during matching, reducing extra queries, provided the core already has the destination IP. When troubleshooting, check the destination address, matched rule, and final policy in the connection log instead of looking only at whether the webpage loads.
MATCH usually belongs at the end of the rule list and catches connections that matched nothing above it. It defines the configuration's default behavior: assigning a proxy policy group sends unknown traffic through a proxy by default, while DIRECT sends it directly. Because MATCH catches the remainder, placing it incorrectly prevents later rules from ever running.
A safer approach is to list local networks, system services, explicitly direct domains, and services that require a proxy first, then finish with MATCH. Before changing the default policy, check for apps that depend on the previous behavior, especially update services, local-device discovery, and corporate networks. If many connections only hit MATCH in the logs, earlier rules may not cover enough cases, or domain data or rule sets may not have loaded as expected.
TUN uses a virtual network interface to intercept more system traffic. It is useful for apps that ignore system proxy settings, some game launchers, command-line tools, and desktop environments that need unified routing. TUN determines whether traffic can enter the core; it does not replace DOMAIN, IP-CIDR, or MATCH. Once inside the core, connections still select policies according to rule order.
Before enabling it, confirm administrator permissions, routing tables, the DNS hijacking method, and conflicts with other VPN software. If local-network access fails, a routing loop appears, or wake-from-sleep recovery breaks, disable TUN first and verify the basic system proxy. Then check auto-route, strict-route, the DNS listener, and firewall settings one by one. If ordinary web proxying already works, there is no need to enable TUN simply to add more features.
Clash generally checks rules in the order they appear in the configuration and stops once a match succeeds. Rules are not evaluated simultaneously before choosing the “most specific” one, so order is part of the configuration logic. If a newly added rule has no effect, first check whether a broad rule earlier in the list is taking precedence.
Rules usually point to policy groups rather than binding each rule directly to a node. This lets you switch nodes, use automatic selection, or change exits without editing rule text. When maintaining a configuration, first identify the policy group matched by the rule, then check its current selection. This avoids confusing a rule problem with node connectivity.
When choosing a client, the interface name is only the first clue. The core in use, configuration compatibility, system integration, and maintenance status matter more. Understanding these relationships helps determine whether a tutorial's settings apply to the current client.
The Clash ecosystem has developed a widely used YAML configuration structure covering proxy nodes, policy groups, rules, DNS, and runtime parameters. After the original project stopped updating, community forks continued maintaining compatibility. mihomo preserves common configuration patterns while extending rule types, proxy protocols, DNS behavior, and TUN capabilities. In practice, follow the core built into or invoked by the client; a Clash label in the interface alone does not confirm feature support.
Graphical clients typically manage subscriptions, policy-group switching, system proxies, startup launch, log viewing, and core updates; the core actually establishes connections, matches rules, and forwards traffic. Because their roles differ, an interface that can import a configuration does not mean the current core supports every field. When a configuration fails, record the client version, core name, error line, and runtime log before deciding whether the issue is syntax, compatibility, or system permissions.
Source code, commit history, release notes, and issue discussions together provide traceable technical evidence for open-source projects. Users can see when a rule was added, whether default behavior changed, and whether a known issue was confirmed, while comparing the responsibilities of the client wrapper and the core itself. When explaining features, this site prioritizes configuration semantics, system networking mechanisms, and public maintenance information rather than unverifiable metrics such as download counts, ratings, or node speeds.
A client update may change the interface, replace the core, alter permissions, and migrate configuration at the same time. A stable maintenance process is to preserve a working configuration, record custom rules, read release notes, and check subscription refreshes, policy-group selection, DNS, and system proxy status after updating. If something breaks, restore a minimal configuration to verify basic connectivity, then add rule sets, scripts, or TUN settings step by step. This is easier to diagnose than changing several options at once.
Use these questions to quickly decide whether to visit the download page, guides, glossary, or full FAQ. For issues involving specific error logs, keep the original error and operation sequence before troubleshooting each item.
The client provides the visual interface and system integration; cores such as mihomo handle connections, rules, and traffic forwarding; YAML configuration files describe nodes, policy groups, rules, and DNS behavior. All three must be compatible for normal operation. See the glossary for more concepts.
A successful import only means the configuration reached the client. You still need to start the core, select a working policy, enable the system proxy or the appropriate interception method, and confirm that rules match the correct policy group. Follow the Getting Started guide to check the configuration, mode, connection, and verification steps in order.
Rule mode routes traffic according to the configuration and suits everyday use. Global mode sends most connections through one proxy policy and is useful for temporarily testing a node. Direct mode is mainly for confirming that the local network works. Changing modes will not fix a failed node or an invalid subscription; see the FAQ page for details.
If browsers and common desktop apps follow the system proxy normally, you can usually keep the current setup. Consider TUN only when an app ignores the system proxy, more protocols need interception, or unified routing is required. After enabling it, check routing, DNS, local-network access, and conflicts with other VPN software.
These articles cover core differences, Android network interception, and client interfaces by specific problem. They are useful for further reading after the basic installation is complete.
A guide to mihomo (Clash Meta) compatibility, extended rules, protocol support, and configuration migration, helping you decide whether an existing configuration can be reused as-is.
Read the full article →Explains how Android intercepts traffic and how to handle dropped connections after screen lock, background-process cleanup, and battery-saving restrictions.
Read the full article →Explains the practical purpose of policy-group switching, subscription updates, runtime logs, and basic settings across common interface sections.
Read the full article →