How to Write Custom Clash Rules: DOMAIN-SUFFIX, IP-CIDR, and Rule Order

Rule format: type, match criteria, and outbound policy

Custom Clash rules go in the rules list in your configuration file. When FlClash uses the mihomo core, it checks each rule against the request and applies the specified policy when a rule matches. First, make sure the configuration you want to edit is selected and the outbound mode is set to Rule. Global and Direct modes don't route traffic using this standard rule list.

Most rules use a three-part format: rule type,match criteria,outbound policy. Separate each part with an English comma, and start each YAML list item with a hyphen and a space. Here's an example you can add to an existing configuration:

rules:
  - DOMAIN,login.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,REJECT
  - IP-CIDR,192.168.50.0/24,DIRECT,no-resolve
  - MATCH,DIRECT

• DOMAIN is the rule type and matches an exact domain; login.example.com is the match criterion; DIRECT means a direct connection.
• REJECT blocks the connection. The second line demonstrates blocking; check the domain scope carefully before using it in your configuration.
• no-resolve is an optional fourth parameter for relevant IP rules. It is not a policy name.
• MATCH is the catch-all rule. It has no match criterion, so it contains only two parts.

DOMAIN vs. DOMAIN-SUFFIX: exact domains and domain suffixes

Use DOMAIN when you need to route a single login page, API, or download domain. Use DOMAIN-SUFFIX to cover a base domain and all its subdomains. Both match hostnames, not full URLs from the browser's address bar.

Domain rules don't include a scheme, path, or port

For https://api.example.com:8443/v1/status, the domain rule matches api.example.com, not the full URL. Don't use *.example.com to specify a suffix. Use DOMAIN-SUFFIX,example.com,DIRECT instead.

If you only need to match a port, consider DST-PORT. For example, DST-PORT,8443,DIRECT matches requests to destination port 8443, regardless of domain. To match both a domain and a port, consult the logical rule syntax for your mihomo version; you can't combine the two conditions arbitrarily in a standard three-part rule.

Domain visibility determines whether a rule can match

When a domain is passed through an HTTP or SOCKS proxy, the core can usually see the hostname. With TUN, a connection may initially appear as a destination IP; whether the domain can be recovered also depends on the DNS mode, mapping records, and sniffing settings. If connection details show only an IP, adding a domain rule may not take effect. First check what destination information the client actually detects.

IP-CIDR and no-resolve: address ranges and DNS resolution

Use IP-CIDR for IPv4 ranges and IP-CIDR6 for IPv6. The number after the slash in CIDR notation is the prefix length: 192.168.50.0/24 covers 192.168.50.0 through 192.168.50.255, while 192.168.50.10/32 matches a single IPv4 address. This is not a port range.

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

The IPv6 rule above covers fd00::/8, commonly used for locally assigned ULA addresses. It shows one specific range, not a complete list of private networks to route directly. Adjust it for your LAN, VPN, and remote-work networks. Don't send every address directly if some need a proxy or dedicated tunnel.

What no-resolve actually means

If a request includes a domain but the destination IP isn't available yet, an IP rule may trigger DNS resolution to check whether the address falls within the specified range. Adding no-resolve prevents that rule from triggering a lookup solely for its IP match. If the request already has a destination IP, the rule can still match.

• It does not disable DNS or guarantee that the domain will never be resolved for the connection.
• An earlier rule may already have triggered resolution, or DNS mappings or the inbound connection may already provide the destination IP.
• If you expect a domain to match an IP range based on its resolved address, adding this parameter may cause it to fall through to a later rule instead.

For this reason, LAN IP rules often use no-resolve to avoid extra DNS lookups of external domains just to check a range. For rules that classify traffic based on resolved addresses, first confirm whether this parameter is appropriate.

Rule order: evaluated top to bottom; first match wins

Clash doesn't automatically sort rules by domain length or network size. Standard rules are checked from top to bottom, and the first match determines the policy. A more specific rule can still be masked by a broader rule above it.

rules:
  - DOMAIN,login.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,REJECT
  - MATCH,DIRECT

In this list, login.example.com matches the first rule and goes direct; cdn.example.com matches the second rule and is rejected; unmatched requests reach the final Direct fallback. If you swap the first two rules, the suffix rule will also reject the login domain.

A practical order: exceptions, categories, fallback

1. Specific exceptions: Put special cases, such as a single domain or host IP, before the broader rule they override.
2. Traffic categories: Order domain suffixes, rule sets, and regional or network categories according to the priority you want.
3. Final fallback: Put MATCH at the end of the list to set the outbound policy for all remaining traffic.

If your subscription already includes a full set of rules, don't simply append new rules to the end of the file. Rules after MATCH will never be evaluated. If the client offers prepend, append, or override options, check where rules end up in the merged configuration rather than just counting the lines saved in the editor.

RULE-SET: keep rule criteria separate from outbound policies

As your domain list grows, you can manage rule sets with mihomo's rule-providers and reference them with RULE-SET. The rule set stores the match criteria; the main configuration specifies which policy to use when they match. This example uses a local file so you can validate the structure before setting up a remote update source.

Main configuration: define the provider and add it to the rules list

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

rules:
  - RULE-SET,local-work,DIRECT
  - MATCH,DIRECT

local-work is the rule provider's name and must match wherever it's referenced. Relative paths are based on the core's working directory, which may not be your Downloads folder. On mobile, FlClash is also subject to the app's file access permissions; placing a file in an arbitrary directory doesn't guarantee the core can read it.

Rule-set file: include match criteria only

payload:
  - DOMAIN,portal.example.com
  - DOMAIN-SUFFIX,example.net
  - IP-CIDR,192.168.50.0/24,no-resolve

This is the file content for behavior: classical and format: yaml. Don't include DIRECT or a policy group name on each line; the main configuration's RULE-SET,local-work,DIRECT sets the outbound policy for the whole rule set. Don't copy full three-part standard rules into this file.

• Use behavior: domain for a domain collection; its content format differs from the classical example above.
• Use behavior: ipcidr for an IP range collection. Don't mix in standard domain rules.
• For an HTTP provider, configure a reachable url. You can set interval: 86400 to update it every 86,400 seconds (24 hours).

Updating a rule set and updating a subscription are separate operations. A subscription update refreshes the main configuration; a rule provider update refreshes its rule data. If a rule set fails to load, check the provider error log and file format first. Repeatedly refreshing the subscription won't fix a malformed rule file.

FlClash setup and testing: check the active configuration and new connections

To verify that custom rules are working, check the configuration actually loaded by the core and the connection records. The names of edit or override options can vary by client version. Start on FlClash's Configuration page and confirm which profile is selected, then check its action menu for available editing options. Only use an editing option that's actually available, and separately confirm how changes persist across subscription updates.

1. Back up the original configuration: Export or copy the current configuration and note the existing outbound mode and policy group selections. A remote subscription update may overwrite direct edits.
2. Add a few rules at a time: Start with one exact-domain rule and place it before related broad rules and MATCH. If rules already exists, merge into that list instead of adding a duplicate top-level key.
3. Apply the changes and check logs: After saving, reload the configuration using the client's available method. If you see a parse error, unknown policy, or file read error, fix it before testing.
4. Test with a new connection: Close the existing page or relevant connections, then make a new request. HTTP/2, HTTP/3, and app connection pools may reuse existing connections; adding a rule doesn't automatically select a new outbound for an established connection.
5. Check connection details: On the Connections page, inspect the destination host, destination IP, matched rule, and outbound chain. Fields vary by version, so use the logs to verify the rule type and policy name as needed.

TUN routes more app traffic into the core; rules classify requests that reach it. Turning on TUN doesn't raise a rule's priority. If the target request never appears in the connection list, check traffic capture, the app's own proxy settings, and routing before changing the rules further.

Common rule mistakes: diagnose by symptom

Rule matches, but the connection still fails

A rule match only confirms that routing was decided; it doesn't guarantee the destination is reachable. Direct connections still depend on your network and DNS, proxy policies depend on the selected node, and REJECT actively blocks the connection. If connection details show the expected policy, troubleshoot that outbound path instead of adding more rules for the same traffic.

When maintaining rules, add a YAML comment explaining why each exception exists, and remove obsolete entries regularly. Prefer exact domains, smaller IP ranges, and an explicit fallback policy. For the client setup process, see Getting Started. To review rules, policy groups, and TUN concepts, see Protocol Guide.