Check the core, rule mode, and policy groups first
“Direct for mainland China, proxy for overseas” is not a switch that automatically determines where a service is based. It is a set of rules evaluated against each connection. Clash checks rules from the top down and applies the policy of the first matching rule; it does not continue looking for a more specific match. As a result, the same domain can be routed differently depending on where its rule appears.
This guide uses the mihomo core, the successor to Clash Meta, as its primary configuration environment. The client provides the interface; the core parses the rules. Similar client names do not guarantee support for the same fields. Older Clash cores cannot use examples containing GEOSITE as-is. Check the core details in your client, then look in the logs for “unknown rule type” or data file loading errors.
Check these three things before editing
- Mode is set to Rule: The configuration must include
mode: rule. Global mode uses the global policy, while Direct mode bypasses rule-based routing; neither uses the rule list described here. - The proxy group exists: This guide uses
Overseas Proxyas the name of an existing policy group. Replace it with a group name that actually exists in your configuration, then select an available node for that group on the proxy page. Editing rules alone will not create a node. - Keep your original configuration: Copy the current configuration before making changes, then test the copy. Subscription updates may overwrite direct edits. For ongoing use, maintain changes with the client's supported override or merge feature, and check the final active configuration.
Four rule types: domains, geo data, and rule sets
| Type | What it matches | Best used for |
|---|---|---|
DOMAIN-SUFFIX | A domain and its subdomains | Specific exceptions for a small number of sites |
GEOSITE | Domain category data | Mainland China domains and overseas service categories |
GEOIP | The region associated with the destination IP | Additional routing when the destination IP is available |
RULE-SET | External or local rule providers | Maintaining a separate set of site rules |
DOMAIN-SUFFIX: for precise adjustments
DOMAIN-SUFFIX,github.com,Overseas Proxy matches both github.com and api.github.com, but not githubusercontent.com, which is a separate domain and needs its own rule. To match just one host, use DOMAIN,api.github.com,Overseas Proxy so other services under the domain are not routed the same way.
GEOSITE: categories depend on the data file
GEOSITE,cn,DIRECT uses the cn category in the geosite data; it does not mean “every domain ending in .cn.” Similarly, geolocation-!cn in common data sets is an overseas-domain category, not the complete mathematical complement of the cn set. The available categories and the sites they cover depend on the loaded data file and when it was last updated.
Before using this example, confirm that mihomo successfully loaded a geosite.dat containing cn and geolocation-!cn, along with geo-IP data for GEOIP. With geodata-mode: true, mihomo uses geoip.dat; the common default mode uses MMDB data. Data update options vary by client, so check the logs for a successful load.
GEOIP: checks the IP, not the service's origin
GEOIP,CN,DIRECT checks whether the destination IP falls within mainland China's address ranges. An overseas service using a mainland China CDN may resolve to a CN IP and match; a mainland China service hosted on overseas cloud infrastructure may not. Putting domain-category rules before IP-category rules prioritizes your intent for the service itself.
The trailing no-resolve means this IP rule will not trigger a DNS lookup on its own; it does not mean “disable DNS.” It can still match when a connection already has a real destination IP. If only a domain is available and there is no usable real IP, the rule may be skipped. Adding it can reduce lookups triggered during rule matching, but it cannot guarantee that every unlisted mainland China domain connects directly.
Rule order: LAN bypass, specific exceptions, categories, and fallback
The snippet below suits a setup where commonly used mainland China sites connect directly and all other traffic defaults to a proxy. The order is: bypass LAN traffic, manually specified overseas sites, mainland China domain category, overseas domain category, mainland China IPs, and final fallback. MATCH unconditionally matches all remaining connections, so it must come last.
# mihomo config snippet; Overseas Proxy must be an existing policy group
mode: rule
rules:
- 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-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
- DOMAIN-SUFFIX,github.com,Overseas Proxy
- DOMAIN-SUFFIX,githubusercontent.com,Overseas Proxy
- DOMAIN-SUFFIX,githubassets.com,Overseas Proxy
- GEOSITE,cn,DIRECT
- GEOSITE,geolocation-!cn,Overseas Proxy
- GEOIP,CN,DIRECT,no-resolve
- MATCH,Overseas Proxy
Why LAN rules belong at the top
Router admin pages, NAS devices, and company intranet services typically use private IP addresses. For example, sending traffic to 192.168.1.1 through a remote proxy will not reach the router on your current network. Direct private-address traffic first so it is not caught by the final proxy fallback. The 172.16.0.0/12 range covers 172.16 through 172.31; do not mistake it for 172.16.0.0/16, which covers only a smaller subnet.
Domain rules choose the outbound route; they do not guarantee that a name can be resolved. Company intranet domains may require corporate DNS, and adding a direct domain rule alone will not solve issues with .local, which is commonly used by mDNS. If TUN is enabled, also check routing and DNS interception for internal subnets. A rule matching DIRECT and the system being able to reach the LAN are two separate things to verify.
Choose a proxy or direct connection as the fallback
MATCH,Overseas Proxy: Unclassified connections default to the proxy. This works well when you want new overseas sites to use the selected outbound route.MATCH,DIRECT: Only explicitly matched services use a proxy. Use this if you have a fixed list of sites to access and want everything else to connect directly.- If you are concerned that unlisted mainland China domains may use the proxy, check which rule they match and add domain exceptions as needed. Do not move
GEOIP,CNahead of all domain rules.
“Overseas Proxy” describes a routing policy, not a promise of network quality. If the policy group selects DIRECT, the rule may match that group and still connect directly. When troubleshooting, check both the matched rule and the final outbound route.
RULE-SET: maintain frequently used site rules separately
As your manual domain rules grow, you can move them into a rule provider. The example below uses a local YAML file and does not rely on remote rule downloads. The file must be in a directory the core can read. Relative paths are usually resolved from the core's working directory, which may not be the directory containing the subscription file.
Step 1: Create a local rule file
Save it as rules/overseas.yaml. This is a rule-set file, not the client's main configuration; its root key must be payload. The example uses the classical format, where each entry includes a rule type but no outbound policy.
payload:
- DOMAIN-SUFFIX,github.com
- DOMAIN-SUFFIX,githubusercontent.com
- DOMAIN-SUFFIX,githubassets.com
Step 2: Declare and reference it in the main configuration
Merge the provider below into the existing rule-providers, then replace the three GitHub domain rules from the previous section with RULE-SET. Put the reference after the LAN rules and before the GEOSITE rules. The snippet shows only the surrounding section; keep any omitted existing rules in your actual configuration.
# Main config snippet: declare a local provider
rule-providers:
overseas-manual:
type: file
behavior: classical
format: yaml
path: ./rules/overseas.yaml
# Snippet for the corresponding position in the rules list; not the complete list
- RULE-SET,overseas-manual,Overseas Proxy
- GEOSITE,cn,DIRECT
- GEOSITE,geolocation-!cn,Overseas Proxy
- GEOIP,CN,DIRECT,no-resolve
- MATCH,Overseas Proxy
behavior: domain, ipcidr, and classical require different entry formats. Changing only the field while keeping the original file contents will not work. If you switch to an HTTP provider, configure a real source, cache path, and update interval, then verify that the download succeeds. Seeing RULE-SET in the rules list does not mean the rule file loaded; check the provider status and core logs.
Verify routing: check new connections, not just whether a page loads
A page loading only shows that one route works; it does not prove the connection used the expected outbound route. After saving and reloading the configuration, check the client's Connections page for the target domain, destination IP, matched rule, and policy chain. Check the Logs page for rule file loading errors. Page names vary by client; focus on finding these four details rather than just checking whether the proxy is enabled.
Repeatable checks
- Confirm that
mode: ruleis active in the configuration, and temporarily setlog-level: info. Switch todebugonly when you need to inspect the parsing process, then restore the previous level to avoid generating excessive logs over time. - Close the current test connection, then make a new request. Browser connection reuse may keep using the previous route; seeing an old connection after changing rules does not necessarily mean the new rules failed.
- Visit
github.com. It should match the manual domain rule oroverseas-manual, and the final route should include the selected proxy node. - Visit a mainland China site you actually use and check whether it matches
GEOSITE,cn. If it falls through to MATCH, first check the domain category and DNS result. - Connect to a LAN device that is actually available on your current network. It should match the relevant private subnet and use DIRECT. If the device is not available, do not mistake a connection timeout for a rule failure.
Test through a specific proxy endpoint
If the active configuration sets mixed-port: 7890, use the command below to explicitly send the request through the local HTTP proxy endpoint. This helps rule out the possibility that the system proxy settings were not applied to your terminal. The port is not a fixed standard; change the number in the command if your port differs.
curl --proxy http://127.0.0.1:7890 --head --max-time 15 https://github.com
--max-time 15 sets the maximum time for the entire request to 15 seconds; it does not measure access speed. HTTP status codes and response times alone cannot prove which rule matched, so compare them with the routing record on the Connections page. This command tests the explicit proxy endpoint; it does not verify that all TUN traffic is being intercepted.
Common mistakes and the limits of DNS and TUN
| Symptom | Check first | Fix |
|---|---|---|
| All connections use the same route | Mode is not Rule, or MATCH is at the top | Enable rule mode and move the fallback to the end |
| Configuration will not load | Policy group name, YAML indentation, core support | Use the logs to find the issue and confirm the group name matches exactly |
| GEOIP appears not to work | no-resolve and whether the real destination IP is available | Check DNS and domain rule matches first |
| Rules disappear after a subscription update | Changes were made to the generated file instead of the override source | Use a supported override mechanism and review the final configuration |
| Some resources from an overseas service fail to load | Resource domains differ from the homepage domain | Add separate domain rules based on failed connection records |
| LAN hostname will not load | Internal DNS, TUN routing, and destination reachability | First confirm the name resolves to the correct address, then check the direct rule |
DNS routing is not the same as connection routing
nameserver-policy selects the DNS server used to resolve a domain, while rules selects the outbound route for an application connection. Configuring local DNS for mainland China domains does not automatically make their connections direct; conversely, a DIRECT rule does not guarantee that queries use local DNS. To control the DNS path, check the dns configuration separately.
In mihomo versions that support the relevant fields, respect-rules lets DNS upstream connections follow routing rules. Before enabling it, configure bootstrap resolution settings such as proxy-server-nameserver correctly, so resolving the proxy server's hostname does not depend on the proxy itself. Adding this option to an arbitrary configuration will not fix every DNS issue.
Fake-IP and TUN do not change the first-match rule
Fake-IP associates a mapped address with a domain for handling subsequent connections; it does not automatically classify every site as mainland China or overseas. If the destination address is in the commonly used 198.18.0.0/16 mapping range, do not add the entire range as DIRECT to “fix routing.” Instead, check that the domain mapping and rule matching are working correctly.
TUN expands the traffic it can intercept; it does not turn rule mode into global proxy mode. The system proxy affects apps that honor proxy settings, while TUN can capture more IP traffic, subject to permissions, routing, and exclusions. These rules apply only to connections that reach the core. Other VPNs, system routes, and connections created directly by apps must be checked separately.