How to Write Clash Custom Rules: DOMAIN, IP-CIDR Syntax & Match Priority Explained

1. Basic Structure of a Rule Entry

Clash's traffic routing is built entirely on rules — every line under the rules: field in the config file is one independent rule. The general format has three parts separated by commas:

TYPE,ARGUMENT,POLICY

TYPE defines the matching method — for example, domain, IP range, or process name; ARGUMENT is the actual value to match; POLICY is what happens on a match — a proxy node name, a policy group name, or the built-in DIRECT or REJECT. Some rule types also support an optional fourth field, most commonly no-resolve, which tells the core to skip DNS resolution when matching IP-based rules, avoiding extra lookup delay or privacy leaks. A complete rule example looks like this:

DOMAIN-SUFFIX,example.com,Proxy
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve

Understanding this three-part (plus optional fourth field) structure is the foundation for everything else covered below.

2. Breaking Down Common Rule Types

The Clash core (including the Clash Meta / mihomo branch) supports quite a few rule types, but the ones you'll actually use day to day fall into four groups: domain-based, IP-based, geolocation-based, and process/port-based.

1. Domain-Based Rules

• DOMAIN: exact match on a full domain. For example, DOMAIN,www.example.com,Proxy only applies to that exact domain — subdomains or other prefixes won't match.
• DOMAIN-SUFFIX: matches by domain suffix. Written as DOMAIN-SUFFIX,example.com,Proxy, it matches both example.com itself and any subdomain like www.example.com or api.example.com. This is the most commonly used domain rule type.
• DOMAIN-KEYWORD: matches if the domain contains a given keyword. For example, DOMAIN-KEYWORD,google,Proxy matches any domain containing "google". The matching scope is broad, so watch out for accidentally catching unrelated domains that happen to share the string.
• DOMAIN-REGEX: matches domains using a regular expression. Useful for fine-grained control without listing every domain individually, but it's harder to write and debug — reach for it only when the first three types can't do the job.

2. IP and Subnet Rules

• IP-CIDR: matches an IPv4 CIDR range. For example, IP-CIDR,10.0.0.0/8,DIRECT routes that entire private subnet through a direct connection.
• IP-CIDR6: same syntax as IP-CIDR, but for IPv6 ranges.
• IP-SUFFIX: matches by an IP address suffix segment. This is a niche use case, mostly seen in specific internal network setups.
• SRC-IP-CIDR: matches by the source IP range of the request, commonly used to assign a specific policy to certain devices on a LAN rather than distinguishing by destination address.

IP-based rules are often paired with the no-resolve parameter, especially for direct-connection rules, since direct traffic doesn't need the extra overhead of DNS resolution.

3. Geolocation-Based Rules

• GEOIP: determines the country or region a destination IP belongs to. For example, GEOIP,CN,DIRECT routes traffic identified as mainland China IPs through a direct connection. This relies on an IP geolocation database, so accuracy depends on how up to date that database is.
• SRC-GEOIP: similar to GEOIP, but based on the geolocation of the request's source rather than the destination.

4. Process and Port Rules

• PROCESS-NAME: matches by the name of the process making the connection. For example, PROCESS-NAME,com.example.app,Proxy is useful for assigning a custom policy to a single app — commonly used in mobile configs.
• PROCESS-PATH: matches by the full executable path of the process. More precise than PROCESS-NAME, but also more tedious to configure.
• DST-PORT / SRC-PORT: matches by destination or source port, commonly used to route specific ports (like mail or game-specific ports) through a fixed path.

5. Rule Sets and Fallback

• RULE-SET: references an external rule set file, bundling a large batch of similar rules together so they can be updated via subscription rather than maintaining hundreds or thousands of individual entries by hand.
• MATCH: the fallback rule. It takes no argument — any traffic that hasn't matched an earlier rule ends up here. The format is MATCH,POLICY.

3. Match Priority: Top to Bottom, First Hit Wins

The single most important thing to understand about Clash rules: rules are checked strictly in the top-to-bottom order they appear under rules:. The moment a rule matches, its policy is applied immediately and no further rules are checked. This means a rule's position is itself a form of priority — rule type alone doesn't determine precedence. Whichever type appears first, whether DOMAIN or GEOIP, wins as soon as it's checked and matches.

Here's an example of a common pitfall:

GEOIP,CN,DIRECT
DOMAIN-SUFFIX,example.com,Proxy

If the server hosting example.com happens to have an IP that the geo database identifies as a mainland China IP, this config will route the traffic through the first GEOIP rule and never reach the second, domain-specific proxy rule below it. To make sure a specific domain always goes through the proxy, that domain rule needs to be placed before GEOIP:

DOMAIN-SUFFIX,example.com,Proxy
GEOIP,CN,DIRECT

This ordering issue comes up constantly in configs with lots of rules. When troubleshooting "this site has a proxy rule but isn't using the proxy," the first thing to check is whether a broader rule higher up the list is intercepting it first.

4. Where GEOIP and MATCH Belong

The placement of the GEOIP rule and the MATCH fallback rule are the two spots in a rule list most worth calling out specifically.

GEOIP Should Come After Specific Rules

GEOIP matches based on the country or region a destination IP belongs to, which is a very broad net — a single GEOIP,CN,DIRECT rule can cover thousands of individual domains. Placed too early in the list, it can end up sending services that should be proxied straight to a direct connection instead. The safer approach is to put domain, app, and port rules that need precise control first, then place GEOIP rules after those but before the fallback rule, letting it handle "most local traffic that hasn't been specifically flagged."

MATCH Must Be the Very Last Line

MATCH is the fallback rule — as the name implies, it catches whatever traffic none of the earlier rules handled. It takes no parameters and always follows the format MATCH,POLICY, commonly written as MATCH,Proxy or MATCH,DIRECT depending on your routing preference. If this rule isn't placed last, traffic that should have been handled by more specific rules further down gets swallowed by the fallback policy early, making every rule after it pointless. Think of it this way: once MATCH appears, nothing after it ever runs — so it can only, and must, be the last rule in the list.

5. Ready-to-Use Ordering Recommendations

Building on the mechanics above, a well-structured rule list generally follows a "specific first, broad later, fallback last" pattern, roughly in five layers:

1. LAN and private address ranges routed direct: e.g. IP-CIDR,192.168.0.0/16,DIRECT,no-resolve, so local network traffic doesn't get routed through the proxy unnecessarily.
2. Targeted rules for specific apps and ports: PROCESS-NAME and DST-PORT rules for anything that needs individual control.
3. Domain rules that need particular attention: DOMAIN-SUFFIX and DOMAIN rules for frequently used services, explicitly pointed at a proxy or direct connection.
4. Rule sets and geolocation rules: the bulk of rules pulled in via RULE-SET, plus GEOIP as a catch-all for local traffic.
5. Final fallback: one line of MATCH deciding the default destination for anything that didn't match above.

A simplified example looks roughly like this:

IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
PROCESS-NAME,com.example.updater,DIRECT
DOMAIN-SUFFIX,example.com,Proxy
DOMAIN-KEYWORD,ads,REJECT
RULE-SET,proxy-list,Proxy
GEOIP,CN,DIRECT
MATCH,Proxy

It's worth noting that a rule set (RULE-SET) itself is matched in the order of its internal entries, and where you insert it into the overall list follows the same principle: anything more specific placed earlier gets first crack, and the rule set only gets its turn afterward. If you're referencing multiple rule sets at once, put the narrower, higher-priority ones ahead of the broader ones.

6. Common Ordering Mistakes to Check For

In practice, the vast majority of "rule not working" issues aren't syntax errors — they're ordering problems. Here are the most frequent ones:

• Placing GEOIP,CN,DIRECT before all domain rules, causing every target service that happens to fall on a mainland China IP range to get routed direct instead.
• A DOMAIN-KEYWORD that's too broad and placed too early, accidentally catching other domains that were supposed to go through the proxy.
• Adding rules after MATCH — these rules will never run and are effectively dead configuration.
• Putting a LAN subnet rule that should be direct at the very end, so that traffic gets caught by a broader proxy rule earlier in the list first, slowing down access to local devices.

Instead of re-checking each rule's syntax one by one, a much faster way to troubleshoot is to print out the full rules: list and mentally walk through the matching order line by line — you'll usually spot the earlier rule that's stealing the match right away.