Clash Traffic Routing for Mainland China and Overseas: Rule Order and Proxy Group Configuration

Routing model

Understand the mainland China and overseas routing model

Clash routing is not a simple check of whether a website is “in mainland China or overseas.” Instead, it evaluates each connection against the rules in the configuration file. Rules can match domains, domain suffixes, IP addresses, destination ports, process names, or external rule sets. Once a rule matches, the connection is passed to the specified proxy group, proxy node, or built-in action. The common actions DIRECT, PROXY, and REJECT mean direct connection, handing the connection to the proxy group named PROXY, and blocking the connection, respectively.

So “direct for mainland China, proxy everything else” is a goal, not a single rule that covers every case. A practical configuration usually handles LAN traffic and explicit exceptions first, then matches specified domains, regional domains, and destination IPs, and finally uses a catch-all rule for anything unmatched. A site may use an overseas domain while its servers are deployed locally, or use a mainland Chinese domain while depending on services abroad. A region database alone can therefore produce unexpected results; more specific domain rules may be needed.

It is also important to distinguish the strategy matched by a rule from the node ultimately used. For example, a rule may send a connection to the Overseas Traffic proxy group, which may then reference a Auto Select group, a Hong Kong Nodes group, or another child group. Seeing a match for “Overseas Traffic” in the log does not mean it is the final exit. Check the group’s current selection and the chain shown in the connection details.

Rule order

Rules match from top to bottom, so specific rules must come first

When mihomo processes a connection, it checks rules from top to bottom. The first matching rule determines the connection’s strategy, and later rules are ignored. A rule can be correct yet fail because it is in the wrong position—one of the most common regional-routing configuration issues. For example, if a broad mainland-China domain rule comes first and an exception for one of those domains to use a proxy comes later, the exception will never take effect.

A safer ordering moves from the most specific rules to the broadest. Local networks, loopback addresses, and home-device domains usually belong on a direct connection; domains that must use a proxy, stay direct, or use a specific exit are manual exceptions; whether to reject advertising or tracking domains should be decided carefully based on page functionality. Only then should you add grouped regional domains, regional IP rules, and the final catch-all. Rule names vary across subscriptions, but the ordering principle remains the same.

1. Local networks and private addresses: Router admin pages, NAS devices, printers, and LAN services usually belong on DIRECT so they do not take a detour through a remote node.
2. Manual exceptions: Place full domains and domain suffixes that must use a proxy, must connect directly, or require a specific exit before general rules.
3. Service rule sets: Reference maintained rule sets by service category, such as developer platforms, streaming services, or instant messaging.
4. Mainland-China domains and IPs: Put regional domain rules before GEOIP to reduce inaccuracies caused by relying only on the resolved IP address.
5. Final fallback: Point MATCH to the default proxy group so every uncategorized connection has a defined destination.

If the goal is “direct for known mainland-China resources and proxy everything else,” the fallback should point to the proxy group instead of running another regional check. Conversely, if only a small set of services should use a proxy, list those services first and finish with MATCH,DIRECT. Neither pattern is universally better; the difference lies in the default behavior and maintenance cost.

Proxy groups

Use proxy groups to separate routing intent from node selection

Binding every overseas rule directly to a specific node may look simple, but a subscription update that renames nodes can invalidate a large number of rules. A more maintainable approach is to point rules to stable proxy-group names, then let those groups organize nodes, URL-test groups, or other groups. Rules express “how this type of traffic should be handled,” while proxy groups decide “which exit handles it now.”

A practical structure usually has three layers: a main entry group, regional selectors, and automatic testing groups. The main entry can be named Overseas Traffic with type select, allowing manual selection of an auto group, a regional group, or DIRECT. Regional groups can reference matching nodes from the subscription or obtain nodes dynamically through proxy-providers and filter conditions. Auto groups commonly use url-test to probe candidate nodes periodically and select an exit with lower measured latency.

The result of url-test reflects only the response from its test URL at that moment; it does not represent the real speed of every website. Cross-region paths, destination-side limits, and node load all affect the experience. For services sensitive to login location, requiring a fixed region, or needing a stable exit, a manually selected regional group is usually more predictable than a frequently changing auto group.

proxy-groups:
  - name: Overseas Traffic
    type: select
    proxies:
      - Auto Select
      - Hong Kong Nodes
      - Japan Nodes
      - DIRECT

  - name: Auto Select
    type: url-test
    proxies:
      - HK-01
      - JP-01
      - SG-01
    url: https://www.gstatic.com/generate_204
    interval: 300

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

The node names in the example must exactly match names defined in proxies. If nodes come from a proxy provider, use the appropriate use configuration in the group instead of copying node names that do not exist. Configuration references have strict requirements: every proxy group referenced by a rule, and every node or child group referenced by a proxy group, must already be defined. Group names generated after importing a subscription into Clash Verge Rev may differ, so inspect the current configuration structure before editing it.

YAML practice

Practical routing configuration from exceptions to the fallback

The rule fragment below demonstrates a common approach: connect local addresses directly, send specified development services through a proxy, connect clearly identified mainland-China services directly, use regional data for general cases, and finally send unrecognized traffic to the overseas group. This is a structural example and should not replace an existing subscription. A real configuration also needs ports, DNS, nodes, proxy groups, and any required rule-provider definitions.

rules:
  - DOMAIN,router.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

  - DOMAIN-SUFFIX,github.com,Overseas Traffic
  - DOMAIN-SUFFIX,githubusercontent.com,Overseas Traffic

  - DOMAIN-SUFFIX,gov.cn,DIRECT
  - DOMAIN-SUFFIX,example.cn,DIRECT

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

GEOSITE is a geographic site rule supported by mihomo and depends on the corresponding geographic data files. Data-loading methods and rule sets vary between configurations. If the current configuration has no usable GeoSite data, use an already defined RULE-SET or maintain the necessary domain rules instead of adding a reference to data that cannot be loaded. GEOIP determines the region from the destination IP and is useful for connections not covered by domain rules.

no-resolve tells the core not to trigger an additional domain lookup when checking this IP-based rule for the destination IP. It is suitable at the end of some IP-CIDR and GEOIP rules, but it does not disable the client’s DNS functionality as a whole. If the connection context already contains a destination IP, the rule can still be evaluated normally.

When using an external rule provider, the rule content can be separated from its update source. A rule provider needs definitions for its behavior type, format, storage path, and update interval before it can be referenced in rules through RULE-SET. The example below shows the relationship; replace the address and filename with valid content from the source you actually maintain.

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

rules:
  - RULE-SET,local-direct,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,Overseas Traffic

The rule set’s behavior must match the file content. domain is for domain-based payloads, ipcidr is for network-range payloads, and classical can contain classic rules with rule types. A format mismatch can cause a provider update to fail or its payload to become unparsable. Remote rule sets also need a stable update source. If the source is temporarily unreachable, the client will usually continue using the saved local file, but there may be no usable cache when the first download fails.

DNS and TUN

How DNS, system proxy settings, and TUN affect results

Rules determine where connections go, but the final observed result also depends on whether the client receives the traffic, whether the domain can be reconstructed correctly, and where DNS requests are sent. The system proxy only covers applications that follow the operating system’s proxy settings. Some games, command-line tools, virtual machines, and applications with their own network stacks may bypass the system proxy. No matter how complete the rules are, traffic that never enters mihomo will not appear in the connection list.

TUN mode uses a virtual network interface to capture a broader range of TCP and UDP traffic, making it suitable for programs that do not read system proxy settings. Enabling TUN does not change the top-to-bottom rule-matching principle; it only expands the range of traffic that can enter the rule engine. TUN can also be affected by system permissions, routing tables, other VPN software, and security tools. Validate basic routing in system-proxy mode first, then enable TUN if needed.

DNS configuration is especially likely to produce the result “the rules look correct, but the outcome is inconsistent.” In fake-ip mode, the client can return a reserved address first while retaining an internal mapping between the domain and connection, giving later rules a chance to match by domain. Some LAN services, device discovery mechanisms, or programs incompatible with virtual addresses may need to be added to fake-ip-filter. In modes such as redir-host, the resolution process and connection setup differ, but DNS queries must still not be completely bypassed by another program.

If the domain is resolved to an IP outside the system before the core receives it, the connection may lack the domain context needed for domain-based rules and may ultimately fall through to an IP rule or MATCH. When troubleshooting a domain rule that does not match, inspect the destination host, resolution result, and matched rule in the connection details instead of checking YAML spelling alone.

Verification

How to verify the actual traffic path after changes

Verifying routing is not just a matter of checking whether a webpage opens. Both direct and proxied connections may succeed, while latency, exit location, and matched rules differ. A reliable check combines configuration load status, connection details, matched rules, proxy-group selection, and the observed external exit. Change only one category of condition at a time.

Step 1: Confirm that the configuration loaded successfully

After saving the YAML, check the client prompt and core log for indentation errors, incorrect field types, duplicate names, or rule-provider parsing errors. YAML uses spaces to express hierarchy; Tab characters and bad indentation can both cause loading failures. If the client is still using the old configuration, subsequent tests will not reflect your changes.

Step 2: Clear existing connections before testing

Browsers reuse HTTP/2, HTTP/3, and persistent connections, while applications may retain connection pools. After changing rules, established connections usually do not automatically select a new exit under the new rules. Close the target connection, reopen the application, or terminate the relevant connection in the client before making a new request. DNS caching can also affect comparisons; wait for the cache to expire or flush it using the system’s normal procedure if necessary.

Step 3: Inspect connection details and the match chain

In the Clash Verge Rev connections page, locate the target domain and check the matched rule type, rule payload, proxy group, and final node. If you expected DOMAIN-SUFFIX but see MATCH, the domain may not have reached that rule, an earlier rule may have intercepted it, or the connection may contain only IP information. If the proxy group is correct but the node is wrong, inspect the current selection on the proxy-group page instead of changing the rules.

Step 4: Verify direct and proxy exits separately

Compare one target explicitly configured for direct access with another explicitly configured to use a proxy. If needed, use a trusted exit-IP lookup service to confirm the public exit, but remember that lookup services may use different networks, caches, and IP geolocation databases. Regional labels are supporting evidence only; the most important evidence remains the matched rule and chain shown by the client.

• A direct target should show DIRECT, or first match a proxy group whose current selection is DIRECT.
• A proxied target should show the expected proxy group and resolve through the chain to the actual node.
• A reject rule should appear as a blocked connection; also confirm that it has not broken APIs or static resources required by the page.
• UDP, QUIC, and TCP may create separate connections, so pay attention to the protocol type during troubleshooting.

Troubleshooting

Troubleshooting order for unexpected routing results

A mainland-China website is still using the proxy

First check for a broad proxy rule placed before the mainland-China rules, such as one covering an entire top-level domain or a large rule set. Then confirm that the mainland-China proxy group is actually set to DIRECT. If the configuration only contains GEOIP,CN,DIRECT and the target uses an overseas CDN address, it may not match. Add an explicit direct domain rule for stable services when necessary.

An overseas service sometimes connects directly

Check whether the target uses multiple service domains. Modern websites commonly access separate domains for login, APIs, images, video, and analytics; proxying only the primary domain will not cover every request. Collect the actual domains from the connection list, then add necessary suffix rules or use a well-maintained service rule set. Do not turn every temporary CDN hostname you observe into an exact rule; identify stable domain boundaries first.

The rule matches correctly, but the service does not work

Matching a proxy rule only means that the connection was handed to the corresponding strategy; it does not guarantee that the node is reachable. Check whether the proxy group has selected a working node, whether the node supports the required UDP traffic, whether DNS works, whether the destination restricts exit regions, and whether the system clock is accurate. Temporarily switching to another node in the same group can help distinguish a rule issue from a node-path issue.

LAN devices become unreachable after enabling TUN

Confirm that private-network rules appear near the top and point to DIRECT. Also check TUN’s auto-route and strict-route settings, along with other virtual network adapters on the system. If LAN devices are accessed by hostname, make sure local domain resolution or the search domain has not been replaced by remote DNS. Testing with the device IP first can help distinguish a routing issue from a local name-resolution issue.

Custom rules disappear after a subscription update

Directly editing a subscription-generated configuration may cause your changes to be overwritten by the next subscription update. Clash Verge Rev can preserve local adjustments through configuration merges, scripts, or override capabilities; the exact entry depends on the current version and configuration-management method. Back up a working configuration first, keep custom proxy groups and rules in separate, easy-to-review fragments, and confirm after each update that the referenced names still exist.

Checklist

A routing checklist for ongoing maintenance

Stable routing between mainland China and overseas destinations depends on clear default strategies and a small number of necessary exceptions, not an ever-growing stack of rules. After completing the configuration, review it with this checklist:

• LAN and private-address rules are near the top and explicitly use DIRECT.
• Business domains that must use a proxy or connect directly appear before general regional rules.
• Proxy-group names referenced by rules exactly match the definitions in the configuration.
• Every node, child group, and proxy provider referenced by a proxy group actually exists.
• Regional domain rules come before regional IP rules, and MATCH is last.
• The behavior type, file format, and payload content of each external rule set are compatible.
• After making changes, terminate old connections and confirm the rule, proxy group, and final node on the connections page.
• Evaluate TUN mode only when the system proxy cannot cover the target program.
• Review custom overrides after subscription updates to prevent proxy-group references from breaking when names change.

The core of configuration is not maximizing the number of rules, but ensuring that every connection follows an explainable path to a clear strategy. Start with a small framework of “local direct access, explicit exceptions, regional matching, and a final fallback,” then add real requirements based on connection records. This is usually easier to maintain and troubleshoot than importing multiple overlapping rule sets at once.