Clash Rule Syntax Explained: How to Write DOMAIN, GEOIP, and MATCH Rules

Rule Execution Order: First Match Wins

Clash's rules is a list executed from top to bottom, where each line generally follows the format type,match content,policy. When the client receives a network request, it checks each rule in order starting from the first, and as soon as one matches, it immediately applies that policy and stops checking further. This is the single most important thing to understand about rule files — a lot of "I wrote the rule correctly but it doesn't work" problems come from overlooking this.

For example, say the rule file contains these four lines:

- DOMAIN-SUFFIX,example.com,DIRECT
- DOMAIN-SUFFIX,google.com,PROXY
- GEOIP,CN,DIRECT
- MATCH,PROXY

A request to www.google.com would first check line one — it doesn't match example.com, so it's skipped; then line two — it matches as a subdomain of google.com, a hit, so the PROXY policy is applied immediately and checking stops. The GEOIP and MATCH rules after it never get evaluated at all.

The Complete List of Common Rule Types

Beyond the six most common types in the setup guide's quick-reference table, Clash actually supports a much richer set of rule types. Here they are organized by purpose:

• DOMAIN: Exact match on a single, complete domain — subdomains are not included.
• DOMAIN-SUFFIX: Matches a domain and all of its subdomains — the most commonly used form.
• DOMAIN-KEYWORD: Matches if the domain contains a given keyword, covering multiple domain variants in a single rule.
• DOMAIN-REGEX: Matches domains using a regular expression — good for domains that follow a pattern but are hard to list one by one.
• IP-CIDR / IP-CIDR6: Matches by IPv4/IPv6 address range — commonly used for direct-connecting local network traffic.
• GEOIP: Routes based on which country/region the request's target IP belongs to, e.g. GEOIP,CN,DIRECT.
• SRC-IP-CIDR: Matches by the local source IP that initiated the request — useful for routing by source when you have multiple network interfaces or multiple devices on a LAN.
• PROCESS-NAME: Matches by the process name that made the request, letting you assign a policy to a specific app on its own (best supported on desktop).
• MATCH: The catch-all rule — matches any traffic that didn't hit an earlier rule. It must be the last line in the list.

Rule Provider: No Manual Writing, Auto-Updates From a Remote Source

Writing every rule by hand obviously isn't practical — there's no way to list thousands of mainland China domains one by one. rule-providers exists to let you reference a remotely-hosted rule collection maintained by the community or a provider; its content updates automatically from the remote source, and you only need one line in your rule list to reference it:

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

rules:
  - RULE-SET,reject,REJECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

Most subscription providers have already set up this layer for you, so regular users can use it out of the box. Only when the default rule set doesn't meet your needs (say, you want to additionally block some newly discovered ad domain) do you need to insert your own rule before it — since rules earlier in the order get matched first.

The Three Most Common Rule Mistakes Beginners Make

1. Putting MATCH in the Middle Instead of at the End

MATCH is the catch-all rule — if it's written partway through the list, none of the rules after it will ever get executed, because MATCH itself matches all traffic. Always put it on the very last line of the entire rules list.

2. Writing a Custom Rule After the Rule Provider Reference

If you want your own rule to take priority over the subscription's built-in rule set, it must go before the RULE-SET reference line — otherwise the subscription's rule set will match first, and your custom rule will never get a turn.

3. Forgetting to Add no-resolve to IP-CIDR

When matching local network IP ranges, it's a good idea to add the no-resolve parameter (e.g. IP-CIDR,192.168.0.0/16,DIRECT,no-resolve), which means the domain won't be resolved ahead of time — avoiding unnecessary DNS lookups triggered by the resolution process itself.

Practical Example: Assigning a Policy to a Single Domain

Say you want a specific site to always go through the proxy, regardless of what the subscription's rule set decides — just add one line at the very top of the rule list:

rules:
  - DOMAIN-SUFFIX,example.com,PROXY   # Custom rule goes first
  - RULE-SET,reject,REJECT
  - RULE-SET,direct,DIRECT
  - RULE-SET,proxy,PROXY
  - MATCH,PROXY

Since it comes before every RULE-SET reference, it gets matched first — it won't get "beaten to the punch" by the subscription's rule set and classified as direct connect or something else.

Final Thoughts

Once you understand the core logic of "matching in order, first hit wins," the rest of the rule types are just vocabulary to pick up along the way. If you're ever unsure what a term means, check the glossary anytime; if you just want to know why a particular site won't load, the troubleshooting steps in the setup guide may solve your problem faster than writing a rule by hand.