A focused collection of Clash client packages, mihomo core configuration, and YAML routing rules. Choose a graphical client for your operating system first, then follow the field reference to import a subscription, check DNS behavior, and verify which rules match.
Clash does not process requests through a single switch. It uses a chain made up of listeners, DNS, rule matching, proxy groups, and outbound connections. The index below breaks down that chain according to real configuration relationships, making it easier to see which layer a field belongs to and which requests a change may affect.
rules is an ordered list evaluated from top to bottom. Domains, IPs, process names, and rule sets can all serve as match conditions;
once a rule matches, the core sends the request to the proxy group, DIRECT, or
REJECT specified by that entry, and later entries are ignored. Specific domain rules therefore usually come first, while broad
GEOIP, GEOSITE, and final fallback rules belong at the end.
When troubleshooting a routing result, first check which rule actually matched the request, then inspect the proxy group it targets instead of immediately switching nodes.
Common discrepancies come from rule order, domain-suffix scope, stale rule sets, or DNS results that differ from what IP-based rules expect.
The configuration reference also covers the syntax and boundaries of DOMAIN, DOMAIN-SUFFIX,
IP-CIDR, MATCH, and other rules.
Proxy groups sit between rules and proxy nodes. A manual selection group suits scenarios that require a fixed exit; an automatic testing group chooses an available option according to the probe URL, interval, and tolerance configured; a failover group searches its members in order for a reachable outbound. A proxy group can also contain another proxy group, creating clear layers for regions, purposes, and switching methods while avoiding repeated node names in rule files.
When configuring a group, check type, member sources, health checks, and referenced names together. Strategy names in rules must match the names in
proxy-groups exactly; after a subscription update, groups that depend on fixed names may reference entries that no longer exist.
In most graphical clients, switching a group only changes its current selection and does not rewrite the original subscription.
The DNS module receives application queries, selects upstream servers, and passes domain results to subsequent rule evaluation. With
fake-ip enabled, the core first returns a mapped address from a reserved pool. After the application connects, the original domain is restored from that mapping,
preserving the information required by domain rules. Some LAN devices, connectivity checks, and programs that require real addresses can be exempted with
fake-ip-filter.
DNS failures usually require separating “the domain cannot be resolved” from “resolution succeeds but the connection fails.” Check the listener address, default resolver, the resolution path for proxy-server domains, encrypted DNS reachability, and whether the system is still sending queries through another interface. Changing only the upstream address may not help, because startup resolution, rule evaluation, and proxy chains may use different server sets.
Read DNS and Fake-IP terminology →Graphical clients typically store a remote subscription, a local configuration copy, and the current runtime configuration. Subscription updates fetch nodes and base policies published by the service provider; local overrides add DNS, rules, or interface settings; the runtime configuration is the final result handed to the core after merging. These are not the same file, and directly editing a cached copy may be undone by the next update.
When maintaining configuration, first determine which override methods the client supports, then choose a prepend, append, or field-level merge. YAML indentation must remain consistent; the client determines how duplicate keys are overridden, and array fields may be replaced rather than appended. If an import fails, validate the syntax with a minimal configuration first, then restore proxies, proxy groups, DNS, and rules section by section to locate incompatible fields faster.
Read about overrides and merging →The homepage provides platform entry points only. Package formats, client differences, system requirements, and maintenance status are listed together on the download page, keeping files for different architectures from being mixed in one place. Open the relevant tab, then choose a client based on your device architecture and intended use.
Designed for everyday desktop use, with options including Clash Plus, Clash Verge Rev, FlClash, and Clash Nyanpasu. After installation, confirm system proxy permissions; with UWP apps, also check whether loopback restrictions affect local proxy access.
Apple Silicon and Intel devices require packages for their respective architectures. On first launch, you may need to approve a network extension or proxy permission in System Settings; if the menu bar shows a connected state but requests do not pass through the core, check the system proxy and enhanced-mode settings.
Options include Clash Plus, Clash Meta for Android, FlClash, and Surfboard. After importing a subscription, Android will ask you to establish a VPN connection; battery-saving policies, background restrictions, and vendor network-management features may interrupt persistent connections and should be checked for the specific device.
iPhone and iPad users can get Clash Plus from the App Store. The first connection requires permission to add a VPN configuration; after importing a subscription, select a policy and start the connection. A VPN icon in the status bar only confirms that the tunnel is established; actual access still depends on rules and the outbound.
On desktop environments, use Clash Verge Rev or FlClash; servers, routers, and container environments typically deploy the mihomo core directly. When choosing a file, distinguish the package format from the CPU architecture, and configure service management, the working directory, and permission to read the configuration file yourself.
To decide whether a client fits your device, separate the graphical interface, proxy core, and configuration format into three layers. Different projects may maintain these layers, but they work together through similar configuration structures and control interfaces.
The Clash ecosystem established a widely used configuration model: proxy nodes are described by proxies, policy selection is organized by
proxy-groups, requests are matched in sequence through rules, and the DNS module handles resolution and domain mapping.
After the original Clash project stopped active development, community forks continued expanding compatible fields, with mihomo among the commonly maintained cores today.
As a result, many newer clients have different names but still operate around similar configuration structures, control interfaces, and rule semantics.
Clash Plus, Clash Verge Rev, FlClash, and other graphical clients mainly handle subscription management, configuration switching, system proxy control, log viewing, and core lifecycle management. The client’s built-in or invoked core performs DNS processing, rule matching, and outbound connections. When something fails, first determine whether the problem is in the interface or the core: an inability to save settings is client behavior, while configuration parsing failures usually involve fields or core compatibility; if a specific site uses the wrong exit after a connection is established, inspect the rules and proxy group.
Commit histories, releases, issue discussions, and configuration documentation in open-source repositories can be cross-checked. Rather than looking only at a client name, a more useful assessment is to confirm whether recent commits remain active, whether packages cover the current architecture, whether the core supports the fields used in the configuration, and whether major changes include migration notes. Clash Chinese Site distinguishes maintained and archived projects on its client comparison page, while the download page marks maintenance status directly on each card so you can choose before installing.
Client upgrades, core upgrades, and subscription updates are three different operations. A client upgrade may change the interface or override mechanism; a core upgrade may add or alter fields; a subscription update mainly replaces nodes and rules supplied by the service provider. Before making changes, export the currently working configuration and record the active policy mode, then update only one layer at a time. If parsing errors appear, restore the old configuration and correct fields one by one using the locations shown in the logs instead of replacing the client, core, and subscription simultaneously.
The questions below help with an initial assessment. For complete fields, client differences, or step-by-step troubleshooting, continue to the relevant help page rather than changing several settings without logs or configuration context.
Clash usually refers to the configuration model and its surrounding ecosystem; mihomo is one actively maintained compatible core; Clash Plus, Clash Verge Rev, FlClash, and similar products are graphical clients. Graphical clients handle configuration and system integration, while the core handles parsing, matching, and connections. See the terminology handbook for a fuller explanation of these layers.
First confirm that the underlying network works, then check whether the client has started the core, whether system proxy or VPN permissions are active, whether the proxy group has selected a usable outbound, whether DNS can resolve domains, and which rule ultimately matched the request. Do not change DNS, mode, and subscription all at once; checking one layer at a time preserves useful clues. See the full sequence in Help Center troubleshooting.
Rule mode determines each request’s destination from the configuration rules and suits regular use; global mode sends most requests to a selected policy, making it useful for temporarily testing the proxy chain; direct mode is mainly for confirming whether the proxy path is causing the issue. After troubleshooting, return to rule mode and use the logs to confirm that key domains match the expected policy.
A remote subscription update usually replaces the local cached copy. DNS, rule, or policy changes that must persist should go into an override file or merged configuration supported by the client, rather than directly into the subscription cache. Support for array appending, duplicate-key overrides, and script-based overrides varies by client; consult the overrides and merging chapter first.
For help locating installation, subscriptions, startup, Fake-IP, or UWP loopback issues, visit the Help Center for categorized answers →
Each article focuses on a specific task, with an emphasis on reproducible checking sequences, field boundaries, and platform differences. Start with the basic checks, then use the logs and configuration symptoms to open the relevant section.
Trace failed subscription imports step by step through link status, response content, YAML indentation, field compatibility, and local caches, distinguishing server-side response errors from client-side parsing problems.
Read the full article →A complete guide to getting the client on iPhone and iPad, importing configuration, authorizing the VPN, selecting a policy, and checking the first connection.
Read the full article →Distinguish latency tests from real-world usability, then choose nodes based on traffic multipliers, target regions, protocol characteristics, and stability over time.
Read the full article →