Aug 24, 2026 · Advanced Rules · 12-minute read

Clash Custom Rules: DOMAIN-SUFFIX, IP-CIDR, RULE-SET, and Match Order

Learn Clash rule syntax and first-match order, and see how placing custom rules before or after subscription rules changes routing.

Rule Matching Order: Top to Bottom, First Match Wins

If a site you set to bypass the proxy still goes through it, the usual culprit isn’t the rule type—it’s an earlier rule that matched first. Clash’s rules is an ordered list. The core checks rules from the top and applies the first matching rule’s outbound policy; it doesn’t continue looking for a “more specific” match.

The core is the program that handles connections and routes traffic. Clash Meta continues development under the name mihomo; a client is the interface for managing subscriptions, toggles, and connection logs. The examples below use common mihomo YAML configuration. YAML represents structure through indentation: use spaces, never tabs.

Specific rules don’t get automatic priority

rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - DOMAIN,docs.example.com,DIRECT
  - MATCH,PROXY

When you visit docs.example.com, the first suffix rule matches, so the connection uses PROXY. The second rule is more specific, but it never gets a chance to run. To connect directly to the documentation site, move the second rule above the first.

In this article, PROXY is an example policy group name, not a built-in keyword available in every configuration. Replace it with a policy group that exists in your configuration, matching its capitalization and spacing. DIRECT is the built-in direct-connection policy, and REJECT is the built-in reject policy; both can be used as shown.

DOMAIN vs. DOMAIN-SUFFIX: Exact Domain and Suffix Matching

A common rule format is “type, match value, target policy,” with fields separated by English commas. Domain rules take a hostname only—no https://, path, query string, or trailing slash. In a web address, /account isn’t part of the domain.

Rule type	Example	What it matches
DOMAIN	`DOMAIN,docs.example.com,DIRECT`	Matches this hostname only, not its subdomains.
DOMAIN-SUFFIX	`DOMAIN-SUFFIX,example.com,PROXY`	Matches example.com and all of its subdomains.
DOMAIN-KEYWORD	`DOMAIN-KEYWORD,example,PROXY`	Matches connections whose domain contains example; this is broader than a suffix rule.

Suffix rules respect domain boundaries

DOMAIN-SUFFIX,example.com,PROXY matches example.com, api.example.com, and a.b.example.com, but not notexample.com. There’s no need to write *.example.com or add a dot before the match value.

To send only the login hostname direct, use DOMAIN,login.example.com,DIRECT. Use DOMAIN-SUFFIX when an organization’s entire subdomain tree needs the same outbound policy. Keyword rules are for cases that genuinely need broad matching; don’t use them as a catch-all replacement for domain suffix rules, or unrelated sites may be routed along with the intended ones.

IP-CIDR and no-resolve: Route by Destination Address

IP-CIDR matches IPv4 destination ranges. CIDR notation combines an address with a prefix length. For example, 192.168.50.0/24 covers addresses from 192.168.50.0 through 192.168.50.255—not just the single address shown. Use /32 to specify a single IPv4 address.

rules:
  - IP-CIDR,192.168.50.0/24,DIRECT,no-resolve
  - IP-CIDR,10.20.30.40/32,DIRECT,no-resolve
  - IP-CIDR6,fd00::/8,DIRECT,no-resolve
  - MATCH,PROXY

The IP-CIDR6 entries above are for IPv6. These three address ranges are examples; adjust them to match your actual LAN. Avoid adding an overly broad range to the direct-connection list, or traffic you intended to proxy may bypass it.

no-resolve doesn’t disable DNS

DNS resolves domain names to IP addresses. For a connection with a domain but no destination IP yet, an IP rule may trigger a lookup to check for a match. Adding no-resolve at the end tells the rule not to resolve the domain just to test that rule. If the connection already has a usable destination IP, it can still match.

So no-resolve doesn’t disable DNS for the entire client or automatically let a domain bypass the proxy. To always connect directly to a particular site, start with a domain rule; to connect directly to a range of private network addresses, use an IP rule. How the domain is obtained, the DNS mode, and sniffing settings all affect what information the core has. When troubleshooting, check connection details—not just the browser’s address bar.

RULE-SET: Reference a Rule Set Without Changing Match Order

RULE-SET references a rule provider. The provider loads a set of domains or addresses; the reference in rules determines which policy applies when an entry matches. The set name, provider type, and file contents must agree. Adding a reference alone won’t create the rule set.

Example: Local Domain Rule Set

This is a configuration snippet to merge into an existing setup, not a complete subscription you can run on its own. First make sure your configuration has a policy group named PROXY, then merge the provider and rules into their respective top-level fields.

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

rules:
  - DOMAIN,login.example.com,DIRECT
  - RULE-SET,work-domains,PROXY
  - IP-CIDR,192.168.50.0/24,DIRECT,no-resolve
  - MATCH,PROXY

Next, create rules/work-domains.yaml in the working directory used by the core. The relative path is based on the core’s actual working directory, which may differ from the installation directory. The file can contain:

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

In this domain set, example.com represents that domain, while +.example.org represents example.org and its subdomains. Because the provider’s behavior is domain, put domain match values here—not a full rule such as DOMAIN-SUFFIX,example.org,PROXY.

domain, ipcidr, and classical: What’s the Difference?

domain: The set uses domain-matching syntax, making it suitable for lists of domains.
ipcidr: The set contains IP address ranges, such as 192.168.50.0/24.
classical: The set uses rule types and match conditions, such as DOMAIN-SUFFIX,example.org. The outer RULE-SET specifies the outbound policy, so don’t append a policy group to each entry in the set.

Remote providers also need settings such as a URL and update interval. If you use a remote set included with a subscription, first check that it loaded successfully, then check match order. A failed download, invalid file format, or misspelled set name is a different problem from an earlier rule matching first.

Should Custom Rules Go Before or After Subscription Rules?

Updating a subscription usually regenerates its configuration. Direct edits to a downloaded YAML file may be overwritten on the next update. A safer approach is to use the client’s persistent override or rule-merge feature. An override stores your changes separately from the subscription’s original configuration and combines them when enabled to produce the core’s configuration.

Menu names, merge direction, and scripting interfaces vary between clients. Don’t assume a rule is active just because it was “added.” Check where it appears in the final configuration: prepended, appended, or replacing the existing rules. For basic interface instructions, see the user guide.

Recommended order: exceptions first, rule sets next, fallback last

rules:
  # Custom exceptions: evaluate first
  - DOMAIN,docs.example.com,DIRECT
  - DOMAIN,blocked.example.net,REJECT

  # Existing subscription rules: position shown for illustration
  - DOMAIN-SUFFIX,example.com,PROXY
  - RULE-SET,work-domains,PROXY
  - IP-CIDR,192.168.50.0/24,DIRECT,no-resolve

  # Handle connections not matched above
  - MATCH,PROXY

MATCH is a catch-all rule and doesn’t need a match value. Any connection that reaches it uses its target policy. If the client appends custom rules after an existing MATCH, those rules will never run. Prepend your custom rules or insert them before the final catch-all instead of repeatedly adding duplicates.

Rules Not Working? Check the Connection Log Step by Step

After changing rules, reload the configuration, close existing connections from the target app, and make a fresh request. Browsers may reuse established connections, which typically won’t switch to a new outbound policy just because the rules changed. For easier comparisons, change only one or two rules at a time.

Check the active configuration and mode. Confirm which subscription is enabled and that the client is in Rule mode. Editing an inactive configuration won’t affect current traffic.
Confirm traffic reaches the core. Open the client’s Connections page and search for the target domain or IP. If there’s no entry, check the system proxy, the app’s own proxy settings, and the traffic covered by TUN.
Check which rule matched. In the connection details, look for the rule type, match value, and policy chain. Field names vary by client; the key is to identify the rule that actually matched.
Check the final rule order. If a broad suffix rule or rule set matched, move the more specific exception above it. If MATCH matched, verify that the rule set’s contents and provider actually match the connection.
Make sure the outbound route is what you expect. A PROXY match only hands the connection to that policy group. If the group currently selects DIRECT, the connection still goes direct.
Update the subscription once, then test again. Make sure your custom rules are still there and haven’t moved. This catches changes that worked temporarily but disappeared after an update.

Verify Rule Order with Three Requests

Using the domain examples above: visit docs.example.com and expect the exact-domain rule to match and connect directly; visit api.example.com and expect the suffix rule to match and use PROXY; then visit a destination not covered by any other rule and expect it to fall through to MATCH. These domains illustrate how the rules interact. For real testing, use reachable domains whose purpose you’ve verified.

A single page may also request separate hosts for login, images, video, and APIs. A rule for the main site doesn’t mean all its resources will use the same outbound route. If the page loads but images don’t, find the failed resource’s domain in the connection log, then decide whether to add an exact rule or broaden the suffix match.

Common Rule Questions

Which takes precedence when DOMAIN-SUFFIX and IP-CIDR both match?

In most cases, the rule that appears first in the list wins; there’s no fixed rule that domains always take priority over IP addresses. Also check whether the connection has the domain or IP information needed to evaluate the rule, and whether no-resolve prevented a lookup for that rule. Putting explicit domain exceptions first generally makes the configuration easier to understand and maintain.

Do I still need custom rules when using TUN?

That depends on how you want to route traffic. TUN captures traffic through a virtual network interface; it doesn’t introduce a new match priority. Once traffic reaches the core, Rule mode still selects a policy based on rule order. If a LAN destination can’t connect at all, also check routing, TUN exclusions, and the firewall.

Why didn’t a REJECT rule block the webpage?

First check whether an earlier rule allowed the domain, then confirm whether the page uses other resource domains or an existing connection. REJECT affects only connections that actually match it; it doesn’t identify an entire service by the page title. Reconnect after making changes and use the match shown in connection details to verify the result.

When maintaining rules, keep the number of exceptions small and give each a clear purpose. For every change, record what it matches, which policy handles it, and where it sits in the list, then verify it in the connection log. Check traffic capture, rule matching, and policy-group routing separately to pinpoint most cases where a rule seems to have no effect.