Clash Rule-Based Routing: Direct Connection for Mainland China, Proxy for Overseas Traffic

Why Split Traffic with Rules

The core idea behind rule-based routing is simple: traffic destined for sites in mainland China should go through a direct connection, while traffic destined for overseas sites should go through a proxy node — the two paths never interfere with each other. Direct connections have the advantage of lower latency and don't consume proxy bandwidth; proxy nodes let you reach overseas resources that are blocked or slow. Without traffic splitting, global mode sends everything through the proxy, which not only adds unnecessary latency for domestic sites but also eats into your node's upstream bandwidth — making things even worse during peak hours when your provider throttles speeds.

To implement traffic splitting, you need to understand how the two cooperating parts of a Clash (and its core implementations, Clash Meta / mihomo) configuration file work together: proxy-groups defines "which exit strategies are available," while rules defines "which traffic should use which strategy." Rules themselves don't pick nodes — proxy groups do. A rule simply assigns traffic to a particular proxy group, and the selection logic inside that group decides which actual line to use. Understanding this layered relationship is a prerequisite for everything that follows.

Writing proxy-groups

A proxy group is essentially a collection of proxy nodes (or other proxy groups) plus a selection method. The three most commonly used type values are:

• select: manual selection. The client shows a dropdown list, and traffic follows whichever entry you click — no automatic switching.
• url-test: automatic latency testing. It periodically probes every node in the group using url and interval, and automatically picks the fastest one.
• fallback: failover. It tries nodes in list order and automatically switches to the next one if the current node becomes unavailable.

A typical region-based traffic-splitting setup needs at least three proxy groups: an auto-test group for "overseas traffic," a fixed DIRECT (a built-in direct connection that requires no node definitions), and a fallback manual-selection group. Example:

proxy-groups:
  - name: Proxy Select
    type: select
    proxies:
      - Auto Select
      - DIRECT

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

  - name: Direct (CN)
    type: select
    proxies:
      - DIRECT
      - Proxy Select

Names such as HK-01 must match the actual node names produced when your subscription is parsed — after importing a subscription, you can usually see the real node names directly in the client's node list, and adjust the proxies field of each group accordingly. url is the target address used for the latency test, interval is the test interval in seconds, and tolerance is the switching tolerance — as long as the latency difference stays within this margin, the client won't switch nodes constantly.

Rule Types and Matching Order

Rules are matched from top to bottom, and the moment one rule matches, it takes effect immediately — no further rules are checked. This means the order of rules directly determines the routing outcome, and getting the order backwards is the single most common mistake. The commonly used rule types are:

• DOMAIN-SUFFIX: matches by domain suffix. For example, DOMAIN-SUFFIX,taobao.com matches that domain and all of its subdomains.
• DOMAIN-KEYWORD: matches by keyword within the domain. This is looser and prone to false matches, so it's best used only when you're certain the keyword is unique enough.
• DOMAIN: matches a single domain exactly, excluding subdomains.
• GEOIP: matches by the country/region the destination IP belongs to. For example, GEOIP,CN,DIRECT routes traffic directly whenever the destination IP is identified as being in mainland China. GEOIP matching relies on a built-in or external IP geolocation database, and an outdated database can lead to misclassification — it's worth having your client update its geo database file regularly.
• IP-CIDR / IP-CIDR6: matches by IP range, commonly used to route internal or LAN addresses directly.
• MATCH: a catch-all rule placed on the last line of the rule list, matching any traffic not caught by an earlier rule.

Every rule follows the same three-part syntax: type,match-value,target-policy, separated by commas. A complete rule list generally looks like this:

rules:
  - DOMAIN-SUFFIX,cn,DIRECT
  - DOMAIN-KEYWORD,baidu,DIRECT
  - DOMAIN-SUFFIX,taobao.com,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT
  - IP-CIDR,10.0.0.0/8,DIRECT
  - GEOIP,CN,Direct (CN)
  - MATCH,Proxy Select

This rule set reads as follows: first, exclude domains and LAN addresses that clearly belong to mainland China and hand them to DIRECT; for any remaining IPs identified as being in mainland China, hand them to the "Direct (CN)" group (which still routes through DIRECT internally, but leaves room for manual switching); finally, any traffic not matched by anything above is handed to the "Proxy Select" auto-test group to handle overseas access.

Creating a Dedicated Group for Streaming Services

Many users want streaming traffic to stick to a fixed set of nodes (for example, nodes specifically labeled as unlocking a streaming service) instead of being switched around by the "Auto Select" group's latency testing — this avoids sudden node switches and rebuffering mid-video. The approach is to add a dedicated proxy group and assign the relevant domains to it in the rules, making sure this rule comes before the general-purpose rules:

proxy-groups:
  - name: Streaming
    type: select
    proxies:
      - HK-01
      - SG-01
      - Auto Select

rules:
  - DOMAIN-SUFFIX,netflix.com,Streaming
  - DOMAIN-SUFFIX,nflxvideo.net,Streaming
  - DOMAIN-SUFFIX,disneyplus.com,Streaming
  - DOMAIN-SUFFIX,cn,DIRECT
  - GEOIP,CN,Direct (CN)
  - MATCH,Proxy Select

The key point here is that streaming-related domain rules must come before MATCH, and ideally before other general-purpose rules too, so they aren't intercepted early by a broader rule further up the list (such as a DOMAIN-KEYWORD entry). As a rule of thumb, the more specific an entry is and the more it needs precise control, the earlier it should appear; the more general a catch-all rule is, the later it should appear.

If you maintain your streaming domain list as a rule set (rule-provider) instead of listing entries one by one, the principle is exactly the same — you simply replace individual DOMAIN-SUFFIX lines with a reference to a remotely or locally maintained rule-set file, which adds a rule-providers field and a corresponding RULE-SET rule type. The matching-order logic doesn't change at all.

Rule Mode vs. Global Mode

Clients typically let you switch between three operating modes, and understanding how they relate to the configuration above matters:

• Rule mode: matches strictly against the rules list, entry by entry — this is the default behavior described in this article.
• Global mode: ignores all rules and sends every connection through a single manually selected node. Useful for briefly testing whether a specific node works, but not meant for everyday use.
• Direct mode: ignores all rules and sends every connection directly, bypassing all proxy nodes. Useful for briefly checking whether the proxy itself is the source of a connection problem.

For everyday use, stick with rule mode, and only switch briefly to global or direct mode for comparison testing when troubleshooting. Remember to switch back afterward — otherwise your traffic-splitting rules won't take effect.

Checking Your Rules After Writing Them

1. After saving the config, reload it from within the client (different clients may call this "reload" or "refresh") to make sure editor caching doesn't leave your rules unapplied.
2. Open the client's connection log or traffic panel, visit a known site in mainland China, and confirm the matched rule and final policy is DIRECT.
3. Visit a known overseas site and confirm it lands on the expected proxy group, and that the node currently selected in that group is healthy.
4. If a domain ends up on the wrong policy, check whether an earlier, broader rule (especially a DOMAIN-KEYWORD entry) is intercepting it before it reaches its intended rule.
5. If GEOIP results look off, check when the client's geo database file was last updated — an outdated database can cause inaccurate IP attribution for some addresses.

Rule-based routing isn't something you write once and forget — as the sites you visit and the nodes you use change, the node lists in your proxy groups and some of your domain rules may need periodic adjustments. Get into the habit of checking the logs before changing rules; it's far more reliable than guessing.