Rule Provider in Practice: Say Goodbye to Hand-Writing Hundreds of Routing Rules

What Problem Does Rule Provider Solve

A rule set is really just a "domain/IP to action" mapping table, and the community has long since organized common categories (ad domains, everyday sites, various streaming platforms) into publicly maintained, continuously updated rule files.

rule-providers lets Clash download that rule file directly from a remote URL and refresh it automatically on a schedule you set — you only need to reference it once in your config, without maintaining hundreds or thousands of rules yourself.

Three Rule Set Types

There's also a format field that decides the file format — commonly yaml, or the smaller and faster-to-parse mrs (mihomo's binary rule set format).

Real Configuration Example

rule-providers:
  reject:
    type: http
    behavior: domain
    url: "https://example.com/rules/reject.txt"
    path: ./ruleset/reject.yaml
    interval: 86400
  direct:
    type: http
    behavior: classical
    url: "https://example.com/rules/direct.txt"
    path: ./ruleset/direct.yaml
    interval: 86400

rules:
  - RULE-SET,reject,REJECT
  - RULE-SET,direct,DIRECT
  - MATCH,PROXY

A few key fields:

• interval: how often the rule set auto-refreshes, in seconds. Rule set content changes over time, so around one day (86400) is usually plenty — no need to refresh too often.
• path: the local cache path. Once downloaded, the rule set is stored locally, so a client restart doesn't require re-downloading it.
• RULE-SET,name,action: references a rule set by name inside rules. The action can be DIRECT, REJECT, or the name of a proxy group.

Where Rule Sets Come From

You don't need to write rule sets yourself — the community already maintains a number of well-organized, long-running public projects covering categories like direct-connect for everyday sites, ad blocking, popular streaming platforms, common AI services, and more; these have become something of a "standard dependency" when building a config file. When choosing a rule set source, focus on two things:

• Is it actively updated? Domains and IP ranges keep changing, and a rule set that hasn't been updated in months gradually becomes inaccurate — check the repository's recent commit history to judge this.
• Is it granular enough? Some rule sets maintain "everyday direct-connect sites" and "ad blocking" as separate files, so you can reference only what you need instead of being forced to download one giant all-in-one file.

Automatic Updates vs. Forcing a Manual Refresh

interval controls how often the Clash core checks for updates while running in the background — but it won't force a refresh the instant you change your config and restart the client. If a rule set file is already cached locally (the one path points to), the core defaults to using that local cache until the next interval comes around.

This matters in two specific situations:

1. You just switched a rule set's URL from A to B but forgot to update path along with it — the core may still be reading the old cache file at that path, creating the illusion that "the config changed but nothing happened."
2. The rule set maintainer just fixed an obvious false-positive block and you want the latest version right away — in that case, just delete the local cache file that path points to and restart the client to trigger a forced re-download.

Most clients with a Dashboard also offer an "update rules" button that does the same thing as manually deleting the cache and restarting — more convenient for everyday use.

Rule Sets vs. Hand-Written Rules: What About Performance?

Some worry that "downloading tens of thousands of rules will slow down matching." In practice, the core preprocesses rule sets when loading them (for example, organizing domain rules into a prefix-tree structure), so per-rule matching overhead doesn't scale linearly with the number of rules — anywhere from a few thousand to tens of thousands of rules has essentially no perceptible latency impact on modern hardware.

What actually affects perceived speed is the order rules are arranged in — the higher up a frequently-matched rule sits, the fewer average comparisons it takes. That's why it's worth putting commonly-used direct-connect rule sets near the top, rather than tacking them onto the end of the rule list without thinking about it.

Practical Tips

1. Don't stack too many rule sets from different sources at once — the same domain can end up getting judged differently by overlapping rule sets, producing inconsistent behavior. One actively-maintained rule set per need category is usually enough.
2. If a rule set causes a problem (say, it wrongly blocks a legitimate site), check whether the rule set itself is at fault before assuming your own config is wrong — try temporarily commenting out the specific RULE-SET line to isolate the issue.
3. Streaming-unlock rule sets tend to update the most frequently (since platforms constantly shuffle their IP ranges and domains), so it's reasonable to set a shorter interval for those — say 43200 (12 hours).
4. Periodically review the list of rule sets you reference and remove categories you no longer need — a leaner config is much easier to debug when something goes wrong.

For the full rule syntax and priority details, see the Rule Engine section of the Advanced Configuration guide.