Rule Provider in Practice: Auto-Update Your Rule Sets, Ditch Manual Maintenance

Why Bother With Rule Provider

You can absolutely paste a few hundred DOMAIN-SUFFIX lines straight into the rules list and have it work — but the maintenance cost adds up fast. Whenever the rule set's author pushes an update, you have to sync it manually, and once the rule count grows, the config file becomes genuinely hard to read. Rule Provider splits that content out into a separate remote file that the client re-fetches on a schedule you define, leaving the actual maintenance of the rule set to whoever publishes it — all you do is reference it by name inside rules.

Three behavior Types — Don't Pick the Wrong One

The field most people get wrong when defining a Rule Provider is behavior, which tells the client how to parse the rule set's content:

• domain — the rule set is a plain list of domains (one per line), equivalent to DOMAIN-SUFFIX semantics;
• ipcidr — the rule set is a list of IP ranges (one CIDR per line), equivalent to IP-CIDR semantics;
• classical — the rule set contains full rules (each line carries its own rule type, matching the exact format you'd hand-write in rules). Most flexible, but also the largest file size.

A Complete Configuration Example

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

  local-ip:
    type: http
    behavior: ipcidr
    url: "https://example.com/rules/local-ip.txt"
    path: ./rules/local-ip.txt
    interval: 86400

rules:
  - RULE-SET,reject,REJECT
  - RULE-SET,local-ip,DIRECT
  - MATCH,PROXY

path is where the rule set gets cached locally — the first fetch writes to this file, and every interval seconds after that, the client re-downloads and overwrites it. Even during a temporary network outage, the client keeps working off the last cached copy instead of losing all its rules over one failed update.

Ordering Multiple Rule Sets

Rules still match top to bottom and stop at the first hit — that behavior doesn't change just because you switched to Rule Provider. In practice, a sensible order looks like this:

• Ad/malware-blocking rule sets first (e.g. reject), so unwanted requests get filtered out as early as possible;
• Then rule sets for domains you explicitly want proxied (common lists of services that need it);
• Then regional direct-connect rule sets (domains and IP ranges you want to bypass the proxy);
• Finally, a catch-all MATCH rule — usually routed to the proxy — so a newly launched service doesn't just fail outright because it hasn't matched anything yet.

Choosing an Update Interval

Rule sets don't need refreshing anywhere near as often as node latency tests. For most use cases, an interval between 12 and 24 hours (43200–86400 seconds) is plenty; refreshing more aggressively just adds load on the rule set's server without any real benefit. If you're maintaining a private rule set yourself and it rarely changes, stretching that out to 2–3 days is perfectly fine too.

Common Problems and How to Fix Them

If rules "look configured" but aren't actually doing anything after switching to Rule Provider, work through these in order:

• The rule set fails to fetch — check whether url loads directly in a browser. Some rule sets are hosted on platforms that themselves require the proxy to reach, which creates a chicken-and-egg problem — in that case, switch to a URL served from a mirror or CDN closer to you;
• behavior doesn't match the content — as covered above, this is the single most common cause of failure. A classical-format file declared as domain gets parsed as plain domains, and the extra rule-type prefixes on each line end up treated as part of the domain string, breaking the whole rule set;
• The local cache is stale — if you suspect the client is still running on an old cached copy, just delete the file at path; the client will trigger a fresh full fetch on next startup;
• A new rule set disrupted the ordering — after adding a rule set, double-check it landed in the right spot relative to the "specific rules first, catch-all last" principle. An out-of-place insertion can silently break rules further down that used to work fine.

Nearly every "rules aren't working" issue traces back to one of these four causes, and working through them in order usually gets you to the answer quickly. For the complete rule syntax reference, see the Advanced Configuration Docs.