Clash Downloads for All Platforms
Client and Configuration Guides

Mihomo handles rules and connections

Mihomo is a widely used core in the Clash Meta ecosystem. It reads YAML configuration, establishes proxy connections, resolves DNS, matches rules, and applies the final policy. On Windows, macOS, and Linux, graphical clients are usually management layers: the proxy groups, rule providers, logs, and connection status shown in the interface are ultimately handled by the core. When choosing a client, confirm that it supports Mihomo rather than relying on the app name alone.

For everyday troubleshooting, separate the problem into two layers: the interface imports configuration, selects modes, and saves settings; the core handles subscription nodes, proxy groups, rule order, and network requests. If a configuration imports successfully but access still fails, check the core log and current mode first, then determine whether the issue is the subscription, DNS, or system permissions. This is more effective than repeatedly switching clients.

A subscription URL is only the entry point to a configuration

A subscription usually returns a configuration file containing nodes, proxy groups, rules, and DNS settings. Import the subscription URL supplied by your provider, confirm that the client reports a successful update, and then check that proxy groups and nodes appear in the configuration. Pasting a URL into an input field does not by itself mean the configuration is active; also verify the update time, node list, and logs.

When a subscription update fails, first confirm that the URL opens in a browser, then check the system clock, network proxy, and client permissions. If the response is a web page rather than a YAML or JSON configuration, you may have copied a management-page URL. After a successful update, reload the configuration and make sure the selected proxy group is not empty. Client support for subscription formats varies, so use the Clash or Mihomo format supplied by the provider when necessary.

Rule order determines where requests go

Rule-based routing matches rules from top to bottom. Common types include DOMAIN, DOMAIN-SUFFIX, DOMAIN-KEYWORD, IP-CIDR, and GEOIP, which evaluate domains, keywords, IP ranges, and geographic databases. Once a rule matches, it sends the request to DIRECT, a proxy group, or the REJECT policy. If no earlier rule matches, the final MATCH rule handles the remaining requests.

When troubleshooting routing, do not rely only on whether a page opens. Open the connection or log panel and inspect the target domain, matched rule, and final policy. The client may need a configuration reload after rule providers update. For LAN devices, services in mainland China, and domains that must always connect directly, add more specific rules before the fallback rule. The more specific a rule is, the earlier it should appear; MATCH usually belongs at the end.

rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

Rule, global, and direct modes serve different troubleshooting stages

Rule mode assigns a policy to each request according to the configuration file and is suited to long-term use. Global mode sends requests to the currently selected proxy group and is useful for verifying a node and its egress. Direct mode bypasses the proxy and helps test the local network or determine whether a problem comes from the proxy path. These are request-routing methods, not speed levels.

For an initial setup, use global mode to verify the client, node, and system proxy, then switch to rule mode to inspect routing results. If a site behaves unexpectedly in rule mode, temporarily use global mode for comparison. Restore rule mode afterward and check the proxy-group selection, DNS settings, and connection logs. Android and iOS may show an additional system authorization step; follow the current client’s instructions when a VPN or proxy permission request appears.

System proxy and TUN cover different traffic scopes

A system proxy usually affects browsers and apps that follow the operating system’s proxy settings. It is simple to configure, requires fewer permissions, and is a good first step on desktop systems. Some command-line tools, games, virtual machines, and apps that ignore system proxy settings will not use this path automatically. TUN captures a broader range of traffic through a virtual network interface, while Mihomo handles DNS and rule-based routing. It requires elevated system permissions and may conflict with other VPNs or network filters.

Before enabling TUN, disable other VPNs, confirm that the client has administrator or system-extension permission, and record the existing network settings. If the network goes offline, disable TUN first, restore the system proxy, and then inspect the core log. On desktop systems, start with the system proxy for basic validation, and consider TUN only after the rules and nodes work correctly. Mobile VPN services also require system authorization, and battery-saving policies may interrupt background connections.