Clash Rules Guide: Direct Connections for Local Traffic and Proxies for International Traffic

Start with the basics: rule mode, traffic entry, and route

“Direct connections for local traffic, proxies for international traffic” involves three separate actions: send LAN addresses to DIRECT, bypass the proxy for clearly identified domestic sites based on their domain or IP, and send all other connections to a proxy group. “Local” here means your router, NAS, and other services on your private network; it is not the same as “domestic websites.” Distinguishing between these destinations helps prevent connections to your company network from being routed through a remote node.

These examples are for the mihomo core. Clash Nyanpasu is a graphical client; the core currently in use is what actually processes rules. Older Clash versions may support some fields differently. In particular, include-all below may not work across all clients with the Clash name, so don’t assume mihomo configurations are universally compatible.

• Proxy mode: Select “Rule.” Global mode doesn’t use the standard rules list to choose a route, while Direct mode won’t provide a proxy fallback.
• Traffic entry: Your browser must use the client’s proxy port, or the traffic must be captured by TUN. The system proxy setting may not cover every app.
• Policy group route: A rule matching a proxy group doesn’t mean a working node has been selected. Check the group’s current selection too.
• Configuration source: Check which subscription is active and whether an override or merge script is changing the final rules.

Back up the configuration you’re currently using. A subscription manager may rebuild it during updates, so use a persistent override or merge mechanism supported by your client to preserve custom rules. Then check the resulting configuration rather than editing a temporary generated file.

Rule matching order: put specific exceptions first and MATCH last

The standard rules list is evaluated from top to bottom. The first matching rule determines the policy, and evaluation stops there; the core won’t keep looking for a “more specific” match. Rules aren’t automatically sorted by domain length or IP range size. For example, if a suffix rule covering an entire site comes first, a later exception for a single subdomain will never take effect.

How to put domain exceptions ahead of suffix rules

rules:
  - DOMAIN,example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,Proxy
  - MATCH,Proxy

In this example, example.com connects directly, while www.example.com goes through the proxy. If you swap the two lines, the root domain will also match the suffix rule first. These reserved example domains illustrate matching behavior; they aren’t real sites to add to your configuration.

no-resolve means the core won’t actively resolve a domain to an IP just for this IP rule. It doesn’t disable every DNS lookup made during a connection. If the connection already includes a destination IP, the rule can still match against it. This option is useful for LAN subnet rules because it avoids unnecessary lookups when checking private network addresses.

Direct local connections and international proxies: a configuration you can verify

The following snippet is intended to be merged into an existing mihomo configuration. It is not a complete subscription with proxies, DNS, and listening ports. Keep your existing proxies or proxy-providers, then merge in the policy group and rules. If a top-level field with the same name already exists, edit it instead of adding a second rules: field.

mode: rule

proxy-groups:
  - name: Proxy
    type: select
    include-all: true
    proxies:
      - DIRECT

rules:
  # Personal exceptions: match domains first when available
  - DOMAIN-SUFFIX,home.arpa,DIRECT
  - DOMAIN-SUFFIX,lan,DIRECT

  # Loopback, private networks, and link-local addresses
  - 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

  # Route domestic IPs directly; send remaining connections to the proxy group
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

Select a node, then verify the proxy route

include-all: true adds existing nodes and nodes from proxy providers to this mihomo policy group. The example keeps DIRECT as an option, so after applying it, you must select a working node in the “Proxy” group. If DIRECT remains selected, traffic will connect directly even when the logs show a MATCH. If you haven’t imported any nodes, this snippet can’t create a proxy connection for you.

If your configuration already has a working policy group, it’s usually simpler to keep it and replace “Proxy” in the rules with that group’s exact name. Names are case-sensitive, and spaces count. Don’t delete an automatic selection group supplied by your subscription just to fit this example.

What this basic routing setup can and can’t do

• GEOIP,CN checks the database location of the destination IP, not the website’s language, the company’s country of registration, or its top-level domain.
• Domestic services may use overseas CDNs, and international services may be assigned domestic IP addresses. Domain rule sets can help account for these cases.
• GEOIP requires a working local database. If the file is missing or fails to load, fix that first; a failed rule load should not be treated as a normal fallback.
• Private network domains must resolve correctly. A DIRECT rule won’t configure corporate DNS for the client or automatically discover your NAS.

The GEOIP rule here doesn’t include no-resolve, so the core can resolve a domain when needed to check whether its IP is domestic. The trade-off is that some connections may trigger a local DNS lookup first. If you need strict control over where DNS queries are resolved, configure DNS policies too; routing traffic through a proxy doesn’t guarantee that DNS queries also go through it.

Using rule-providers: remote rule sets and behavior types

For larger rule lists, you can move domain entries out of the main configuration. rule-providers defines a rule set’s source, format, and update schedule; RULE-SET references that set in the rules list. Defining a provider without referencing it won’t change how any connection is routed.

This example uses a public Loyalsoldier direct-connection domain rule set with an HTTP provider. The list contains direct-routing recommendations maintained by its publisher; it doesn’t define a strict geographic boundary for China. Check that its coverage suits your needs before using it. The core fetches rules from the URL when configured; this webpage doesn’t request them automatically.

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

interval: 86400 is measured in seconds, so updates are checked every 24 hours. path specifies the local cache file under the core’s working directory, not a path relative to this webpage. On first load, the remote content must be available or a usable cache must already exist. Don’t assume the core will skip the rules and start normally if the download fails.

Add the rule set in the right place

Keep the personal exceptions and LAN rules from the previous section, then insert the following line after them and before GEOIP. Only the end of the list is shown here; don’t replace the whole list and lose your existing private network rules.

  - RULE-SET,direct-domains,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

A recommended order is “personal exceptions → LAN → direct-domain set → domestic IPs → proxy fallback.” If a domain appears in the direct-connection list but should use a proxy, add an explicit proxy rule for it before RULE-SET. An exception placed after MATCH will never take effect.

Match behavior to the rule file format

A local file with behavior: domain and format: yaml can look like this. Here, +.example.com matches the root domain and its subdomains. Don’t mistake it for the full three-part syntax used in standard rules.

payload:
  - '+.example.com'
  - 'example.net'

For classical content, use match conditions such as DOMAIN-SUFFIX,example.com; don’t append DIRECT to each payload entry. The policy is specified by the outer RULE-SET,rule-set-name,policy rule. The file extension doesn’t determine its actual format: the remote URL above ends in .txt, but its content is still a YAML payload.

Test three kinds of connections: LAN, domestic sites, and proxy fallback

Saving the configuration only means the edits are complete; it doesn’t prove the new rules are handling connections. After reloading, confirm the active configuration in the client, then check the connection list and core logs. Screen names vary by version, so focus on viewing the matched rule and full route for each connection rather than just checking the mode button.

1. Test your LAN: If your router is actually at 192.168.1.1, access it through the proxy entry. It should match 192.168.0.0/16 and show DIRECT. Don’t assume every home network uses this gateway.
2. Test a domestic site: Start a new connection to a domestic site and check whether it matches direct-domains or GEOIP CN. If it matches MATCH, first check whether the domain is in the list, then verify the geolocation of the resolved IP.
3. Test the proxy fallback: Visit an international site that isn’t in the direct-connection set. It should match MATCH, and the route should continue to the selected node rather than end at DIRECT.
4. Test an exception: Add a temporary rule for an exact domain at the top, start a new connection, and confirm it matches before the rule set. Remove the temporary entry when you’re done if you don’t need to keep it.

Use curl to confirm which proxy port a request uses

If your active configuration has mixed-port: 7890, use the command below to make a request explicitly through the HTTP proxy port. Use the port from your active configuration; 7890 isn’t universal. In Windows PowerShell, use curl.exe to avoid differences caused by command aliases.

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 -I https://example.com/

This command confirms that traffic is passing through the local proxy entry; it doesn’t prove that a particular website should use a proxy. In the connection list, compare the request time, destination domain, matched rule, and route. For a SOCKS-only entry, use its corresponding port. socks5h:// sends the domain to the proxy for resolution, avoiding a local lookup by the test tool that could affect the results.

Changing rules usually won’t reroute an existing TCP connection. Browser connection pools, HTTP/2, and QUIC can reuse sessions. Close existing connections before testing, then make a new request; otherwise, you may mistakenly conclude that the rules aren’t working.

Troubleshooting routing issues

A proxy group matches, but traffic still connects directly

Expand the policy group to check its final route. A manually selected group may have DIRECT selected, or it may contain another selection group that ultimately chooses DIRECT. The connection only goes through a proxy when the full route shows an actual proxy node. Calling a group “Proxy” doesn’t force it to proxy traffic.

The configuration saves, but the remote rule set isn’t available

Check the logs for the provider name, HTTP status, and parsing errors. A 403 means the server refused the request; a 404 usually indicates an incorrect path or branch. If the response is an HTML error page, a completed HTTP request still doesn’t mean valid rules were retrieved. Don’t put a subscription proxy node URL in a rule provider; the two use different data formats.

The browser works, but games or command-line tools don’t follow the rules

First check whether the connection appears in the connection list. If it doesn’t, check whether the app uses the system proxy, connects directly, or is actually covered by TUN. TUN expands the range of traffic entering the client; it doesn’t fix the order of your rules. UDP traffic also requires support from the entry, core, and node route.

An IP address connects directly, but its LAN domain won’t open

This usually calls for checking DNS resolution. Does your router or corporate DNS have a record for printer.home.arpa? Is the app using the system resolver or its own encrypted DNS? Adding a DIRECT rule won’t fix a domain that doesn’t resolve to the correct private IP. Also note that .local is often associated with mDNS, so it shouldn’t be treated as an ordinary unicast DNS suffix.

Custom rules disappear after a subscription update

Check that your changes were saved in a persistent override layer, then review the merge behavior: some methods append arrays, while others replace them entirely. If custom rules are appended after the existing MATCH, they’ll still be visible but will never match. After each update, check at least the start of the list, the RULE-SET reference, and the final MATCH rule.

For maintainable routing, keep a small number of clear exceptions, use rule sets with known sources for larger domain lists, and verify the results in connection logs. For more setup basics, see the user guide. To understand how DNS, TUN, and core settings interact, see the technical reference. More rules don’t necessarily mean more accurate routing; a reliable setup depends on the right entry, rule order, and final route working together.