Use rule-providers to Auto-Update Routing Rules Without Manual Edits

The Problem with Hand-Written Rules

Writing DOMAIN-SUFFIX and IP-CIDR entries directly under rules works fine at first, but once the rule count grows into the hundreds or thousands (e.g. precisely separating local vs. overseas traffic), you'll hit two problems: the config file becomes bloated and hard to maintain, and rules need constant updates (new domains, fixed mismatches) that are easy to miss when synced by hand.

What rule-providers Solves

rule-providers hosts an entire batch of rules as a standalone file (local or remote URL). Your main config just references its name and sets an update interval — the client re-fetches it automatically on schedule, so when the rule content changes, you don't have to do anything.

The behavior Field Determines the Rule Format

• domain: the rule set is a list of domains, one domain or domain suffix per line.
• ipcidr: the rule set is a list of IP ranges, one CIDR per line.
• classical: the rule set can use full matching syntax (same as the rules field) — most flexible but also the largest.

interval Determines the Fetch Frequency

The unit is seconds — 86400 means once every 24 hours. Rule sets usually don't change very often, so once a day or every few days is enough; there's no need to set it too short, which would put unnecessary load on the rule set's server.

Common Setup: Ad-Blocking + Regional Direct Connect

A typical combo is two rule sets: one for blocking ads and tracking domains (matches route to REJECT), and one for identifying local sites and IP ranges (matches route to DIRECT). Everything else goes to your proxy group — maintaining just two rule sets covers the vast majority of routing needs.

Combining Multiple Rule Sets

Real configs usually have more than one rule set. A common order is: the ad-block rule set first, then the local-direct rule set, then routing rules for each proxy group, and finally MATCH as the catch-all. The rules field matches top-to-bottom and stops at the first hit, so order matters a lot — if a "send everything to proxy" rule is placed first, none of the more specific rule sets after it will ever be checked.

Think of this order as "exclude first, catch-all last": handle traffic that clearly should be blocked or clearly should connect directly first, and only what's left uncovered falls through to the final MATCH and the default proxy group.

Notes on Updating and Migrating Rule Sets

After a rule set file is downloaded, it's cached at the local path specified by path. Even if you go offline temporarily, the client keeps working off the last cached version rather than losing all rules because a fetch failed. If you switch devices or reinstall the client, remember to migrate the cache directory referenced by path too — otherwise the first startup will trigger a fresh remote download, and rules may be briefly missing on a poor connection.

Also, the behavior of each rule set must match its content format — declaring domain but providing classical-formatted content will cause a parse failure. The client will usually show a clear error in the logs; fix it and restart, or just wait for the next interval to take effect.

Summary

rule-providers decouples "rule content" from "rule reference": content can be updated and maintained independently while the main config keeps only the reference. Over the long run this stays far cleaner than a several-hundred-line rules list, and makes it easy for multiple devices to share the same rule set.