Clash Rule Routing Guide: Split Traffic by Domain Suffix and GeoIP

1. Rule Mode and Matching Order

Clash routes traffic on a per-connection basis. Once a connection reaches the core, it checks rules from top to bottom using available information such as the destination domain, destination IP, and port. The first matching rule determines the outbound policy; later rules generally do not affect that connection. Rule order matters more than the number of rules.

This guide uses common, basic Clash rule syntax and applies to Clash and Clash Meta/mihomo cores that support these fields. Client interface labels may differ, but mode: rule, rules, and policy names in the configuration must match the setup actually in use. Do not assume that extended rule types or database options work across all versions.

Check These Three Settings First

1. Mode: Switch to Rule mode. Global mode does not route traffic according to the rules in this guide, and Direct mode is not a rule-testing environment.
2. Traffic entry: Make sure the browser reaches the core through the system proxy or an explicitly configured proxy. Consider TUN mode if you need to capture traffic from apps that ignore the system proxy.
3. Available outbound: Your configuration must include a working proxy node or a policy group containing one. This guide calls that group Overseas Proxy.

The system proxy and TUN determine which connections reach the core; rules determine how those connections are routed. Enabling TUN does not automatically proxy every connection, and Rule mode does not automatically capture traffic from every app on the system. First confirm that the connection appears in the client’s connection list, then check how it was routed.

Three Core Rule Types

DIRECT is a built-in direct-connection policy. Overseas Proxy is a user-defined name, not a built-in core keyword. Both can be used as the policy in a rule, but the latter must already be defined as a node or policy group, with an exact name match.

2. Basic Setup: Direct in China, Proxy Elsewhere

Back up your active configuration before replacing the rules section. The snippet below is meant to be merged into an existing configuration; it does not include subscription URLs, node credentials, or a complete policy group. If mixed-port or mode already exists, edit the existing field instead of adding a duplicate at the same level.

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

rules:
  # LAN names and common local addresses
  - 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
  - IP-CIDR6,::1/128,DIRECT,no-resolve
  - IP-CIDR6,fc00::/7,DIRECT,no-resolve
  - IP-CIDR6,fe80::/10,DIRECT,no-resolve

  # Explicit domain policies
  - DOMAIN-SUFFIX,qq.com,DIRECT
  - DOMAIN-SUFFIX,jd.com,DIRECT
  - DOMAIN-SUFFIX,github.com,Overseas Proxy
  - DOMAIN-SUFFIX,githubusercontent.com,Overseas Proxy
  - DOMAIN-SUFFIX,wikipedia.org,Overseas Proxy

  # IP geolocation and final fallback
  - GEOIP,CN,DIRECT
  - MATCH,Overseas Proxy

7890 is the HTTP/SOCKS mixed port used in this example; it is not the default for every client. Keep the actual port if your client uses a different one. Check your policy group too: even if a rule matches Overseas Proxy, the connection will still go direct if the group’s current selection is DIRECT.

Why Explicit Domain Rules Go Before GeoIP

Domain rules express routing intent; GeoIP rules reflect how an IP is classified in a database. They are not interchangeable. Suppose a domain you explicitly want to proxy resolves to an address the database labels CN. If GEOIP,CN,DIRECT comes first, the connection will go direct before the domain rule is checked. Put explicit domain rules first so site-specific policies take precedence over IP location.

Likewise, services that should connect directly can use a preceding domain rule for DIRECT, even if their IP addresses are outside mainland China. This is a default routing policy, not an absolute classification of every site. Handle login, payment, and corporate private-network services according to their specific network requirements.

3. DOMAIN-SUFFIX Syntax and Scope

DOMAIN-SUFFIX,qq.com,DIRECT matches qq.com and subdomains such as mail.qq.com. It does not match notqq.com just because the text looks similar. Enter only the domain—no https://, path, or query string—and do not add *.qq.com.

• Exact hostname: DOMAIN,login.example.com,DIRECT matches only that hostname.
• Entire domain tree: DOMAIN-SUFFIX,example.com,DIRECT matches both the root domain and its subdomains.
• Keyword: DOMAIN-KEYWORD matches by substring and has a broader scope, so it is not a good substitute for a precise domain list.

example.com above is only a syntax example. For actual use, enter verified domains for the services you need. A webpage may request content from its main site, image hosts, APIs, and object storage. Routing the main domain through a proxy does not mean every resource follows the same policy. For example, GitHub pages and some raw files use github.com and githubusercontent.com respectively; check each connection in the client’s connection list.

Put Narrow Exceptions First

rules:
  - DOMAIN,download.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,Overseas Proxy
  - GEOIP,CN,DIRECT
  - MATCH,Overseas Proxy

This standalone snippet demonstrates an exception within the same domain tree: route the download host directly and other subdomains through a proxy. If you swap the first two rules, the suffix rule will match first and the exact-host rule will never take effect. Whenever you add a rule, check whether an earlier rule above it has a broader scope.

4. GeoIP, DNS, and no-resolve

GEOIP,CN,DIRECT does not mean “direct for Chinese-language websites” or “direct for all .cn domains.” It checks the region assigned to the destination IP. A domain may use an overseas CDN, while an overseas site may resolve to an address in China. Database updates, IP address changes, and DNS responses can all affect the match.

Traditional Clash commonly uses Country.mmdb for GeoIP data. mihomo also offers geographic database settings that depend on the operating mode and version. If the database fails to load, check the current core logs and the database settings actually in use. Do not copy database filenames, update URLs, or extended fields from another client without verifying compatibility.

no-resolve Does Not Disable DNS

Adding no-resolve to an IP-based rule means the core will not perform an additional domain lookup just to evaluate that rule. If the connection already has a destination IP, the rule can still match against it. This does not prevent apps from making DNS queries or change the system’s DNS settings.

The basic configuration in this guide adds no-resolve to the LAN subnet rules, avoiding lookups for every domain just to check for a private address. The CN rule still allows resolution. If internal names must always go direct, add explicit domain rules or configure internal DNS correctly rather than assuming the private-address rule will receive a resolved IP first.

Fake-IP and Domain Visibility

In Fake-IP mode, the core maintains a mapping between domain names and fake addresses. When a connection reaches the core, it can use that mapping to recover the domain and evaluate the rules. Do not treat the common Fake-IP range 198.18.0.0/16 as a real overseas service subnet, or force the whole range to DIRECT just to “skip fake addresses.”

Conversely, if an app uses its own DNS, connects directly to an IP, or bypasses the expected DNS path, the core may not have enough domain information for DOMAIN-SUFFIX to match. mihomo sniffing can recover domain information for some connections, but not every protocol. Check the domain, destination IP, and matched rule in the connection details instead of relying only on the browser’s address bar.

5. Load the Configuration, Verify Connections, and Check Logs

Verification has two steps: first confirm that the configuration loaded successfully, then check that new connections match the expected policies. Saving a file does not mean the client is using the new rules. Subscription configurations may also be transformed by the client, so check the active configuration or connection details.

1. Back up: Export the current configuration and note the operating mode, listening port, and selected policy group.
2. Check the syntax: Use standard ASCII commas and consistent indentation, and make sure there is only one top-level rules field.
3. Reload: Use the client’s configuration reload feature. If reloading fails, start by fixing any YAML or policy-name errors in the logs.
4. Start a new connection: Close existing connections from the test page, then make a fresh request. Old connections may keep using their original outbound, and refreshing the page may reuse a persistent connection.
5. Check three details: The destination domain or IP, the matched rule, and the final outbound node. All three must be correct to confirm that routing worked as expected.

Test the Proxy Entry Directly—Not Just Your Public IP

If your mixed port is 7890, you can use the following command locally to make a request through the core. It tests only this explicit proxy entry; it does not confirm that other apps are using the system proxy or TUN.

curl --proxy http://127.0.0.1:7890 --head --connect-timeout 10 https://github.com/

10 here is the connection timeout in seconds, not a speed-test result. After running the command, look for github.com in the connection list. It should match the earlier domain-suffix rule, then pass through the Overseas Proxy group to the selected node. An HTTP redirect or other status code does not, by itself, indicate a routing problem.

To test GeoIP, temporarily choose a target that is not covered by an earlier domain rule, note the IP it resolves to, and check whether the CN rule matches. Do not assume a public website will always match the same rule; CDN addresses and database contents can change. To verify the final MATCH rule, use the actual connection record as well.

6. Common Mistakes and Ongoing Maintenance

Subscription Updates and Rule Merging

Subscriptions provide configuration or node data; whether rules persist depends on how the client processes that configuration. Editing a generated file directly may work only until the next update overwrites it. Use a persistent override, script, or rule-merging feature explicitly supported by the client, and check whether it prepends, appends, or replaces the rules. Appending new rules after an existing MATCH may be syntactically valid but will not affect routing.

As your rules grow, consider managing them as rule sets. mihomo can load rule sets with rule-providers and reference them using RULE-SET; the behavior type and file format must match. Do not assume a file containing only a list of domains is a universal rule-set format, and do not replace your entire ruleset just to handle one domain exception.

Final Checklist

• Put precise service exceptions first, general GeoIP rules later, and MATCH at the end.
• Domain rules should not include a protocol or URL path, and policy names must match the active configuration.
• Check IPv4 and IPv6 separately. A successful IPv4 test does not prove that both paths work correctly.
• Change one related set of rules at a time. Reload, verify with a new connection, then continue.
• Record the matched rule and final node. If a connection times out, check the proxy node, DNS, and destination service reachability separately.

A stable basic setup prioritizes local routes and service-specific exceptions, then applies domain rules, uses GeoIP for addresses not already covered, and finishes with MATCH as the fallback. For details on individual fields, see the protocol reference. If the client or proxy entry is not set up yet, use the configuration guide to confirm that traffic is reaching the core first.