OPEN SOURCE · CLIENT AND CONFIGURATION
Choose a maintainable Clash client for your device, then use routing rules, proxy groups, and configuration guides to import subscriptions, set up the system proxy, and troubleshoot connections.
PLATFORM CONNECTORS
Confirm your device's operating system first. On the download page, check the processor architecture, maintenance status, and package type. The homepage links only identify the right platform; they do not distribute installation files directly.
Built for everyday desktop use. The download page includes Clash Plus, Clash Verge Rev, FlClash, Clash Nyanpasu, and an archived Clash for Windows entry for migrating legacy configurations. Before installing, check your Windows version and processor architecture in System Settings. Most users should choose a maintained graphical client that supports Mihomo.
On macOS, distinguish between Intel and Apple Silicon builds. Graphical clients can manage the system proxy, rule mode, and subscription updates; when launching one for the first time, follow the system prompts to grant permissions. The legacy ClashX Meta build is intended only for migrating existing workflows, so new installations should use a currently maintained client.
Suitable for phones and tablets. Packages are usually separated into ARM64, ARM, and universal builds, with ARM64 used by most recent devices. After importing a subscription, allow the client to create a local VPN interface. Battery-saving features may stop background connections, so check battery optimization settings for sustained use.
Install Clash Plus from the App Store and use the system's VPN configuration capability to route connections that require a proxy. Confirm that the subscription is trusted before importing it. If the same configuration is used on multiple devices, import it separately and check proxy group selections on each device instead of reusing nodes that may not suit the current network.
On desktop systems, choose Clash Verge Rev or FlClash; servers, soft routers, and container environments typically run the Mihomo core directly. Running the core requires you to manage configuration paths, service supervision, file permissions, and the control port yourself, so users new to Clash should start with a graphical client.
CONFIGURATION BUS
A configuration is not a collection of unrelated switches. Connections enter through a network interface, pass through DNS resolution, rule matching, and proxy group selection, and are then handled by the chosen exit. The five structures below are explained by responsibility.
The rule engine uses domains, IPs, processes, or rule sets to determine which proxy group should handle a connection. Rules are matched from top to bottom, and a match usually ends evaluation, so specific domain rules should come before broad rules. MATCH handles connections that matched nothing earlier. When troubleshooting incorrect routing, first confirm that rule mode is enabled, then check rule order, rule-set loading status, and the name of the proxy group ultimately selected.
Unlike proxy tools that offer only a global on/off switch, Clash can define direct, proxied, and blocked behavior in one rule chain. Rules do not select a specific node; they pass traffic to a proxy group. This separation keeps rule sets reusable while allowing exit nodes to be switched independently as network conditions change.
rules:
- DOMAIN-SUFFIX,example.cn,DIRECT
- GEOIP,CN,DIRECT
- MATCH,PROXYProxy groups sit between rules and nodes. select is suited to manual exit selection, url-test can choose automatically from test results, fallback checks availability in order, and load-balance distributes traffic across multiple exits. Choose the group type according to reliability requirements rather than swapping similarly named types. The test URL, interval, and timeout also affect switching behavior.
Have application rules reference stable proxy group names instead of individual node names. When subscription updates add or remove nodes, you only need to adjust the group members rather than rewrite the entire rule set. When merging multiple subscriptions, avoid duplicate node names and confirm that the providers referenced by proxy groups have finished loading.
proxy-groups:
- name: PROXY
type: select
proxies:
- AUTO
- DIRECTDNS settings determine how domains are resolved, which server receives queries, and how the results interact with the rule engine. With Fake-IP enabled, the client returns a reserved address first and stores the domain mapping, allowing later connections to continue matching domain rules. Redir-Host follows a more traditional resolution flow. If a website resolves incorrectly, check in order whether the system DNS is being intercepted, whether the upstream server is reachable, whether the enhanced mode fits the network, and whether the filter list covers local domains.
DNS leaks, poisoning, and query loops often occur when multiple software layers intercept DNS at once. Decide whether the system, client, or router owns the entry-point resolution, and avoid sending DNS upstreams that require proxy access through a direct connection by mistake.
dns:
enable: true
enhanced-mode: fake-ip
nameserver:
- 1.1.1.1TUN mode creates a virtual network interface so applications that do not read system proxy settings can enter Clash's processing chain. It is useful for command-line tools, some game launchers, and software with an independent network stack, but it also makes routing, DNS, and permission settings more complex. Before enabling it on desktop systems, confirm that the client has the required permissions and check whether another VPN, security tool, or virtual network adapter is using the same route.
If enabling TUN cuts off all network access, do not immediately keep switching nodes. A better sequence is to disable TUN and restore a baseline, then check the stack type, auto-route, DNS hijacking, and firewall rules. Only when the system proxy works but a specific application bypasses it should you determine whether TUN is necessary.
tun:
enable: true
stack: mixed
auto-route: true
auto-detect-interface: trueThe external control interface lets desktop clients and dashboards read proxy groups, connections, and logs, and switch policies. It usually needs to listen only on the local address. If you expose it to the LAN, also configure an access key and restrict the firewall scope. A dashboard is only a management entry point; actual traffic is still handled by the Clash or Mihomo core. A dashboard that will not open and a failed proxy chain are separate problems, so check the static page, control port, and core process independently.
Do not expose the control port directly for remote administration. A safer approach is to use a controlled network or a reverse proxy with access control for the dashboard, while limiting which sources can reach the interface. After changing the control address, update the connection settings in the client's dashboard as well.
external-controller: 127.0.0.1:9090
secret: "your-password"OPEN SOURCE TRACE
Clash clients, cores, and configuration formats are maintained across multiple projects. Understanding each layer's responsibility is more useful for migration and troubleshooting than memorizing a single client name.
Clash established a configuration foundation around a rule-driven proxy model: listening ports, proxy nodes, proxy groups, rules, and DNS form a single processing chain. As the original project's maintenance status changed, community clients and compatible cores continued to evolve. When choosing a client today, do not judge compatibility solely by whether its name contains Clash. Check its maintenance status, core type, operating system support, and configuration compatibility instead.
Legacy clients such as Clash for Windows may still appear in older guides and on existing devices, but unmaintained software is not a suitable default for new installations. Before migrating, export or save the original configuration, then verify the new client's support for the subscription format, scripting features, and override behavior. Do not assume client-specific fields are universal core fields.
Graphical clients handle installation, subscription management, system proxy toggles, log display, and proxy group controls. Compatible cores such as Mihomo parse configuration, create listening ports, and execute rules. Subscription services provide nodes and policy content. These layers can work together, but failures occur at different points. A client interface opening does not mean the core has started, and a running core does not mean the subscription's nodes are currently available.
Troubleshoot layer by layer: confirm the local network and system time, then verify the subscription response and configuration parsing, followed by core logs, proxy mode, policy selection, DNS, and the system firewall. Layered troubleshooting avoids repeatedly reinstalling a client when nodes are unavailable and prevents configuration syntax errors from being mistaken for system network failures.
Mihomo preserves the Clash configuration model while extending support for rule providers, proxy providers, DNS, TUN, traffic sniffing, and control interfaces. Most modern graphical clients package core downloads and startup, so ordinary users usually do not need to run a binary manually. Server, router, and container users must manage configuration directories, runtime permissions, service supervision, and log rotation themselves.
Configuration migration is not just a matter of whether the YAML parses. Some fields depend on a particular core version or client override logic, and the same subscription may behave differently across clients because of default DNS, TUN stack, and system proxy settings. After migrating, separately verify direct-access sites, proxied sites, domain resolution, and whether the system proxy is restored after the application exits.
Client, core, and subscription updates solve different problems. A client upgrade typically changes the interface, system integration, or core management; a core upgrade may add configuration fields or fix network behavior; a subscription update changes nodes, proxy groups, and rules. When something goes wrong, record which layer changed most recently before deciding whether to roll back the configuration, switch nodes, or reinstall the client.
Keep the last working configuration before updating, and record the system proxy, TUN, DNS, and override settings. Afterward, do not judge the result by latency tests alone. Check that proxy groups are complete, rule providers have loaded, logs contain no parsing errors, and browsers and applications that ignore the system proxy each behave as expected.
QUICK DIAGNOSTICS
These answers establish a troubleshooting order. For complete steps, open Troubleshooting or the user guides.
For a new installation, choose a maintained client that supports your operating system and uses a compatible core. Windows users can compare Clash Plus, Clash Verge Rev, FlClash, and Clash Nyanpasu. When migrating an old configuration, save the subscription URL and local overrides first, then verify the system proxy, proxy groups, DNS, and TUN settings one by one. See the client comparison for details.
First check whether the subscription request succeeded, then confirm that the response can be parsed by the current client. If the log reports YAML syntax, field-type, or proxy group reference errors, fix the configuration first. If the subscription content is valid but the list has not refreshed, pull it again and check whether the client is using an old cache. Do not repeatedly switch proxy modes before confirming the parsing result.
Disable the system proxy first to confirm that the local network itself works. Then check whether the core is running, the node is reachable, and the current mode and proxy group are correct. If the browser cannot connect, also check DNS. Only when a specific application bypasses the proxy should you determine whether it ignores the system proxy and requires TUN. See Troubleshooting for the complete process.
Rule mode decides whether traffic is direct, proxied, or blocked one rule at a time. Global mode usually sends connections to a single proxy group and is useful for briefly testing the node chain. Direct mode bypasses proxy exits and helps confirm whether the proxy chain is the source of the problem. Rule mode is generally best for daily use; global mode is better as a short-term diagnostic tool than as a permanent replacement for rule configuration.
TECHNICAL NOTES
Reusable checklists for node connections, subscription parsing, and client selection. The articles focus on configuration layers and practical workflows rather than unreproducible performance figures.
Trace connection timeouts through the local network, subscription status, node availability, proxy mode, DNS, and the system firewall—in that order—before reinstalling the client.
Read the full article →Distinguish an expired subscription URL from an invalid response, malformed configuration, or client cache issue, then use the request result and core logs to identify the failing layer.
Read the full article →Compare popular clients by platform coverage, core support, configuration capabilities, and maintenance status, with separate selection criteria for desktop, mobile, and server environments.
Read the full article →