Clash Rule-Based Routing for Mainland China and Overseas Traffic: Policy Groups, Rule Providers, and Fallback Order

Clash rule-based routing is not simply a matter of sending “domestic domains” direct and handing “overseas domains” to a proxy. The actual destination is determined by three layers: rules identify traffic, policy groups select an exit, and proxy nodes or built-in actions carry it out. If the name, order, or reference between any layer is inconsistent, websites may take the wrong route, LAN services may be proxied, applications may time out, or some connections may continue using an old path after a node switch.

The configuration approach below applies to Clash clients that support rule mode, as well as the core distributed under the Clash Meta name and now commonly known as mihomo. GUI labels vary by client, and core versions differ in supported rule types, rule-provider formats, and process matching. Before making changes, confirm which core the client actually uses and keep a configuration that is known to start successfully.

Define the DIRECT, PROXY, REJECT, and fallback model first

A maintainable routing setup for mainland China and overseas traffic should define at least four outcomes. The first is DIRECT, which hands the connection to the local network. The second is a custom proxy policy group, such as PROXY. The third is REJECT, which blocks domains or network ranges that should not be accessed. The fourth is the final fallback policy, which receives traffic not matched by any earlier rule.

DIRECT does not mean “mainland China.” LAN addresses, printers, router admin pages, and internal company systems usually need direct access, while some services in mainland China may require a proxy because of account regions, office egress, or testing requirements. Conversely, some overseas sites may be reachable directly from the current network. Geographic rules are best used for broad baseline decisions; business-specific exceptions should come before them.

Separate node selection from business intent with policy groups

Putting a single node name directly in a rule works, but it increases maintenance overhead. Subscription updates can rename nodes, and multiple rules may end up tied to the same specific node. A more resilient approach is to have rules reference semantically clear policy groups, while each group selects a node, an automatic latency-test group, or another policy group.

Common structures include a main entry group such as PROXY, an automatic latency-test group such as AUTO, a manual selection group, and service-specific groups for media, work, or development. Business rules point only to business policy groups; node changes happen inside those groups. This keeps rule files stable while still allowing temporary egress changes in the client UI.

mode: rule

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - AUTO
      - MANUAL
      - DIRECT

  - name: AUTO
    type: url-test
    use:
      - airport
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80

  - name: MANUAL
    type: select
    use:
      - airport

The airport in the example must already be defined under proxy-providers. use references a proxy provider, not a rule provider. url-test selects nodes based on test results, but the lowest latency does not necessarily deliver the highest throughput for every service. If a destination requires a particular egress region, create a regional group or manual selection group instead of relying solely on global latency testing.

Allowing PROXY to select DIRECT is useful for temporary diagnosis, but it also means that switching this group changes the egress for every rule that references it. For services that must always use a proxy, create a separate policy group without DIRECT. For traffic that must always go direct, point the rule straight to DIRECT so it is not affected by changes to the main policy group.

Use one consistent spelling for every policy group name

Names in YAML are matched character for character. If a rule uses PROXY while the policy group is named Proxy, they are not treated as the same target. Chinese names, spaces, and symbols are generally supported, but short uppercase English names are easier to inspect when moving between clients. If a name contains special characters, quote it and keep the spelling consistent across rules, policy groups, and script references.

How rule-provider subscriptions work with policy groups

rule-providers declares reusable rule sets. It serves a different purpose from node subscriptions: node subscriptions provide proxy server information, while rule providers supply domains, IP ranges, or classical rule entries. A rule provider does not select an egress by itself. It participates in connection decisions only when referenced through RULE-SET in rules, together with a target such as DIRECT, PROXY, or another policy.

rule-providers:
  reject-list:
    type: http
    behavior: domain
    format: yaml
    path: ./ruleset/reject.yaml
    url: https://example.com/rules/reject.yaml
    interval: 86400

  cn-domain:
    type: http
    behavior: domain
    format: yaml
    path: ./ruleset/cn-domain.yaml
    url: https://example.com/rules/cn-domain.yaml
    interval: 86400

  cn-ip:
    type: http
    behavior: ipcidr
    format: yaml
    path: ./ruleset/cn-ip.yaml
    url: https://example.com/rules/cn-ip.yaml
    interval: 86400

The sample URL only illustrates the field structure; use the original file URL supplied by the rule maintainer in a real configuration. path is the local cache location for the rule set, and the client must have write access to the corresponding directory. interval is usually measured in seconds; setting it to one day reduces unnecessary requests. Choose an update interval that matches the upstream maintenance schedule—checking more often does not improve matching accuracy.

behavior determines how entries in a rule set are interpreted. domain suits collections of domains and domain suffixes, ipcidr suits IPv4 and IPv6 network ranges, and classical can contain classical rules with types. The file content must match the declared behavior and format. Declaring a domain list as ipcidr, or reading a classical rule file as a plain domain collection, usually causes a parse failure or prevents the rules from matching.

Rule order: specific exceptions first, broad fallbacks last

Clash checks rules from top to bottom and immediately applies the policy from the first match. It does not compare every rule and then choose the “most specific” one. Rule design should therefore follow this principle: specific exceptions first, broad collections later, and the final fallback at the end.

A recommended baseline order is: explicit blocks, LAN and private addresses, services that must go direct, services that must use a proxy, mainland-China domain collections, mainland-China IP collections, other regional or proxy collections, and finally MATCH. Projects can adjust the categories, but a broad rule must not appear before an exception it is meant to cover.

rules:
  - RULE-SET,reject-list,REJECT
  - DOMAIN-SUFFIX,internal.example,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve

  - DOMAIN-SUFFIX,service-needs-proxy.example,PROXY
  - DOMAIN-SUFFIX,service-needs-direct.example,DIRECT

  - RULE-SET,cn-domain,DIRECT
  - RULE-SET,proxy-domain,PROXY
  - RULE-SET,cn-ip,DIRECT,no-resolve
  - GEOIP,CN,DIRECT,no-resolve

  - MATCH,PROXY

The business domains in the example illustrate ordering only; replace them with the domains you actually need to control. If a domain that must use a proxy also appears in the mainland-China domain provider, place the specific proxy rule before cn-domain or it will match the direct rule first. If a block rule is too broad, login endpoints, static assets, or CAPTCHA domains may be rejected before any later proxy rule is considered.

DOMAIN matches an exact domain, DOMAIN-SUFFIX matches the specified domain and its subdomains, and DOMAIN-KEYWORD checks only whether a keyword appears in the domain. Keyword rules cover a wide range and can easily catch unrelated sites with similar names, so exact domains, suffixes, or maintained rule providers are usually preferable.

IP-CIDR and GEOIP make IP-based decisions. Adding no-resolve prevents a rule from triggering extra resolution to obtain the destination IP, but it also means the rule participates only after the core already knows that IP. Whether to add this option should be verified against the DNS mode, connection metadata, and core behavior—not copied mechanically into every rule.

Should MATCH use DIRECT or PROXY?

The fallback target depends on the configuration goal. For the common model of direct access for mainland-China traffic and proxy access for everything else, use MATCH,PROXY; newly appearing domains not yet covered by a rule provider will enter the proxy policy first. If the environment should default to direct access and proxy only a small set of services, use MATCH,DIRECT, but ensure that all proxy-required rules are comprehensive. Neither model is universally better; the key question is which egress keeps unknown traffic within acceptable risk limits.

How DNS and TUN modes affect routing results

When the rule order is correct but access is still abnormal, inspect DNS. Domain requests, resolution results, and the actual connection may take different paths. If the system DNS returns an address affected by the network environment, the domain rule may match the intended policy while the subsequent connection still times out. With Clash’s built-in DNS, verify the relationship between nameserver, proxy-server-nameserver, fallback resolution, and rule-based routing, then use core logs to see which server handled each query.

In fake-ip mode, the core returns reserved addresses to applications and restores the destination domain from the mapping when the connection is made. This helps domain rules participate consistently, but some LAN devices, local domains, game platforms, or applications that require real IP addresses may need entries in fake-ip-filter. Do not expand the filter indefinitely: an overly broad scope sends more requests back to real-IP resolution and reduces the consistency of domain-based routing.

redir-host mode returns the real resolved address directly to the application, so its compatibility path differs from fake-ip. After switching modes, old DNS cache entries and existing connections may remain active. Disconnect the relevant applications before testing and clear the DNS cache according to the operating system. Refreshing a browser page alone does not necessarily rebuild the entire connection path.

TUN mode takes over more system traffic, but it does not change the basic top-to-bottom rule-matching logic. After TUN is enabled, applications that previously bypassed the system proxy may also enter Clash, increasing the number of matched connections. If an application exposes only a destination IP, domain rules may lack usable metadata. A core with sniffing support can recover host information from some HTTP or TLS traffic, but sniffing does not work for every protocol.

When browser routing works but a command-line tool or desktop app takes the wrong route, check in order whether the program enters the core, whether the TUN route is active, whether the domain is identified, and which rule ultimately matched. Do not judge the entire system only by the exit address shown on a webpage: different processes may use the system proxy, direct sockets, QUIC, or their own DNS.

Verify with connection logs instead of guessing from access results

Once routing is configured, the most effective validation method is to inspect the client’s connection panel or core logs. For each test, record the destination host, matched rule, selected policy group, actual node, and connection result. “It opens” alone does not prove the rule is correct: the destination may support direct access, use a cached or alternate domain, or already have a persistent connection.

1. Confirm that the configuration loaded. Check the configuration timestamp and core logs to rule out YAML indentation, misspelled fields, failed rule-provider downloads, or invalid policy-group references.
2. Use a fixed test policy. Temporarily select a known-good node for PROXY so an automatic latency-test group does not switch egress during testing.
3. Test LAN and private addresses. Confirm that the router admin page, LAN devices, and internal domains match DIRECT, and check that TUN has not incorrectly taken over reserved network ranges.
4. Test mainland-China domains and IPs. Check whether the match comes from a domain provider, an IP provider, or GEOIP. If the connection falls directly to MATCH, inspect the rule-provider contents or the domain-identification path.
5. Test forced-proxy exceptions. Confirm that the rule appears before broad mainland-China collections and actually matches the specified policy group instead of being intercepted by an earlier suffix rule.
6. Test an unknown domain. Choose a destination absent from your custom rules and confirm that MATCH receives it, validating the fallback policy.

Common symptoms and checks

For long-term maintenance, keep custom exceptions, public rule providers, and fallback rules managed separately. Custom exceptions are usually few, so place them in the main configuration with notes explaining their purpose. Let rule providers update public domain and IP collections, and keep the fallback policy fixed. When something breaks, you can quickly determine whether the change came from a local exception, a remote collection, or the egress policy.

Change one layer at a time. First verify that the policy group can connect, then verify that the rule provider loads, and only afterward adjust rule order. Changing DNS, TUN, rule providers, and policy groups simultaneously introduces too many variables into the logs. For more configuration fields and client operations, cross-check the advanced configuration guide and user guide step by step.