Clash Traffic Routing Rules: YAML Configuration for Mainland China and Overseas Traffic

Define the direct-routing model for mainland China and proxy routing for overseas traffic

Clash rule mode does not evaluate every rule at once. It checks connection information from top to bottom and stops as soon as the first matching rule is found. For mainland China and overseas traffic, the result depends on three things: what the rules can identify, which policy group receives a match, and which rule handles traffic that matches nothing.

A maintainable baseline model usually has four layers. The first handles LAN addresses, loopback addresses, and local services, preventing access to routers, printers, network storage, or development environments from being sent through a proxy. The second contains domains that need explicit handling, such as internal company domains, download sites, or specific application APIs. The third uses domain sets and IP geolocation data to handle broader regional traffic. The fourth uses MATCH to catch connections not identified earlier.

1. LAN and private addresses: Send them to DIRECT to preserve normal communication between local devices.
2. Explicit domain rules: Route directly, through a proxy, or reject traffic according to the actual requirement; these rules take priority over regional rules.
3. Mainland China traffic: Identify it with domain rule sets, GEOIP, or mihomo's GEOSITE.
4. Unmatched traffic: Usually send it to an overseas policy group instead of hard-coding a single proxy node.

Here, “local” refers to two different things: private addresses inside the LAN and public internet traffic in mainland China that should use a direct connection. The former can be identified reliably with fixed subnets; the latter may be identifiable only by domain, or may ultimately connect to a CDN address. That is why domain and IP checks often need to be combined.

Policy groups choose the route; rules only send traffic there

The target field at the end of a rule can be DIRECT, REJECT, or a policy group name. For long-term use, route overseas traffic to a policy group rather than directly to a proxy node. Node names may change when a subscription is updated, while policy group names can remain stable, so the rules do not need repeated edits.

The following snippet shows three commonly used policy groups. “Overseas Traffic” is the user-facing entry point, allowing manual selection of an automatic test group or a direct connection. “Auto Select” periodically tests candidate nodes, while “Fallback Traffic” handles connections that match no regional rule. The example assumes the subscription already contains a proxy provider named airport; replace it with the provider name in the current configuration.

proxy-groups:
  - name: Overseas Traffic
    type: select
    proxies:
      - Auto Select
      - DIRECT

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

  - name: Fallback Traffic
    type: select
    proxies:
      - Overseas Traffic
      - DIRECT

A select group does not change the current selection automatically, making it suitable when you need stable control over the route. url-test selects the fastest-responding candidate based on test results, but test latency reflects only the test URL and does not equal actual download speeds for every website. On frequently changing mobile networks, consider increasing interval to reduce repeated tests.

When nodes are listed directly under proxies, their names must exactly match the subscription configuration, including spaces and capitalization. With use, the name must correspond to a key under proxy-providers. Choose either source according to the client and kernel capabilities, but do not place a provider name in the ordinary node list by mistake.

Rule order: specific conditions first, regional checks and fallback last

Clash uses first-match processing, so the same domain may satisfy several rules. For example, files.example.cn matches both a full-domain rule and DOMAIN-SUFFIX,example.cn; the rule that wins is simply the one listed first. A practical order is “exceptions, application rules, domain-based regional rules, IP-based regional rules, final fallback.”

DOMAIN-KEYWORD has a broad scope. A keyword that is too short may match domains with similar names but completely different purposes. When a full domain or suffix can express the condition, prefer the more precise rule. Process rules also require caution: PROCESS-NAME depends on the operating system and kernel to obtain process information, so identification may vary across platforms, containers, or setups using only a standard system proxy.

MATCH must be at the end of the rule list. If it appears in the middle, rules after it will never run. For a setup where mainland China traffic uses a direct connection and everything else uses a proxy, the final rule is typically MATCH,Fallback Traffic, giving new domains, addresses without geolocation data, and otherwise unclassified connections a defined route.

YAML rules for mainland China and overseas traffic

The following is a conservative rule example. It first sends loopback addresses and common private subnets directly, then handles specified domains, attempts direct routing for mainland China domains and IPs, and sends the remaining traffic to a policy group. This snippet suits common Clash Meta (mihomo) configurations. With an older original Clash kernel, check whether the client supports GEOSITE; if not, replace it with a compatible rule-provider domain rule set.

rules:
  - DOMAIN,router.local,DIRECT
  - DOMAIN-SUFFIX,local,DIRECT
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR6,::1/128,DIRECT,no-resolve
  - IP-CIDR6,fc00::/7,DIRECT,no-resolve

  - DOMAIN-SUFFIX,example.cn,DIRECT
  - DOMAIN,api.example.net,Overseas Traffic

  - GEOSITE,CN,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,Fallback Traffic

Why no-resolve is often placed at the end of IP rules

When matching reaches an IP-based rule and the connection contains only a domain, some implementations may resolve the domain to obtain its destination IP. Adding no-resolve tells that rule not to trigger an extra DNS lookup solely for matching. This reduces queries during rule evaluation and can avoid additional wait time caused by different resolution paths.

However, no-resolve does not mean Clash ignores DNS entirely. The connection still needs to process the domain according to the active DNS mode. It only constrains matching behavior for the corresponding IP rule. In Fake-IP mode, the domain is usually mapped to a reserved address; the kernel can retain the domain information and apply domain rules, then resolve the destination according to the configuration when the connection is established.

Can GEOIP,CN,DIRECT cover every mainland China website?

GEOIP should not be treated as the only source of truth. Websites may use global CDNs, cloud services, or cross-region routing, so the same domain can return different addresses on different networks. Some mainland China services may also use overseas addresses, while overseas services may deploy nodes in mainland China. Domain rules should therefore generally come before GEOIP: classify known services by domain first, then use IP geolocation to supplement the remaining connections.

Geolocation databases need to be updated together with the kernel or client. If a database is outdated, newly allocated address ranges may be assigned to the wrong region. When the same website uses different policies on different devices, compare not only the YAML but also the GeoIP and GeoSite data versions and the DNS responses.

Manage large domain lists with rule-provider

As the rule count grows, avoid placing thousands of domains directly in the main configuration's rules section. mihomo and Clash clients that support rule providers can load separate rule files through rule-providers, then reference them in the rule list with RULE-SET. Keep priority in the main configuration and maintain the individual entries in the rule files.

rule-providers:
  regional-direct:
    type: http
    behavior: domain
    format: yaml
    path: ./ruleset/regional-direct.yaml
    url: https://rules.example.net/regional-direct.yaml
    interval: 86400

rules:
  - RULE-SET,regional-direct,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,Fallback Traffic

behavior: domain suits rule sets containing only domain entries; use classical when the file contains complete rule syntax; pure IP subnets can use ipcidr. The file content must match the selected behavior, or loading may fail and entries may not match. Remote rule sets also need a local path so the client can cache downloaded results.

How DNS, system proxies, and TUN mode affect routing results

Even with correct rules, the actual connection path depends on how traffic is intercepted. With a system proxy enabled, only applications that follow system proxy settings usually enter Clash; some games, command-line tools, virtual machines, or applications that create connections directly may bypass it. TUN mode lets the kernel intercept a broader range of IP traffic, so the same rules may appear to “match more connections.”

TUN mode is not a replacement for regional rules. It determines how traffic enters the kernel; rules determine which path it takes afterward. If an application's traffic never passes through Clash, changing GEOIP, MATCH, or policy groups will not change the result. During troubleshooting, first confirm in the connection panel that the target connection appears, then check which rule it matched.

DNS can change what you observe as well. With redir-host, rule matching may depend more heavily on the actual resolved address; with Fake-IP, the kernel can retain the domain context earlier, so domain rules generally apply more easily. For LAN device names, printer domains, internal corporate resolution, and applications that rely on real IP addresses, add the relevant domains to the Fake-IP filter list, then add direct rules as needed.

If IPv6 is enabled while the rules cover only IPv4 private subnets, LAN IPv6 connections may fall through to the final proxy policy. Add IP-CIDR6 rules for the network environment and confirm that the selected proxy nodes support the required IPv6 connectivity. Disabling IPv6 may temporarily change the symptom, but it is better used as a diagnostic step than as a permanent solution for every environment.

Configuration validation: from syntax checks to rule-match logs

YAML is sensitive to indentation. Spaces before list items, spaces after colons, and quoted names can all affect loading. Policy group names containing Chinese characters or spaces are usually valid, but the rule target must match the policy group name exactly. After editing, use the client's configuration checker first; when running mihomo from the command line, you can also test the configuration directory.

mihomo -t -d /etc/mihomo

A successful test only confirms that the configuration can be parsed; it does not prove that every rule behaves as expected. Validate it in this order:

1. Reload the configuration and confirm that the policy groups appear and that the proxy providers and rule sets update without errors.
2. Visit the router management address or a LAN device and confirm that the connection log shows DIRECT.
3. Visit a site explicitly covered by a domain rule and check the matched rule name and target policy.
4. Visit a commonly used mainland China website and observe separately whether the domain rule and GEOIP rule take effect.
5. Visit an overseas site covered by no explicit rule and confirm that MATCH sends it to “Fallback Traffic.”
6. Switch the node selected under “Overseas Traffic,” start the connection again, and confirm that the policy group selection affects the new connection.

Create a new connection during testing. Existing TCP, QUIC, or long-lived connections may continue using their previous route and will not migrate immediately after a policy group switch. Close the relevant tab or application connection and visit again for a more reliable result. Browsers may also cache DNS or reuse connections; if necessary, close old connections from the client's connection panel.

Rule names in the logs are more useful for diagnosis than whether a webpage opens. A failed page load can result from the node, DNS, TLS, destination server, or network path. Only after confirming the matched rule and target policy can you determine whether the problem lies in the rule layer or the proxy path.

Common routing anomalies and troubleshooting order

A mainland China website is sent through the proxy

First check the destination host and matched rule in the connection log. If it directly matches MATCH, the earlier domain sets and GEOIP rules do not cover it. Add a DOMAIN-SUFFIX rule for a stable domain or update the GeoSite and GeoIP data. If the log shows only an IP address, check the DNS mode, whether the application connects directly by IP, and the domain-sniffing settings.

An overseas website uses a direct connection

Look for an overly broad direct rule, such as a very short DOMAIN-KEYWORD, an incorrect domain suffix, or an early MATCH,DIRECT. Also confirm that the policy group has not been manually set to DIRECT. Matching “Overseas Traffic” does not necessarily mean a proxy is being used, because that group may still have direct routing selected internally.

A LAN device cannot be reached

Confirm that private-subnet rules appear before the final fallback and check which address ranges the LAN actually uses. Many home networks use 192.168.0.0/16, but office networks, virtual networks, and containers may use 10.0.0.0/8 or 172.16.0.0/12. When accessing devices by name, also ensure that local DNS, mDNS, or the search domain is not being disrupted by remote resolution.

Custom rules disappear after a subscription update

When you edit the main configuration generated from a subscription, a subscription refresh will usually rewrite the file. Move custom content into the client's supported override, Merge, or script configuration; alternatively, place stable rules in a rule-provider you maintain. A recommended update sequence is: update subscription nodes first, load overrides second, then update rule sets and run a configuration check.

The rules are correct, but the application has no connection log

This is usually not a rule-order problem; the traffic has not entered Clash. Check whether the system proxy is enabled, whether the application follows proxy settings, whether the terminal has proxy environment variables configured, and whether TUN mode started successfully. With TUN, also check route conflicts, permissions, other VPN software, and virtual network interface status. Get the connection to appear in the panel before analyzing its matched rule.

Final checklist for a maintainable configuration

• LAN and loopback rules come before regional rules.
• Specific domain rules come before broad keyword and GEOIP rules.
• Rules reference stable policy groups rather than node names that may change.
• MATCH appears only at the end of the rule list and points to a clearly defined fallback policy.
• The behavior and content format match for both domain and IP rule sets.
• IPv4, IPv6, DNS mode, and traffic interception match the current network environment.
• Subscription content is separated from personal overrides, allowing syntax and match tests to run again after updates.

There is no permanent regional-routing rule set that works for every network. A more reliable approach is to build a clear four-layer structure first, then add a small number of exceptions based on connection logs. As long as policy group names remain stable, rule order stays readable, and fallback behavior is explicit, the configuration remains relatively easy to maintain even as subscription nodes and geolocation data change.