Clash Rules and Routing: Direct Connections in Mainland China, Proxies Abroad

Define the routing goal first: match domains, then use IP rules as a fallback

“Direct connections in mainland China, proxies abroad” does not mean splitting all traffic into two simple regions. Clash handles connection requests, and each request may include only a domain, only a destination IP, or a domain resolved by DNS before the connection is established. A reliable setup usually identifies targets with domain rules first, fills gaps with IP geolocation rules, and finishes with a fallback rule for unmatched traffic.

Using Clash Meta—that is, the mihomo core commonly used today—as an example, each connection is checked from top to bottom in the order listed under rules. The first matching rule immediately determines which policy group handles the connection; later rules are not evaluated. Complete rule coverage is only the baseline—the order of the rules also determines the final result.

Why GEOIP,CN alone is not enough

GEOIP,CN,DIRECT can only determine location after the core has the destination IP. If a connection is still being matched by domain, or DNS is using Fake-IP mode, GEOIP alone cannot express complete domain-level routing. CDN locations also do not necessarily indicate where a service belongs: the same domain may return IPs in different regions depending on the network, time, and DNS response.

A more reliable structure is “domains first, IPs as a fallback.” Use GEOSITE,cn,DIRECT or a mainland-China domain rule set for known sites, then use GEOIP,CN,DIRECT to catch unlisted services that resolve to mainland addresses. This reduces unnecessary DNS dependence while still covering requests that contain only an IP.

What GEOIP, GEOSITE, and RULE-SET each do

GEOIP: match by the destination IP’s geographic location

GEOIP rules look up the mapping between an IP address and a region code. The common form GEOIP,CN,DIRECT means that a destination recognized as a mainland China address uses the direct connection. It works well as a fallback for mainland traffic, but should not handle all domain routing by itself.

rules:
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

The no-resolve parameter means that this IP rule will not actively resolve a domain just to obtain its destination IP. For example, GEOIP,CN,DIRECT,no-resolve avoids an extra DNS query during rule matching, but it may not match when the request contains only a domain. Whether to add it depends on whether complete domain rules already appear earlier in the configuration.

GEOSITE: match by domain collections

GEOSITE is a domain categorization mechanism supported by cores such as mihomo. GEOSITE,cn,DIRECT sends domains categorized as cn in the geosite database to the direct policy. It does not check which IP the domain currently resolves to, making it better suited to expressing which category a service belongs to.

rules:
  - GEOSITE,private,DIRECT
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

Whether GEOSITE works depends on the core and its geographic data files. Older Clash cores, different client branches, and mihomo data modes are not fully compatible. If the configuration reports unsupported rule type GEOSITE, do not keep rearranging rules. First confirm the core used by the client, then update the core or geographic data through the client’s update controls.

RULE-SET: connect external rule files to the main configuration

When a rule set grows to hundreds or thousands of entries, putting everything under the main configuration’s rules is impractical. rule-providers lets you define separate rule files and reference them with RULE-SET. This makes updates, grouping, and review easier, and avoids changing policy groups or DNS settings whenever rules are maintained.

rule-providers:
  cn-domain:
    type: file
    behavior: domain
    format: yaml
    path: ./ruleset/cn-domain.yaml

  direct-extra:
    type: file
    behavior: classical
    format: yaml
    path: ./ruleset/direct-extra.yaml

rules:
  - RULE-SET,direct-extra,DIRECT
  - RULE-SET,cn-domain,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

behavior: domain is suitable for rule sets containing only domain entries; behavior: ipcidr is for IP ranges; behavior: classical can store complete rules such as DOMAIN, DOMAIN-SUFFIX, and IP-CIDR. The behavior type must match the file contents, or loading failures and unmatched entries may occur.

A local domain rule file can look like this:

payload:
  - '+.bilibili.com'
  - '+.jd.com'
  - '+.taobao.com'
  - 'cn.bing.com'

Here, +.example.com matches the base domain and its subdomains. To match one exact hostname, write the complete domain instead of using a suffix form. After editing the file, reload the configuration in the client; saving the file alone does not make the running core adopt the new rules automatically.

A policy-group and rule skeleton you can adapt

The configuration below uses one main proxy group, one automatic latency-testing group, and one fallback rule. Node names must match the names actually provided by the subscription. If the client generates proxy nodes from a subscription, add policy groups through subscription overrides or configuration merging rather than editing a temporary file that the next subscription update will overwrite.

mixed-port: 7890
mode: rule
log-level: info
allow-lan: false
external-controller: 127.0.0.1:9090

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - AUTO
      - DIRECT
      - Hong Kong nodes
      - Japan nodes
      - Singapore nodes

  - name: AUTO
    type: url-test
    proxies:
      - Hong Kong nodes
      - Japan nodes
      - Singapore nodes
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80

rules:
  - GEOSITE,private,DIRECT
  - GEOIP,private,DIRECT,no-resolve
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

mode: rule is required for rule-based routing. In Global mode, every connection enters the global policy group; in Direct mode, every connection bypasses the proxy. Many “rules are not matching” problems are simply caused by the runtime mode not being switched to Rule.

url-test periodically tests node latency against the specified URL. In the example, interval: 300 tests every 300 seconds, while tolerance: 80 considers switching only when the current node is more than 80 milliseconds slower than a faster node. Frequent tests use more connections and battery power, so 300 to 600 seconds is usually more suitable on desktop systems.

Policy-group syntax with a subscription provider

When nodes come from proxy-providers, a policy group can reference the provider with use, avoiding the need to list every node in the main configuration. The structure below assumes a proxy provider named airport already exists:

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - AUTO
      - DIRECT
    use:
      - airport

  - name: AUTO
    type: url-test
    use:
      - airport
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80

After a subscription update, new nodes enter policy groups that reference the provider. If the client supports configuration merging, place custom rules and policy groups in an override file. The relevant controls are usually under “Settings” → “Configuration” → “Overrides” or “Subscription” → “Configuration editor.” Menu names vary by client, but the principle is the same: preserve the original subscription and keep local routing logic in a separate merge layer.

How DNS and Fake-IP affect routing results

When the rules look correct but mainland China websites still use the proxy, DNS is the next layer to check. Once Clash takes over DNS, domain resolution, rule sniffing, and connection establishment work together. If the system DNS, the browser’s secure DNS, and Clash DNS all run at the same time, some requests may bypass the core’s domain matching and leave only IP information behind.

A common mihomo Fake-IP configuration looks like this. Listening on 1053 avoids taking over the system’s port 53 directly; the client then forwards system DNS requests to that listening address:

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://doh.pub/dns-query
  fake-ip-filter:
    - '*.lan'
    - '*.local'
    - 'localhost.ptlogin2.qq.com'

Fake-IP mode first returns a reserved address in the 198.18.0.0/16 range to the application, while the core stores the mapping between the Fake-IP and the original domain. Even if the application later connects to the IP, the core can recover the domain and apply DOMAIN, GEOSITE, or domain rule sets. Devices that are unsuitable for Fake-IP, such as LAN discovery, printers, and some login components, can be added to fake-ip-filter.

Why browser secure DNS can interfere with matching

When a browser uses its own DoH, DNS queries may be sent as HTTPS traffic to the resolver chosen by the browser. Clash can still proxy that HTTPS connection, but it may not obtain the same mapping between the later service domain and the system DNS result. During troubleshooting, temporarily disable the browser’s secure DNS or set it to “Use current service provider,” then clear the browser DNS cache and test again.

On Windows, start with ipconfig /flushdns to clear the system cache. Chromium-based browsers must be fully closed, including related processes, and reopened to rule out false results caused by reused connections. After changing DNS settings, run “Configuration” → “Reload” in the client, then disconnect and reconnect the system proxy or TUN.

How to choose between system proxy and TUN mode

A system proxy usually sends HTTP and HTTPS requests to mixed-port: 7890. Browsers, downloaders, and development tools that follow system proxy settings can enter Clash normally, but some games, command-line programs, store apps, and software with its own network stack may bypass the system proxy.

TUN mode uses a virtual network interface to take over a broader range of TCP, UDP, and DNS traffic, making it suitable for desktops that need unified routing. A basic mihomo configuration can look like this:

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  strict-route: true
  dns-hijack:
    - any:53
    - tcp://any:53

stack: mixed balances system-stack compatibility with UDP handling; auto-route writes routes automatically; auto-detect-interface identifies the current outbound network interface; and strict-route helps reduce traffic bypassing TUN. TUN usually requires administrator privileges, and the first launch may request authorization for a virtual network adapter or network extension.

How to confirm direct connections in mainland China and proxy routing abroad

Step 1: Confirm the runtime mode and reload the configuration

1. On the client home screen, confirm that the runtime mode is Rule.
2. Open “Configuration” → “Current configuration” and confirm that the file you just edited is enabled.
3. Run “Configuration” → “Reload.” If you recently changed TUN settings, disconnect and reconnect afterward.
4. Temporarily set the log level to info; there is no need to start with the much more verbose debug level.

Step 2: Check the matching chain in the connection list

Open the client’s “Connections” page and visit one mainland China site and one site that requires a proxy. Mainland requests should show something like GEOSITE,cn → DIRECT, RULE-SET,cn-domain → DIRECT, or GEOIP,CN → DIRECT; other requests should show MATCH → PROXY → specific node.

A webpage usually requests its main domain, image CDN, analytics endpoint, login endpoint, and third-party resources at the same time, so seeing both DIRECT and PROXY in the connection list is not necessarily an error. Select the specific connection and verify its destination domain, matching rule, policy group, and final node instead of checking only the page’s primary domain.

Step 3: Use the command line to bypass browser caches

In system proxy mode, explicitly specify the local mixed port for testing. Both commands below enter Clash through 127.0.0.1:7890, after which the rules determine whether to connect directly or use a proxy:

curl -I --proxy http://127.0.0.1:7890 https://www.baidu.com
curl -I --proxy http://127.0.0.1:7890 https://www.google.com/generate_204

Watch the connection panel while running the commands. The first request should normally match a mainland domain rule or mainland IP rule; the second should enter PROXY. An HTTP status code only shows whether the destination responded. The routing conclusion should come from the rule chain and final policy shown in the connection details.

Common issues and troubleshooting order

All mainland China websites use PROXY

• Confirm that GEOSITE,cn,DIRECT and GEOIP,CN,DIRECT appear before MATCH.
• Check whether the core supports GEOSITE and whether the geographic data files have loaded.
• Check whether the current mode was mistakenly set to Global.
• Check whether the destination in the connection details is a domain or an IP. If it is only an IP, investigate whether DNS was bypassed by another program.
• If only a few domains are affected, add them to a local DIRECT rule set instead of changing the entire proxy group to direct.

Overseas websites show MATCH but still cannot be reached

Matching MATCH,PROXY only means the rule selected the proxy correctly; it does not mean a node in the policy group is available. Expand the connection chain and confirm which node PROXY ultimately selected. If it stops at DIRECT, the policy group was manually switched to direct. If a node is selected but the connection times out, check the node status, subscription updates, and support for the target protocol.

Nothing changes after updating a rule file

• A local rule with type: file is not downloaded automatically; reload the configuration after editing it.
• A type: http rule provider is controlled by interval and can also be updated manually from the provider page in the client.
• Check that path points to a configuration directory the client is allowed to access.
• Check YAML indentation. List items usually begin with two spaces and a hyphen; tabs must not be mixed in.
• Confirm that behavior matches the file contents; a domain payload must not be declared as ipcidr.

LAN devices fail to connect after enabling TUN

First confirm that private-address rules appear before other broad rules and cover common ranges. Common private ranges include 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. For devices using a .local suffix, also add the relevant domains to the Fake-IP filter list. Then check whether the system firewall has identified the new TUN adapter as a public network and restricted LAN communication.

Configuration maintenance: keep the structure small and controllable

Direct connections in mainland China and proxies abroad do not require an ever-growing set of rule types. For most setups, direct private addresses, direct mainland domains, mainland IP fallback, exceptions for designated services, and a final proxy fallback are enough. The more rules you add, the more clearly you need to track their source, update time, and priority; otherwise, a rule-set update can change established behavior.

Separate custom content into three layers: subscriptions provide nodes, policy groups select nodes, and rule sets decide which policy handles traffic. Do not overwrite local rules when updating a subscription; do not rewrite proxy nodes when updating rule sets; and do not edit rules when switching nodes. With these responsibilities separated, issues usually fall into one of three layers: an unavailable node, an incorrect policy choice, or an unmatched rule.

After completing the configuration, save at least three items for review: the current core name and version, the configuration file actually loaded, and the connection details for one mainland request and one proxied request. If something goes wrong later, this information is far more useful for diagnosis than simply saying “the website does not open.”