A Guide to Using rule-providers (Rule Sets)

Want to block ads? You could hand-write hundreds of ad domains into rules — or you could skip all that. Rule sets (rule-providers) let you subscribe to rules the same way you subscribe to nodes: community-maintained, updated on a schedule, and your config file only needs a single line to reference the whole thing.

What is a rule set?

A normal rule is written directly into rules, and each line handles one match. A rule set instead bundles hundreds or thousands of related rules into an external file that Clash periodically fetches and refreshes. The two pieces work together:

• The rule-providers section declares which rule packages exist, where to download them from, and how often to refresh them.
• The rules section references an entire package in one line using RULE-SET,name,target.

Declaring a rule set

rule-providers:
  reject-ads:
    type: http
    behavior: domain
    url: "https://example.com/ruleset/reject.yaml"
    path: ./ruleset/reject.yaml
    interval: 86400       # refresh once a day

  local-direct:
    type: http
    behavior: domain
    url: "https://example.com/ruleset/direct.yaml"
    path: ./ruleset/direct.yaml
    interval: 86400

  telegram-cidr:
    type: http
    behavior: ipcidr
    url: "https://example.com/ruleset/telegram.yaml"
    path: ./ruleset/telegram.yaml
    interval: 86400

Here's what each field means:

Referencing it in rules

rules:
  - RULE-SET,reject-ads,REJECT       # thousands of ad domains, one line
  - RULE-SET,local-direct,DIRECT
  - RULE-SET,telegram-cidr,Proxy Select
  - GEOIP,US,DIRECT
  - MATCH,Proxy Select

Order still matters: put blocking rule sets first, direct-routing rule sets next, and always leave the catch-all MATCH for last.

Which behavior should you pick?

The three formats have different matching performance under the hood, so picking the right one keeps things fast:

• domain: use this when everything is a plain domain. Clash builds a prefix tree internally, so matching stays in the microsecond range even with tens of thousands of entries.
• ipcidr: use this when everything is an IP range — backed by an efficient trie structure.
• classical: use this only when the file mixes DOMAIN, IP-CIDR, PROCESS-NAME, and other rule types together — flexible, but the most expensive to match.

What to do when a rule set fails to update

Since rule sets depend on an external download, updates occasionally fail. Work through it in this order:

• Check the local cache first: if the file at path already exists, Clash falls back to the last known-good version rather than breaking the whole rule set over one failed update — so you might not even notice anything went wrong. That's exactly why it's worth periodically checking the last update time yourself.
• Check whether the download URL is still valid: community rule sets occasionally move repositories or change paths. Open the url directly in a browser to see if it still resolves; if not, check the rule set's project page for the current address.
• Make sure interval isn't set unreasonably low: setting it to a few dozen seconds can trigger rate-limiting on the source and cause updates to fail more often, not less. For everyday use, 43,200 to 86,400 seconds (12-24 hours) is plenty.

Where to find popular rule sets

You don't need to build a rule set from scratch — there are several well-maintained, highly-starred rule set repositories on GitHub covering ad blocking, keeping local/trusted traffic direct, unblocking streaming services, routing specific apps, and more. Searching "clash rule providers" or "ruleset" will turn up most of them. When picking one, check two things: is it still being actively updated, and does its behavior type match how you plan to reference it. A rule set and the Clash client are two separate things — the rule set decides "how to route," while Clash handles "how to connect and schedule." The two work together to give you something both clean and functional.

Once you wire in an ad-blocking rule set, a lot of the annoying banner ads on websites simply disappear at the source — even less hassle than installing a browser extension, since this blocks at the network level and applies to every device and app at once.

How to combine hand-written rules with rule sets instead of choosing one or the other

A lot of people delete all their hand-written rules the moment they adopt rule sets, but that's not necessary. The two serve different purposes: rule sets are great for handling things that are large in number, change frequently, and aren't realistic to maintain yourself — thousands of ad domains, or streaming-service IP ranges that shift over time. Hand-written rules are better suited to small numbers of entries where you care a lot about priority and want precise control — your company's internal domains, or a handful of specific sites you use often.

A good pattern is: put your personal hand-written rules first so they always take priority, follow them with rule sets for bulk, general-purpose categories, and finish with GEOIP,US,DIRECT (or your relevant region code) and MATCH as the catch-all. That keeps your flexibility intact without bloating your config to thousands of lines just to cover a few hundred ad domains — and maintenance overhead drops significantly.

A detail beginners often miss: rule order really does change the outcome

Rules are matched top to bottom, and the first match wins — everything after it is simply never evaluated, no matter how correctly it's written. So if you find that a site "has a rule configured but it's not taking effect," the rule itself probably isn't wrong — a broader rule earlier in the list (often a generic entry inside a rule set) is catching it first. The fastest way to debug this is to open the Connections tab in the dashboard and look at exactly which rule that connection actually matched, rather than guessing from the config file alone — a tip also covered in our dashboard guide, and the two approaches work well together.

Summary

Rule sets hand off the tedious job of maintaining rules by hand to the community and automatic updates — all you need to do is declare the source, pick the right behavior, and reference it in the right order. Remember three key points: blocking rules go first, direct-routing rules right after, and MATCH always brings up the rear; behavior should match the actual content format of the rule set, or matching gets slower or even breaks; and if an update fails, check whether the local cache is still serving requests before troubleshooting the download URL or interval. Once it's set up, there's almost nothing left to maintain by hand — the rule set stays fresh on its own through community updates.

If your config file is still cluttered with hundreds of hand-written domain rules, it's worth setting aside half an hour some weekend to replace what you can with rule sets — your config will get noticeably cleaner, and it'll be far less of a burden to maintain going forward.