Clash Custom Rules: Syntax, Priority, DOMAIN, IP-CIDR & MATCH

Rule Matching Order: Top to Bottom, First Match Wins

In rule mode, the Clash client checks connections against the rules list in your configuration, from top to bottom. The first matching rule selects a policy, and no later rule is checked—even if it would be a more specific match. Rule order determines priority; there is no universal rule that DOMAIN always outranks IP-CIDR.

The examples below assume your configuration already has a proxy group named "Proxy Select." This name must exactly match the name under proxy-groups. The example domain example.com is for demonstrating syntax only; it does not imply that traffic to this site should use any particular policy.

mode: rule

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

• Request to api.example.com: the first rule matches and sends it to "Proxy Select."
• Request to www.example.com: the first rule does not match, so the second rule matches and sends it to DIRECT.
• Requests to any other destination that does not match the first two rules are handled by the final MATCH rule.

If you move the second rule above the first, api.example.com will match the suffix rule first and go direct. The exact-domain rule below it will never be checked, even if written correctly. When maintaining rules, define exceptions first, then add broader rulesets.

DOMAIN Rules: Exact Domains, Suffixes & Keywords

A domain rule typically has three fields: rule type, match value, and target policy. The value is a domain, not a full URL: leave out https://, ports, paths, and query parameters. To match https://api.example.com/v1/status, use api.example.com rather than the full address.

Put Domain Exceptions Before Suffix Rules

rules:
  - DOMAIN,download.example.com,Proxy Select
  - DOMAIN-SUFFIX,example.com,DIRECT
  - DOMAIN-KEYWORD,telemetry,REJECT
  - MATCH,Proxy Select

This order gives the download domain its own route before applying the broader domain suffix. The keyword rule comes after the suffix rule, so telemetry.example.com will match the example.com suffix first and go direct, even though its name contains the keyword. To block it, put an exact reject rule earlier; REJECT does not automatically get the highest priority.

Keep Keyword Rules Narrow

DOMAIN-KEYWORD,ad,REJECT can match short strings in many legitimate domains and cause false positives. Use DOMAIN when you know the full domain, and DOMAIN-SUFFIX to cover a set of subdomains. Keyword rules are best reserved for targets with a consistent naming pattern whose match scope you have verified.

Domain rules require a usable domain in the connection metadata. If an app connects directly to an IP, uses a different DNS path, or domain sniffing is not working, the connection record may contain only the destination address. Seeing a domain in the browser address bar does not guarantee that the core can match the corresponding DOMAIN rule.

IP-CIDR and no-resolve: Control When DNS Resolution Runs

IP-CIDR matches destination IPv4 address ranges; IPv6 usually uses IP-CIDR6. The number after the slash is the network prefix length: IPv4 /32 represents a single address, while 192.168.1.0/24 covers 192.168.1.0 through 192.168.1.255.

rules:
  - IP-CIDR,192.168.1.10/32,DIRECT,no-resolve
  - 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
  - IP-CIDR6,fc00::/7,DIRECT,no-resolve
  - MATCH,Proxy Select

no-resolve prevents the rule from triggering a DNS lookup solely to check an unresolved destination against an IP range. It does not "turn off DNS" or "keep all domain traffic from matching this rule." If the destination IP is already available, the core can still match the range. If no usable IP is available, the rule will not trigger a lookup just to make the match.

Two Different Connection Paths

1. The app connects directly to 192.168.1.10:443: the destination IP is known, so it can match a single-address rule. no-resolve does not prevent this match.
2. The app requests nas.example.com: if the core does not yet have a usable destination IP, a range rule with no-resolve will not resolve the domain. The connection may continue to later rules.

If this NAS domain must go direct, add a separate rule such as DOMAIN,nas.example.com,DIRECT rather than relying on an IP check that may never run. For domains that need routing based on their resolved IP, review your DNS configuration and decide whether to remove no-resolve from the relevant rule.

With fake-IP enabled, the synthetic address shown by the client is not the website's real server address. Check connection details, domain mappings, and DNS logs together. Do not add the entire fake-IP pool to direct rules to fix a single website.

Policies and MATCH: Choosing an Exit and Setting a Fallback

The final field in a rule specifies a policy, not necessarily an individual proxy node. DIRECT routes traffic directly; REJECT blocks it. A custom name can refer to a defined proxy or proxy group. When a rule selects "Proxy Select," the actual route depends on the member currently selected in that group.

A connection can show that it matched a proxy group yet still go direct; that does not necessarily mean the rule failed. Check whether the group has selected DIRECT, whether traffic passes through another group that includes DIRECT, and what the current result is for any automatic-selection group. Rule matching and the final route are two related but distinct steps.

rules:
  - DOMAIN,blocked.example.com,REJECT
  - DOMAIN,intranet.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,Proxy Select
  - MATCH,Proxy Select

Keep MATCH as the Fallback

MATCH takes no domain or network argument; its syntax is simply MATCH,policy. It matches every connection that reaches that line. Put it first and none of the rules below it will run; place it between two rulesets and the second ruleset will never be checked.

• To send uncategorized traffic to a proxy group, use MATCH,Proxy Select.
• To send uncategorized traffic directly, use MATCH,DIRECT.
• To allow only explicitly listed connections, you can use MATCH,REJECT—but add all required dependencies first, or logins, updates, and resource loading may be blocked too.

Changing the fallback policy can affect a large amount of uncategorized traffic. Save your current configuration first, then test the full workflow—not just whether the website's home page loads.

mihomo Rulesets: Position Still Determines Priority

mihomo lets you manage rulesets with rule-providers and reference them using RULE-SET. Rulesets do not have a separate priority system outside the main list: a RULE-SET is checked at the position where it appears. If an earlier rule matches, later rulesets are skipped.

Here is a mihomo snippet for a local file ruleset. Merge it into your existing configuration and keep your current nodes and "Proxy Select" group. Make sure ./rules/work.yaml exists relative to the core's configuration working directory; declaring the file without creating it is not enough.

rule-providers:
  work:
    type: file
    behavior: classical
    format: yaml
    path: ./rules/work.yaml

rules:
  - DOMAIN,login.example.com,DIRECT
  - RULE-SET,work,Proxy Select
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,Proxy Select

The contents of work.yaml are shown below. The RULE-SET reference supplies the policy, so entries in the classical ruleset do not need to include "Proxy Select":

payload:
  - DOMAIN-SUFFIX,example.com
  - IP-CIDR,203.0.113.0/24

203.0.113.0/24 is a documentation example range, not a destination range for production use. Use the network range supplied for your own setup. Here, login.example.com matches the first rule in the main list, so it goes direct even though it also belongs to a domain suffix in the work ruleset.

The behavior Must Match the File Contents

• classical: entries include rule types such as DOMAIN-SUFFIX and IP-CIDR, making it suitable for mixed rules.
• domain: entries are domain match values; do not copy classical entries with their rule-type prefixes as-is.
• ipcidr: entries are IP ranges, not a list of domains.

These examples use mihomo syntax. Support for ruleset formats and extended rule types varies across Clash cores, so check the core version shown in your client and validate the configuration. A matching filename does not mean an older core can parse every field.

Ordering Custom Rules and Handling Subscription Overrides

As your rule list grows, organize it as "specific exceptions → categories → fallback" instead of continually appending rules at the end. The order below is a practical starting point; whether reject rules belong at the top depends on which exceptions your setup allows.

1. Exact rules that must override other categories. For example, send a single login domain direct or reject a specific tracking domain. When rules conflict, decide explicitly which one should match first.
2. Local services and LAN destinations. Use domain rules for known domains and IP rules for known ranges, and confirm whether resolution should be triggered.
3. Categories and rulesets. Group traffic by work, media, or other use cases. If rulesets overlap, put the higher-priority category first.
4. Broad domain, region, or IP categories. Wide-ranging rulesets can shadow later exceptions, so sample-test matches after changing their order.
5. MATCH as the final rule. Set the route for uncategorized connections, and put no rules that need to run after it.

Subscription updates may regenerate the main configuration. Direct edits to subscription-generated YAML can be lost on the next update, even if they work now. If your client supports overrides, merging, or persistent custom rules, use that feature. Menu names and locations vary by client, so do not assume a particular UI path applies to every Clash client.

Pay particular attention to the difference between appending and placing rules first. If custom rules are appended after a subscription's existing MATCH, they will be present but can never match. Check the final rules list loaded by the core to confirm the merged order, rather than relying on the snippet in the editor.

Rules Not Taking Effect? Check the Connection Log Step by Step

Change one condition at a time while troubleshooting. Start with a specific target such as api.example.com, note the expected policy, then check the matched rule and final route for a new connection. Browsers may reuse existing persistent connections, so reloading a page does not always create a new connection.

1. Confirm traffic reaches the core. The system proxy covers only apps that follow system proxy settings. Connections that never reach the core are not controlled by rules; TUN routing must also cover the traffic in question.
2. Confirm the active configuration and mode. Check that the edited configuration is loaded, that the active mode is Rule, and that switching subscriptions has not loaded a different configuration.
3. Check for parsing errors. YAML uses spaces for indentation, not tabs. Verify rule type spelling, comma counts, and policy names. Merge duplicate top-level rules keys into a single list.
4. Check for an earlier match. Look for an overlapping DOMAIN-SUFFIX, keyword, RULE-SET, or an earlier MATCH. The rule shown in the log is more useful than the one you expected to match.
5. Check the destination metadata. See whether the record contains a domain or an IP address, whether it is IPv6, and whether a resolved address is available. An IPv4 range rule cannot be expected to match an IPv6 destination.
6. Start a fresh test connection. If it is safe to interrupt, close the existing connection or quit and reopen the test app, then check the new rule match in the log.

A maintainable rule configuration should answer three questions: why the destination matched this rule, which policy the rule selected, and which route that policy ultimately used. Verify each step separately to see how DOMAIN, IP-CIDR, rulesets, and MATCH apply to an actual connection—not just their apparent order in the configuration.