Once you've finished the basic Clash setup, you'll quickly find yourself wanting things like this: domestic sites direct, overseas sites through the proxy, the company intranet bypassing the proxy, game traffic handled on its own, and ads blocked along the way. None of that comes from simply "turning on the proxy" — it's the core capability of Clash's rule engine. This article starts from rule syntax and walks you through building a routing strategy that's truly your own.

How the Rule Engine Works

For every network request, Clash matches the rules in the rules list one by one, in order. As soon as a rule matches, it immediately performs the corresponding action (use a particular proxy group, connect directly, or reject) and stops checking further down the list. That makes the order of your rules critical — the more specific a rule is, the higher it should sit, and the broader it is, the lower it should go.

A typical rules list looks like this:

rules:
  - DOMAIN-SUFFIX,company.internal,DIRECT
  - DOMAIN-SUFFIX,google.com,Proxy
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

The final MATCH is the catch-all rule and must sit at the very end of the list — otherwise any rules after it would never run.

The Clash Meta / Mihomo core supports more rule types (such as GEOSITE, PROCESS-NAME, and RULE-SET) and is more powerful than the original Clash. All examples in this article use Mihomo core syntax.

Common Rule Types Explained

Domain Rules

DOMAIN matches a full domain exactly, DOMAIN-SUFFIX matches a domain and all of its subdomains, and DOMAIN-KEYWORD matches any request whose domain contains a given keyword. They go from precise to fuzzy, and each fits a different use case:

In everyday configs, DOMAIN-SUFFIX is used the most: it covers subdomains while avoiding accidental matches on unrelated domains. Reach for DOMAIN only when you need precise control.

IP Rules

IP-CIDR and IP-CIDR6 match by IP address range, and are commonly used for direct intranet connections or to block specific IP ranges. For example:

- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
- IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
- IP-CIDR,172.16.0.0/12,DIRECT,no-resolve

These three are the private address ranges defined by RFC 1918, and nearly every subscription config includes them to ensure LAN devices can reach each other without going through the proxy. no-resolve tells Clash not to trigger a DNS resolution for this rule, avoiding lookup loops.

Geolocation Rules

GEOIP matches by the IP's geographic location, while GEOSITE matches against a domain-category database. This is the cleanest way to achieve "domestic direct, overseas proxied":

- GEOSITE,cn,DIRECT
- GEOSITE,google,Proxy
- GEOIP,CN,DIRECT
- GEOIP,LAN,DIRECT

GEOSITE is based on domain categories and is more accurate than GEOIP — for example, a CDN node hosted overseas might be misjudged as foreign by GEOIP, whereas GEOSITE,cn can correctly identify it as a domestic service.

Process and Port Rules

PROCESS-NAME matches by the name of the program making the request, which is great for sending specific software down a specific route:

- PROCESS-NAME,Telegram.exe,Proxy
- PROCESS-NAME,WeChat.exe,DIRECT
- PROCESS-NAME,steam.exe,Game

DST-PORT and SRC-PORT match by destination or source port. They're rarely used on their own, but come in handy for fine-grained control over game UDP traffic.

Proxy Groups: The Target of a Rule

The third parameter on the right side of a rule is a proxy group name or an action. Aside from DIRECT (connect directly), REJECT (reject), and REJECT-DROP (silently drop), everything else is a proxy group you define yourself.

Common proxy group types:

A practical multi-group strategy example:

proxy-groups:
  - name: Proxy
    type: select
    proxies: [Auto, HK, JP, US, DIRECT]
  - name: Auto
    type: url-test
    proxies: [HK, JP, US]
    url: http://www.gstatic.com/generate_204
    interval: 300
  - name: AdBlock
    type: select
    proxies: [REJECT, DIRECT]

Rule-Provider: Subscribing to Third-Party Rule Sets

Maintaining hundreds of rules by hand isn't realistic. Rule-Provider lets you subscribe to rule sets from a remote URL, and Clash pulls updates on a regular schedule. The config format looks like this:

rule-providers:
  reject:
    type: http
    behavior: domain
    url: "https://example.com/rules/reject.txt"
    path: ./ruleset/reject.yaml
    interval: 86400
  direct:
    type: http
    behavior: domain
    url: "https://example.com/rules/direct.txt"
    path: ./ruleset/direct.yaml
    interval: 86400

rules:
  - RULE-SET,reject,AdBlock
  - RULE-SET,direct,DIRECT
  - GEOSITE,cn,DIRECT
  - MATCH,Proxy

behavior can be domain, ipcidr, or classical. domain and ipcidr are optimized binary formats that match faster, while classical supports the full Clash rule syntax for maximum flexibility.

When using a third-party Rule-Provider, make sure the source is trustworthy. A malicious rule set could point legitimate domains at REJECT to break services, or send traffic to a malicious node to steal it.

Ad Blocking in Practice

The principle behind Clash's ad blocking is simple: match ad domains to REJECT or REJECT-DROP, the request is dropped locally, and the ad content never loads. Compared to a browser extension, Clash blocks at the system level, so it covers ad requests from inside every app.

A recommended ordering for ad-blocking rules:

  1. Direct connections for LAN and intranet IPs (to avoid blocking local services by mistake)
  2. Ad-domain rule set → REJECT
  3. Domestic domains → DIRECT
  4. Overseas domains → Proxy
  5. MATCH catch-all

Once ad blocking is on, some sites' "anti-ad-blocker" detection may kick in and prompt you to disable your ad blocker. That's normal, and you can add an exception for specific domains in your rules:

- DOMAIN-SUFFIX,anti-adblock-example.com,DIRECT

Place the exception rule before the ad rule set, so it matches the direct connection first instead of being rejected.

Hands-On: Customize Your Own Routing Strategy

Here's a complete rule framework that suits most users — feel free to add to or trim it as you like:

rules:
  # 1. Local & intranet
  - GEOIP,LAN,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve

  # 2. Ad blocking
  - RULE-SET,reject,REJECT

  # 3. Custom direct (work, banking, government)
  - DOMAIN-SUFFIX,company.com,DIRECT
  - GEOSITE,cn,DIRECT

  # 4. Custom proxy (specific services via specific nodes)
  - DOMAIN-SUFFIX,openai.com,US
  - DOMAIN-SUFFIX,netflix.com,Proxy

  # 5. Domestic IPs direct
  - GEOIP,CN,DIRECT

  # 6. Catch-all
  - MATCH,Proxy

In clients like Clash Verge Rev, you can edit visually through the "Profiles → Rules" interface, or modify the YAML file directly. After editing, click "Reload Config" to apply the changes — no need to restart the client.

Debugging Rules: Confirming Where Traffic Goes

After writing your rules, how do you verify that a given stream of traffic is actually routed as intended? Clash provides a connection log. Open the "Connections" panel in Clash Verge Rev and you can watch, in real time, the matched domain, destination IP, the rule used, and the final proxy group for every request.

Debugging tips:

  1. Visit the target site first, then find the matching entry in the connection log
  2. Check the "Rule" column to confirm which rule was hit — if it's not the one you expected, the ordering needs adjusting
  3. If it shows MATCH, none of the earlier rules matched, and you need to add a more specific rule
  4. Reload the config after editing rules, then refresh the page and retest

For bulk verification, you can query rule matching through Clash's API. Power users can also set LOG-LEVEL to debug to see the full rule-matching process in the log file — but for everyday use, keep it at info to avoid bloating the log.

Merging Rules: Override vs. Replace

When using a subscription, how do your custom rules coexist with the rules the subscription provides? There are two common approaches:

In Clash Verge Rev's "Profiles → Override" feature, you can append rules with a YAML snippet without touching the full config file. For example, to add only ad blocking and a custom direct connection:

prepend-rules:
  - RULE-SET,reject,REJECT
  - DOMAIN-SUFFIX,mycompany.com,DIRECT

The upside of this approach is that subscription updates won't overwrite your custom rules — it's the most recommended way to handle day-to-day maintenance.

Common Troubleshooting

Rule changes didn't take effect

Make sure you reloaded the config (not just saved the file). Some clients have two separate editing entry points, "Rules" and "Config" — editing the wrong one won't take effect. Check that your YAML indentation is correct, too: YAML is extremely sensitive to indentation, and one missing space can cause an entire block of rules to be ignored.

Domestic sites went through the proxy

Usually GEOIP,CN,DIRECT is placed too far down and gets beaten to the match by an earlier MATCH,Proxy. Move your GEOIP/GEOSITE rules up, and make sure the catch-all rule is last.

Ad blocking breaks an app's functionality

Some apps' analytics, push, and update service domains live in the same rule set as ad domains. Add a DOMAIN-SUFFIX exception for the affected app, or temporarily change the ad rule set from REJECT to DIRECT to track down the specific domain.

Conclusion

Clash's rule system is the soul of split-routing proxying. Master the three core rule types — DOMAIN-SUFFIX, GEOSITE, and GEOIP — and pair them with Rule-Provider subscriptions, and you can build a stable, personalized routing strategy. Ad blocking just means pointing ad domains at REJECT, and as long as your rule order is correct, you get system-wide ad removal.

Rule configuration is never "done in one shot" — as your use cases change, you'll keep fine-tuning. We recommend starting from the default rules your subscription provides and adding only one or two custom rules at a time and testing them, which is far safer than rewriting everything at once.