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

  1. 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.
  2. The proxy group exists: This guide uses Overseas Proxy as 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.
  3. 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

TypeWhat it matchesBest used for
DOMAIN-SUFFIXA domain and its subdomainsSpecific exceptions for a small number of sites
GEOSITEDomain category dataMainland China domains and overseas service categories
GEOIPThe region associated with the destination IPAdditional routing when the destination IP is available
RULE-SETExternal or local rule providersMaintaining 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

“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

  1. Confirm that mode: rule is active in the configuration, and temporarily set log-level: info. Switch to debug only when you need to inspect the parsing process, then restore the previous level to avoid generating excessive logs over time.
  2. 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.
  3. Visit github.com. It should match the manual domain rule or overseas-manual, and the final route should include the selected proxy node.
  4. 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.
  5. 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

SymptomCheck firstFix
All connections use the same routeMode is not Rule, or MATCH is at the topEnable rule mode and move the fallback to the end
Configuration will not loadPolicy group name, YAML indentation, core supportUse the logs to find the issue and confirm the group name matches exactly
GEOIP appears not to workno-resolve and whether the real destination IP is availableCheck DNS and domain rule matches first
Rules disappear after a subscription updateChanges were made to the generated file instead of the override sourceUse a supported override mechanism and review the final configuration
Some resources from an overseas service fail to loadResource domains differ from the homepage domainAdd separate domain rules based on failed connection records
LAN hostname will not loadInternal DNS, TUN routing, and destination reachabilityFirst 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.