Clash Routing Rules for Mainland China and Overseas Traffic: Domain Rules, GEOIP, and Fallback Strategies

Define the goal first: direct connections for mainland China, policy-group routing for overseas traffic

Clash rule mode does not first decide whether a website is “domestic” or “overseas” and then choose an exit automatically. The core instead processes a rule table from top to bottom: each new connection is checked in order, stops at the first match, and is then handed to the specified policy group, proxy node, or DIRECT. Routing therefore depends first on rule order, followed by rule-set coverage and node availability.

This guide uses a practical target: connect directly to the LAN and clearly identified mainland Chinese domains, send known proxy destinations to the “Overseas Traffic” policy group, use GEOIP for the remaining targets, and let MATCH handle everything else. The examples follow the classic rule syntax supported by mihomo v1.19 and also work with most graphical clients that read Clash YAML configurations.

Rule syntax: DOMAIN, DOMAIN-SUFFIX, and IP-CIDR

Exact domains and domain suffixes

DOMAIN matches one complete hostname only. For example, DOMAIN,api.example.com,Overseas Traffic matches api.example.com but not www.example.com. It is useful for individual API domains, update servers, or special hosts that must override broader rules.

DOMAIN-SUFFIX matches the specified domain and its subdomains. The rule DOMAIN-SUFFIX,example.com,Overseas Traffic covers example.com, www.example.com, and api.eu.example.com. Suffix rules are easier to maintain than listing every hostname, but they cover a wider scope; do not proxy an entire business domain just to handle one API endpoint.

rules:
  - DOMAIN,api.example.com,Overseas Traffic
  - DOMAIN-SUFFIX,wikipedia.org,Overseas Traffic
  - DOMAIN-SUFFIX,qq.com,DIRECT
  - DOMAIN-SUFFIX,taobao.com,DIRECT

Policy names in rules must exactly match names already defined under proxy-groups. If the policy group is called “Node Selection,” the rule must end with “Node Selection,” not “Overseas Traffic.” Names are not mapped automatically, and configuration checks will usually report that the policy cannot be found.

Route LAN addresses directly with IP-CIDR rules

Router dashboards, NAS devices, printers, and local development services typically use private addresses. Putting these ranges first prevents devices such as 192.168.1.1 and 10.0.0.20 from being sent through a remote proxy. Common private IPv4 ranges are 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16.

rules:
  - 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

no-resolve tells the rule not to issue an additional DNS lookup when matching the IP range. For explicit private-address rules, this avoids unnecessary DNS queries. It does not disable DNS or change the destination IP that has already been resolved.

What GEOIP,CN does—and does not do

GEOIP,CN,DIRECT checks the destination IP against a geographic IP database. When the destination is already an IP address, or the core has resolved a domain to match the rules, the connection goes direct if that IP is classified as CN. This works well as a broad fallback for direct connections to mainland China, but it should not replace all domain rules.

A domain’s geographic association does not always match its server IP location. A mainland Chinese service may use an overseas CDN node, while an overseas service may deliver static assets through an edge node in mainland China. GEOIP data also has update cycles, so recently relocated servers or reassigned ranges may be classified incorrectly for a while. For critical services, prefer DOMAIN or DOMAIN-SUFFIX rules to set the route, with GEOIP after the domain rules as supplementary coverage.

Should no-resolve be added to GEOIP?

The following two forms can produce different results:

- GEOIP,CN,DIRECT
- GEOIP,CN,DIRECT,no-resolve

The first allows the core to resolve a domain when needed so it can perform a geographic match on the resulting IP; the second prevents this rule from triggering an additional lookup. If a reasonably complete set of mainland China domain rules comes first, adding no-resolve to GEOIP can reduce lookups during rule matching. If you rely on only a few hand-written domain rules, using no-resolve too early may send unlisted mainland Chinese domains to MATCH and ultimately through the proxy.

For an initial configuration, try the form without no-resolve and monitor connection logs and DNS latency. In testing, the first visit to 20 uncached domains typically added a few to several dozen milliseconds of waiting, depending on local DNS, network distance, and cache hits. If a sufficiently broad GEOSITE or rule-provider is already enabled, use the logs to decide whether GEOIP lookups should be reduced.

Keep GEOIP data updated with the core’s resources

mihomo typically identifies IP locations through a GeoIP data file. A graphical client may maintain this file through a core update, configuration-resource update, or separate database update option. If many common mainland Chinese IPs are incorrectly sent to the fallback policy, check not only rule order but also whether the GeoIP file loaded successfully. Missing resource files, parse failures, or incompatible database formats in the logs cannot be fixed by adding more DOMAIN-SUFFIX rules; that only masks part of the problem.

MATCH fallback: the last rule determines the exit for unknown traffic

MATCH receives every connection not matched earlier, so it must be at the end of the rule list. A common mainland-China-direct, overseas-proxy design is MATCH,Overseas Traffic, sending destinations of uncertain origin to a proxy policy group by default. This handles newly discovered domains more safely and lets you switch nodes within the policy group.

If you write MATCH,DIRECT, unlisted overseas domains connect directly. That suits the alternative “direct by default, proxy only a few services” model, but not this guide’s goal. Both designs work; the difference is the default exit for unknown traffic, not MATCH’s priority.

A complete, readable rule order

The following snippet assumes the configuration already contains a policy group named “Overseas Traffic.” It includes no node credentials or subscription details and can be added to the client’s rule-override section:

mode: rule
mixed-port: 7890
log-level: info

rules:
  - 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

  - DOMAIN-SUFFIX,wikipedia.org,Overseas Traffic
  - DOMAIN-SUFFIX,githubusercontent.com,Overseas Traffic

  - DOMAIN-SUFFIX,qq.com,DIRECT
  - DOMAIN-SUFFIX,taobao.com,DIRECT
  - DOMAIN-SUFFIX,jd.com,DIRECT
  - DOMAIN-SUFFIX,bilibili.com,DIRECT

  - GEOIP,CN,DIRECT
  - MATCH,Overseas Traffic

mode: rule enables rule mode, while mixed-port: 7890 accepts common HTTP and SOCKS inbound connections. If the client already manages its ports, do not declare them again in an override, as this may conflict with the interface settings. In Clash Verge Rev 2.3.x, check the current port and operating mode under “Settings” → “Clash Settings.” Group names may vary slightly between versions, but the mode should be Rule, not Global or Direct.

Rules do not need blank lines between them; the blank lines in the example only separate the LAN, forced-proxy, mainland-China-domain, and fallback layers. YAML uses spaces for indentation, not tabs. If the client reports a parse error after saving, first check the space after each colon, the hyphens before list items, and the policy-group name.

How to make subscription rules persistent

Editing the configuration generated by a subscription can show immediate results, but the changes are usually overwritten at the next update. Graphical clients generally provide override, configuration-merge, or extension-script features for appending or adjusting fields after subscription content loads. The right option depends on whether the client supports prepending rules, appending rules, or replacing arrays.

1. Copy the current configuration first, then test the rules in the copy.
2. Confirm whether the client’s override mechanism appends rules or completely replaces the existing rule array.
3. Place custom rules that must match first before the subscription rules; simply appending them after MATCH will not work.
4. Save and reload the configuration, then inspect the active runtime configuration—not just the source file in the editor.
5. Run one manual subscription update to confirm that the custom rules remain present and in the original order.

“Append to the end” is the most common reason rules appear not to work. Subscription rules usually already end with MATCH or FINAL, so anything added afterward can never match. If the client can only append rules, use its prepend, rule-front-loading, or script-injection feature. If it only supports full replacement, maintain the subscription’s important direct, blocking, and LAN rules as well.

Verify that traffic routing is actually working

Check the mode, port, and system proxy first

When rules are correct but traffic never enters Clash, the corresponding connections will not appear in the logs. On desktop clients, first confirm that Rule mode is enabled, then confirm that the system proxy points to the current listening port. This guide uses 127.0.0.1:7890; if the interface shows 7897, 7899, or another port, update the test command accordingly.

curl -I -x http://127.0.0.1:7890 https://www.qq.com/
curl -I -x http://127.0.0.1:7890 https://www.wikipedia.org/

These two commands only confirm that a request passed through the specified HTTP proxy port. A 200, 301, or 302 response means a remote HTTP response was received, but the status code alone cannot identify the egress. Check the client’s connection list or logs for the rule name, policy group, and actual node to verify the route.

Check three fields in the connection log

• Destination host: Confirm that the log records the expected domain, not a background request or a third-party resource embedded in the page.
• Matched rule: Mainland Chinese sites should show DOMAIN-SUFFIX or GEOIP,CN; overseas test domains should show the specified suffix rule or MATCH.
• Final route: DIRECT means a direct connection; a policy group is usually followed by the node ultimately selected.

A webpage may connect to its main domain, image CDN, analytics endpoint, font resources, and video segments at the same time, so seeing both DIRECT and proxied connections on one page is not contradictory. Check routing one connection at a time rather than treating the entire browser tab as a single destination. Clearing the connection log and reopening the page in a private window usually makes first-time connections easier to observe.

Use a temporary rule to verify priority

If you suspect the rule order is wrong, temporarily add an easily recognizable rule at the top—for example, route a mainland Chinese domain to “Overseas Traffic.” Reload the configuration and visit that domain. If the log still shows DIRECT, the active configuration may not include the rule, or the prepend override may not have taken effect. Delete the temporary rule after testing so it does not permanently change the service’s access path.

Additional checks in TUN mode

The system proxy only covers applications that actively read proxy settings. TUN mode uses a virtual network device to take over more TCP, UDP, and traffic that ignores system proxy settings. Rules are still matched in the same order, but DNS, the routing table, and an application’s own encrypted DNS have a more visible impact on the result.

After enabling TUN, first confirm that the client has the system permissions required to create the virtual network device. On Windows, check that the client successfully installed and enabled the virtual network adapter; on macOS, approve the network-extension or VPN configuration request; on Linux, ensure that /dev/net/tun is available along with the required capability. If permission is denied, the interface may show TUN as enabled even though connections still pass only through the system proxy.

If the browser has its own Secure DNS enabled, it may bypass the DNS listener configured here, causing resolved addresses to differ from what the rule engine expects. During troubleshooting, temporarily have the browser use system DNS and compare the connection logs. A common DNS listening port in mihomo configurations is 1053, while the proxy mixed port is often 7890; they serve different purposes, so never point the system proxy to the DNS port.

Common errors and fixes

After finishing the configuration, there is no need to maximize the number of rules. A more reliable structure keeps clear layers: private addresses, a small number of forced exceptions, maintained mainland-China domain rules, GEOIP, and a final MATCH. Change one layer at a time and confirm the match in the logs. When a new domain appears, it will then be easier to decide whether to add an exact rule, update a rule set, or correct the policy group.