Clash Rules in Practice: Route Mainland China Traffic Directly and International Traffic Through a Proxy

1. Check the rule mode and traffic path first

Routing mainland China traffic directly and international traffic through a proxy requires three things: requests must reach the client, rule mode must be active, and the rules must point to valid outbound connections. Editing rules won't test routing if the client is in global mode. Rules also won't apply if your browser isn't using the proxy.

FlClash uses the mihomo core. This guide follows mihomo rule syntax and does not assume that older Clash versions and the current core use identical databases. Back up your current configuration first, then check the following:

1. Correct configuration selected: In the configuration list, confirm which subscription or local configuration is active. Don't edit an inactive copy.
2. Rule mode enabled: Rule mode in the interface corresponds to mode: rule in the configuration. Global and direct modes don't route traffic through the rule chain below.
3. Requests reach the core: With the system proxy, apps must support and honor the system proxy setting. With TUN, check that the virtual network interface is running and that routes are capturing the intended traffic.
4. Proxy outbound is available: The target proxy group must exist and have a working proxy selected. A rule match doesn't guarantee that the upstream connection will succeed.

2. Rules are checked top to bottom; the first match wins

A common rule format is “type, match value, policy,” such as DOMAIN-SUFFIX,github.com,PROXY. The core checks rules in order. Once a rule matches, it generally determines the policy for that connection; later, more specific rules aren't considered. Put specific exceptions first, category rules in the middle, and the catch-all rule last.

Exact domains vs. domain suffixes

rules:
  - DOMAIN,api.github.com,PROXY
  - DOMAIN-SUFFIX,github.com,PROXY
  - MATCH,PROXY

The first rule matches only api.github.com. The second matches both github.com and its subdomains, but not notgithub.com. The first rule demonstrates exact matching; if both rules use the same policy, the suffix rule is usually enough.

DIRECT is the built-in direct outbound. PROXY isn't a built-in proxy keyword; it's the name used for a proxy group in this guide. If your configuration uses a different group name, replace every PROXY in the examples with the exact name in your configuration.

3. Set up a proxy group, then add direct-routing rules for mainland China

Subscriptions often include some or all of proxies, proxy-providers, and proxy-groups. Don't replace the entire subscription file with a rule snippet. First find proxy-groups and check the proxy group's name and the outbound currently selected for it.

Existing proxy group: use its name as-is

If your configuration already has a working proxy group named PROXY, you can use the rules below as written. If the group is named “Proxy Select,” use GEOSITE,geolocation-!cn,Proxy Select instead. Spaces and capitalization are part of the group name, so use the exact name rather than shortening it based on how it appears in the interface.

Manual setup: create a selector from existing proxies

This mihomo proxy-group snippet assumes your configuration already defines working proxies or a proxy provider. include-all: true adds proxies from the configuration and its proxy providers to the selection; it doesn't create proxy connection details.

proxy-groups:
  - name: PROXY
    type: select
    include-all: true

Merge this entry into the existing proxy-groups list; don't add a second top-level field with the same name. After loading, confirm that the group contains selectable proxies. If the list is empty, fix the subscription or proxy provider before working on the rules. Don't change the only outbound to DIRECT just to make the configuration load, or international traffic will still connect directly.

4. Adaptable rules for direct mainland China traffic and proxied international traffic

This is a rule snippet, not a complete subscription. Before using it, make sure you have a working PROXY group and that your GeoSite data includes the cn and geolocation-!cn categories. The rules cover five layers: private IPv4 addresses, domain exceptions, domain categories, IP-based fallback, and a final catch-all.

mode: rule

rules:
  # Local network addresses and local domains
  - DOMAIN,localhost,DIRECT
  - DOMAIN-SUFFIX,lan,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

  # Explicit domain exceptions that should use a proxy
  - DOMAIN-SUFFIX,github.com,PROXY

  # Match domain categories first
  - GEOSITE,cn,DIRECT
  - GEOSITE,geolocation-!cn,PROXY

  # Then match known destination IPs
  - GEOIP,CN,DIRECT,no-resolve

  # Connections not matched by any other rule
  - MATCH,PROXY

Why domain categories come before GEOIP

A site's business location and its server's IP location aren't the same thing. A service may use CDNs in multiple regions, and an international service may have an access point in mainland China. Let known domain categories determine the outbound first, then use IP rules to catch remaining cases. This reduces misrouting based solely on IP location. Put domains you explicitly want to proxy before GEOSITE,cn,DIRECT.

What does it mean to put MATCH last?

MATCH,PROXY sends unidentified traffic through the proxy by default. This doesn't guarantee that every mainland China service connects directly: a request may still reach the fallback rule if the database doesn't include it, the destination IP isn't available, or IP classification is inaccurate. With MATCH,DIRECT, unidentified international services may connect directly instead. These are different fallback choices; adding both won't make them decide automatically.

5. GEOSITE, GEOIP, and the limits of no-resolve

GeoSite categories come from a database, not live geolocation lookups

GEOSITE,cn,DIRECT matches a set of domains; it doesn't check which country the server is in. geolocation-!cn is also a specific category name, not generic syntax for negating every other category. If your data source doesn't include it, the configuration may fail to load with a missing-category error.

If you see this error, check the client logs for GeoSite loading details. Confirm that the database was downloaded, the file is readable, and the category exists. If you can't verify it yet, remove the international-category rule for now and let MATCH,PROXY catch the remaining traffic. Make sure the mainland China category and other rules still load correctly. Don't keep trying similar spellings for categories that aren't present.

no-resolve avoids extra DNS lookups, but can limit rule matches

GEOIP,CN,DIRECT,no-resolve means the core shouldn't resolve a domain solely for this IP rule. If the connection already has a usable destination IP, the rule can still check it. If only the domain is available and there's no usable IP, the rule can't determine the region; the request continues to the next rule.

• Connecting directly to an IP: If the destination is already an IP address, it can be checked as-is, without a DNS lookup.
• HTTP CONNECT or SOCKS requests with a domain: Don't assume the request already has a real destination IP when it reaches the rule chain.
• Fake-IP scenarios: Whether the domain can be recovered and a real address obtained depends on DNS interception, mapping state, and rule processing. The virtual address shown by the app isn't enough to determine this.

If you want mainland China IP rules to apply to more unknown domains, consider removing no-resolve from that rule so the core can resolve domains when needed. This adds DNS lookups, and results depend on which resolver is used. Check DNS routing and reachability before making changes so DNS timeouts aren't mistaken for rule failures.

6. Check connection logs for rule matches, not page load speed

After the configuration loads successfully, test with new connections. Browsers may reuse existing HTTP/2 or HTTP/3 sessions, and changing a rule won't force every existing connection to select a new outbound. Close the target page, end the related connection, and make a fresh request for clearer results.

1. Check the configuration and mode: Confirm that the current configuration has been reloaded and that rule mode is still active. If loading failed, first resolve any YAML, proxy-group, or database errors in the logs.
2. Test a local network address: Visit an active router admin address, such as 192.168.1.1. If the request reaches the client, check that it matches the private-address rule or another expected direct rule.
3. Test a mainland China site: Visit www.baidu.com and check the destination domain, matched rule, and final outbound in the connection details. The expected result is DIRECT via a mainland China domain category or IP rule.
4. Test an explicit exception: Visit github.com. It should match the DOMAIN-SUFFIX exception and use the proxy selected in the PROXY group.
5. Separate rule matching from connectivity: If the connection matched PROXY but timed out, check the selected proxy, DNS, and destination service. Don't start by deleting all mainland China rules.

A web page may request content from the main site, image servers, login APIs, and analytics domains. The homepage matching a direct rule doesn't mean every connection on the page will connect directly. Check the domains for failed requests individually. These addresses are test targets, not guarantees of latency or success rates.

7. Common rule conflicts and how to fix them

Don't judge subscription overrides by “added successfully” alone

Configuration editing and override options may vary across FlClash versions. Use the features available in your current version. The key is to inspect the final active rule list: custom rules must appear before the fallback MATCH. If an append mechanism puts new rules after MATCH, they'll never get a chance to match—even if they appear in the file.

Existing RULE-SET entries in a subscription follow the same top-to-bottom order. Don't delete every rule set just to use this guide's examples. First identify existing mainland China categories, proxy categories, and fallback rules, then merge or remove duplicates. Keep a recoverable copy of the configuration and recheck it after subscription updates to catch rules being overwritten.

Change one layer at a time

Test each layer in order: domain exceptions → GeoSite categories → GeoIP fallback → MATCH catch-all. First confirm that a known domain uses the right policy, then expand coverage. Don't change DNS, switch TUN, rewrite rules, and replace proxies all at once, or it will be hard to tell what changed the result.

Save more than the rule text. Record three checks: rule mode is active, connection details show the expected matched rule, and the proxy group uses the intended outbound. Once all three are confirmed, the direct-routing setup for mainland China and proxy routing for international traffic is complete and verifiable.