If you've hand-written hundreds of DOMAIN-SUFFIX lines inside rules, you're almost certainly doing it the hard way. Rule providers let you package these common categories into standalone files that update on a schedule, keeping your main config clean.
What are rule-providers
Simply put, a rule provider is a rule list hosted elsewhere — a local file or a remote URL — that Clash fetches and loads on a schedule. You reference it with a single RULE-SET line in rules instead of stuffing hundreds of entries into your main config.
The behavior field: three rule set formats
| behavior | Content Format | Common Use |
|---|---|---|
| domain | Domain / domain-suffix list | Ad blocking, streaming routing, social-platform domain sets |
| ipcidr | IP range list | Local IP ranges, direct-connect for specific data-center IPs |
| classical | Full rule syntax (with type prefix) | Mixed types, scenarios needing precise match control |
behavior must match the actual content format of the rule set file — a mismatch will cause the rule set to fail loading or match incorrectly, so always follow the format the rule set source specifies.
type: http or file
- http: Fetched from a remote URL on a schedule — good for rule sets maintained by the community.
- file: Reads a local file only, no auto-update — good for rules you maintain yourself.
Common rule set sources
The community maintains a number of long-running open-source rule set projects covering ad blocking, direct-connect, streaming routing, and social-platform categories. Pick a few that fit your needs and combine them instead of writing everything from scratch.
How to combine common rule set categories
If you're not sure which rule sets to bring in, organize them by priority, highest to lowest: handle ad/tracker blocking first (to avoid unnecessary connections), then anything that must connect directly (local/LAN addresses), then streaming and social platforms that need special routing, and finally a catch-all direct-connect rule for local IP ranges — everything else falls through to the proxy by default. The logic behind this order: narrow, unambiguous rules go first, and vague catch-alls go last, so broad rules don't accidentally intercept traffic that should have matched something more precise.
Maintaining your own private rule set
Internal company services or niche sites you use personally are unlikely to be covered by any community rule set. That's exactly the case for type: file — build a locally maintained rule file in the same format as a remote rule set, except it won't auto-update from the network and you edit it by hand:
Put your company VPN or internal admin-console domains into this private rule set — your main config stays clean, and you don't have to worry about it getting overwritten by public rule set updates.
How to set up auto-updates
The interval field controls the update frequency, in seconds. A common approach is a short interval (like one day) for fast-changing rule sets such as ad blocking or streaming routing, and a longer interval (like one week) for relatively stable ones.
Rule sets still respect match order
Just like regular rules, RULE-SET references follow "top to bottom, stop at first match." If a broad rule set sits near the top, a more specific rule further down may never get matched — when debugging, check rule order first.
How to troubleshoot a rule set that fails to load
Rule set errors usually show up in one of a few ways: a core startup error, a "rule set download failed" message in the panel/logs, or rules that appear loaded but never actually match. Work through these in order:
- Check whether the URL is reachable: open the
urlfield's address directly in a browser and confirm it returns plain text content, not a 404 or an authentication prompt. - Verify behavior matches the file format: open the downloaded local rule file and check its content format against the configured
behavior(domain/ipcidr/classical). - Confirm the path's directory is writable: the core caches remote content locally at the
pathyou specify — if the directory isn't writable, updates will fail. - Check that the reference name matches exactly: the name defined under
rule-providersmust exactly match the name inRULE-SET,name,...underrules— any case or spelling mismatch causes the rule to be silently ignored.
Should you manually clear the rule set cache
Normally, no. The core automatically checks whether the cache has expired based on interval and re-fetches as needed, without manual intervention. But if you suspect the locally cached rule file is corrupted (say, a download was interrupted last time) or the source changed its content format in a way that broke parsing, you can manually delete the local file at path — restarting the core will trigger a full fresh download, effectively forcing a cache refresh.
Do rule sets slow down startup
Once you add rule sets, the core needs extra time to download and parse them on every startup (or whenever the cache expires and needs refreshing) — more rule sets, or larger individual files, mean longer startup time. For most home-use scenarios this delay is barely noticeable; but if you're running the core on a resource-constrained device (like a low-power router) while loading a large number of rule sets, consider extending interval to reduce unnecessary re-downloads and keep the update frequency to only what's actually needed.
Summary
Compared to hand-written rules, the biggest value of rule sets is "decoupling" and "auto-update": your main config keeps only a handful of custom rules and proxy-group structure, while the tedious domain/IP categorization is maintained by external rule sets — cutting a lot of repetitive work and making long-term maintenance much easier.