Clash Rule-Based Routing: GEOIP, GEOSITE, and RULE-SET for China and International Traffic

Before you begin: Check the core and traffic entry point

Routing mainland China and international traffic separately works well when you want office, video, and download services in mainland China to connect directly while sending international services through a designated proxy group. Here, “mainland China” and “international” refer to how domain or IP data is classified—not a guess based on page language, company registration, or domain suffix. An international service may use a mainland China CDN, so domain rules generally belong before IP geolocation rules.

This complete example targets Clash Meta, now known as the mihomo core. Classic Clash and its various forks differ in their support for GEOSITE, rule-set formats, and data files. Check the actual core in the client’s About or core information page; don’t rely on the client’s name alone. If you see an unknown rule type error on load, check compatibility before tweaking indentation.

• Mode: Select Rule in the client’s Proxy or Mode page. Global mode does not evaluate the rules list line by line.
• Traffic entry point: Start by testing with a browser through the system proxy. If you need to capture apps that ignore the system proxy, check TUN separately. Enabling TUN does not replace rule configuration.
• Proxy group: The examples below use an existing group named International Proxy. It must contain working nodes and be defined under proxy-groups.
• Back up first: Export your current config. If you use a subscription, make changes through the client’s override, extension, or merge feature so subscription updates don’t overwrite them.

Rule order: top to bottom, first match wins

Rules aren’t automatically reordered so that “more specific” rules take priority. For the common rule types shown here, the core checks from the top of the list down and uses the target of the first match. A more specific domain rule later in the list won’t override a broader rule that already matched.

rules:
  - DOMAIN,mail.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,International Proxy
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,International Proxy

In this example, mail.example.com connects directly, while www.example.com uses the international proxy. Neither connection reaches GEOIP. example.com is a reserved example domain used to illustrate rule behavior, not a real service to test.

Recommended rule order

1. Specific exceptions first—for example, a domain that must always connect directly or use a proxy.
2. Local IP ranges, to keep NAS devices, routers, and LAN services off the international proxy.
3. Explicit domain rules and rule sets for international services.
4. Mainland China domain lists, followed by mainland China IP geolocation rules.
5. End with MATCH to handle traffic not covered by the preceding rules.

GEOIP, GEOSITE, and RULE-SET: What each one matches

GEOIP identifies an IP, not an entire service

GEOIP,CN checks the destination address against the configured geolocation database. The data may lag behind changes, and cloud services or CDNs can resolve the same domain to different regions. For services you know should use a proxy, prefer domain rules instead of expecting one GEOIP rule to cover every use case.

no-resolve means the core won’t actively resolve a domain to an IP just to check this IP rule. It does not disable DNS globally. Connections with a real destination IP can still match; if no usable IP is available, this rule may not match and evaluation continues to the rules below. Proxy node addresses and app-level DNS lookups still need to resolve normally.

GEOSITE requires GeoSite data files

GEOSITE,cn requires the core to load GeoSite data that includes the cn category. Some builds bundle the data; others download it on first use. If the logs report a missing file or category, check the core’s data directory, network access, and data source. Don’t replace cn with a website domain. GEOSITE domain categories and GEOIP IP categories come from separate datasets.

RULE-SET: Match the format to the behavior

Rule sets keep rules separate from the main config, making them easier to update regularly. Use behavior: domain for domain lists, ipcidr for IP ranges, and classical for traditional lists that include rule types. YAML, plain text, and MRS are parsed differently; changing only the URL while keeping an incompatible format and behavior won’t work.

Configuration example: Direct routes in mainland China, proxy for international traffic

Below is a complete rule-providers and rules section to merge into an existing mihomo config. Keep your current nodes, proxy groups, and DNS settings. This is not a standalone subscription file. Before merging, name an existing proxy group International Proxy, or replace every occurrence in the code with the exact name of your own group.

This example references Loyalsoldier’s Clash domain rule sets in YAML: international domains first, mainland China domains next, then GEOSITE and GEOIP as additional checks. If rules overlap, the earlier one in the list wins. If you want to maintain just one source of mainland China domains, remove either the mainland China RULE-SET or GEOSITE rule and delete the provider you no longer need.

mode: rule

rule-providers:
  overseas-domains:
    type: http
    behavior: domain
    format: yaml
    url: "https://raw.githubusercontent.com/Loyalsoldier/clash-rules/release/proxy.txt"
    path: ./ruleset/overseas-domains.yaml
    interval: 86400

  domestic-domains:
    type: http
    behavior: domain
    format: yaml
    url: "https://raw.githubusercontent.com/Loyalsoldier/clash-rules/release/direct.txt"
    path: ./ruleset/domestic-domains.yaml
    interval: 86400

rules:
  - DOMAIN-SUFFIX,google.com,International Proxy
  - DOMAIN-SUFFIX,github.com,International Proxy
  - DOMAIN-SUFFIX,githubusercontent.com,International Proxy
  - DOMAIN-SUFFIX,qq.com,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-CIDR,169.254.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

  - RULE-SET,overseas-domains,International Proxy
  - RULE-SET,domestic-domains,DIRECT
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,International Proxy

Check these three things when merging

• Keep only one top-level key: If the config already has rules:, edit that list instead of adding a second key at the end of the file. Duplicate keys can trigger errors or cause the earlier section to be overwritten.
• Match names exactly: The second field in RULE-SET must match the provider name, and the last field must be a built-in action or an existing proxy group. Check spelling, spaces, and capitalization.
• Keep the IPv6 rules you need: If an app uses IPv6, IPv4-only rules for local and public networks aren’t enough. Don’t remove system networking features just to simplify troubleshooting.

Updating rule sets: Keep subscriptions, providers, and geodata separate

interval: 86400 is measured in seconds, or 24 hours. It controls update checks for HTTP rule providers; it does not update node subscriptions or the data files used by GEOSITE. Check main config updates, rule-set downloads, and geolocation data updates separately.

1. Save and reload the config, then make sure there are no YAML parsing errors or missing proxy groups.
2. Find overseas-domains and domestic-domains on the client’s rule-set page. Labels vary by client; check the entry count, last updated time, and error logs rather than relying on the toggle alone.
3. Run a manual update and confirm the download succeeds. The example cache location is ./ruleset/ under the core’s working directory, not a fixed absolute system path.
4. Next, update your node subscription and reload the config. Check that your custom rules are still there. If they’ve disappeared, move your changes to the client’s persistent override feature.

On first launch, rule sources may be unreachable directly while proxy nodes are not yet available, causing rule-set downloads to fail. Restore a working base config first, then download the rule sets. In mihomo versions that support the field, you can also set proxy: International Proxy for an HTTP provider so it downloads through an existing proxy group. That group should use already-loaded nodes to avoid a dependency loop on resources that haven’t been downloaded yet.

For offline deployment, save the relevant YAML files in advance and change the provider to type: file. Keep the correct path, behavior, and format, and remove the HTTP download fields. You’ll then be responsible for updating the files locally; they won’t be fetched automatically on the HTTP update interval.

Verify routing by checking the matched rule—not just whether a page loads

Open the client’s Connections page and visit one domain that should connect directly and another that should use a proxy. Check the destination host, matched rule, proxy chain, and destination IP. A page loading successfully only confirms that the request got a response; it doesn’t prove the traffic took the intended route. Selecting a node in the proxy selector also doesn’t mean every connection will use it.

Use a consistent entry point to reduce variables

If your mixed port is 7890, run the commands below in a terminal. Change the port if yours is different. These commands test HTTP requests only; they don’t test the full system-wide TUN capture or measure connection speed.

curl -I --proxy http://127.0.0.1:7890 https://www.qq.com/
curl -I --proxy http://127.0.0.1:7890 https://github.com/

With the rules in this article, the first request should match DOMAIN-SUFFIX,qq.com and connect directly; the second should match DOMAIN-SUFFIX,github.com and use the international proxy group. The server may redirect the request or reject HEAD requests, so use the client’s connection log to verify routing.

Common issues and how to fix them

• Everything matches MATCH: Check whether the domain appears in the connection log, whether the provider loaded successfully, and whether the GEOSITE category is available. Requests made directly to an IP address can’t match ordinary domain rules.
• Traffic still uses the old node after a change: Existing long-lived connections may keep using their original route. Start a new test connection and check its match details; simply refreshing an app window that reuses its connection may not be enough.
• An international service connects directly due to GEOIP: Check whether a domain rule for the service is missing and add it before GEOIP. Don’t treat one DNS lookup as a permanent representation of the whole service.
• Browser and app behave differently: Check the system proxy, the app’s own proxy settings, TUN routes, and the browser’s Secure DNS. Sniffing can help recover domains for some protocols, but it can’t guarantee domain detection across all encrypted traffic.
• A virtual address appears with fake-ip: This is part of the DNS mapping mechanism; the core typically uses the mapping to recover the domain. Don’t add addresses from the fake-ip pool to your proxy IP list as if they were real international addresses.

Maintenance workflow: Start with small exceptions, then expand rule sets

Routine maintenance doesn’t mean adding more and more similar rules. Keep four layers—specific exceptions, domain lists, IP fallbacks, and a final catch-all—and use connection logs to address actual routing issues. When adding a rule, record the domain, target policy, and reason. Test it before copying the change to other devices.

Using the same subscription on multiple devices doesn’t mean every core can parse the same config. Before copying it to another device, confirm support for GEOSITE, IPv6, provider formats, and custom overrides. For the full setup process, see the subscription import guide. If you’re troubleshooting connection routing, also check system proxy settings and the port reference.

For a successful final check, confirm all three: the config loads, test requests to mainland China and international destinations match the expected rules, and manual rule-set updates succeed without removing custom rules after a subscription update. Once all three pass, expand testing to everyday apps. This makes issues easier to pinpoint than changing DNS, TUN, and every rule at once.