Clash YAML Rule Splitting: A Complete Guide to Policy Groups & Rule Providers

The mental model: rules first, groups second

Think of a Clash profile as three cooperating layers. The proxies section names concrete outbounds: your subscription nodes, direct, reject, or special protocols. The proxy-groups section defines policy groups—containers that either let you pick a member manually (select) or pick automatically (url-test, fallback, and so on). The rules section is a ordered list: for each connection, Clash walks from the first rule downward until one matches, then sends the flow to the target you named—which is usually a policy group, sometimes DIRECT or REJECT.

That ordering matters more than most newcomers expect. A broad rule placed too high will “eat” traffic you meant to handle elsewhere. A missing catch-all at the bottom leaves ambiguous cases undefined until you add MATCH. Experienced users often keep domestic or LAN traffic on DIRECT early, route sensitive domains to a dedicated group in the middle, and end with a MATCH that points at a default proxy group—so nothing falls through silently.

If you are also upgrading cores, remember that advanced protocols live in the proxies list, but which connections use them is still entirely decided here. Our Meta core upgrade guide covers engine replacement; this article assumes Meta is already in place and focuses on routing logic.

How rules match: order, specificity, and common types

Each rule is a predicate plus an action. The predicate might inspect the domain, a keyword, IP ranges, geographic region, or process name (where supported). The action is typically a policy group name, DIRECT, or REJECT. Clash does not “score” rules against each other for the same packet—it simply finds the first line that applies and stops.

DOMAIN and DOMAIN-SUFFIX

DOMAIN matches a single host exactly. DOMAIN-SUFFIX matches a suffix, which is the usual choice for whole sites and CDNs: DOMAIN-SUFFIX,google.com covers www.google.com and mail.google.com. Be careful with short suffixes: a careless DOMAIN-SUFFIX,com would be far too wide for real configs (and is only mentioned here as a cautionary tale).

DOMAIN-KEYWORD

Keyword rules match when the hostname contains a substring. They are convenient but easy to overfit: a keyword that appears inside unrelated domains can cause surprising routing. Prefer suffix rules when you can name the site; reserve keywords for coarse filters you truly intend to be broad.

IP-CIDR and IP-CIDR6

After DNS resolution—or when the destination is already an IP—CIDR rules match the target address. They are essential for internal networks, carrier-grade NAT exceptions, and provider-supplied IP lists. IPv6 configs should mirror IPv4 intent with IP-CIDR6 where dual-stack traffic appears.

GEOIP

GEOIP routes based on country codes bundled with or supplied to the core’s GeoIP database. It is a blunt instrument: fine for “send all CN IPs direct” patterns, but wrong for discriminating CDNs that serve multiple countries from the same anycast address. Combine GEOIP with domain rules when you need finer control.

SRC-IP-CIDR and other advanced matchers

Some builds expose matchers like SRC-IP-CIDR for multi-homed machines, or rules keyed by process name on certain platforms. Availability depends on the core and OS. When you adopt them, document why—future you will not remember that one gaming rule was for split tunneling a single executable.

Policy groups: what each type is for

Policy groups are not “just lists of servers.” The type determines how the group chooses its active member when a rule points at the group.

select

The classic manual group. You (or your GUI) choose one outbound from the list. This is ideal for region switches (“Hong Kong” vs “Tokyo”), or for nesting: a select can list other groups as proxies, building a small hierarchy that stays readable in the UI.

url-test and fallback

url-test periodically measures latency to a probe URL and picks a winner, optionally sticking to it for stability. fallback walks the list in order and moves forward when the current choice fails health checks. Use url-test when you want the fastest node; use fallback when order expresses preference and you want resilience more than raw speed.

load-balance

Distributes sessions across members according to a strategy (such as consistent hashing). It can improve throughput on multi-connection workloads, but it is rarely the first tool you reach for on residential setups—understand your goal before enabling it.

relay

Chains members in sequence. This is advanced territory: useful for nested paths, but easy to misconfigure latency- or loop-wise. Most subscription users never need relay; mentioning it here prevents confusion when you see it in public templates.

proxy-groups:
  - name: "PROXY"
    type: select
    proxies:
      - "Auto"
      - "HK"
      - "DIRECT"
  - name: "Auto"
    type: url-test
    proxies:
      - "node-a"
      - "node-b"
    url: "https://www.gstatic.com/generate_204"
    interval: 300

In this sketch, rules can target PROXY for user-facing choice while Auto handles latency selection under the hood. Naming groups after their role (“Streaming”, “Work VPN”) tends to age better than naming them after a single provider brand.

Rule Providers: remote lists without endless copy-paste

A Rule Provider loads rules from a URL or a local file, stores them under the profile directory, and optionally refreshes on an interval. Instead of inflating your main YAML with ten thousand DOMAIN-SUFFIX lines, you declare a provider once and reference it from rules with RULE-SET (in engines that support rule sets) or map the provider into classical rules depending on your syntax flavor.

Behavior modes: classical, domain, ipcidr

Providers carry a behavior hint. classical text files enumerate full rule lines (with matchers and targets). domain and ipcidr formats are optimized lists: one entry per line without repeating the keyword, which saves space and parse time. Pick the behavior that matches the list author’s format—mixing them causes confusing parse errors that look like “valid line, wrong mode.”

Example: HTTP provider skeleton

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

The path is where the downloaded content lands on disk. The interval controls refresh; during development, a shorter interval helps, then you can raise it to reduce chatter.

Wiring providers into rules

Exact syntax varies slightly between Premium-era configs and Meta’s richer rule-set surface. In Meta, you commonly reference a set with a dedicated rule keyword (often RULE-SET) pointing at the provider name, followed by the policy target. Always align examples with your core’s documentation—when in doubt, validate by reloading and reading the core log rather than guessing.

Practical patterns that survive real-world edits

Good configs read like documentation. Start with non-controversial allowances: LAN and local names to DIRECT, captive portals if needed, then high-confidence domain lists for services you always want proxied or blocked. Place GEOIP rules where they make sense for your region—common in bilingual networks—and only then widen to generic proxy groups.

Avoid duplicating the same domain across multiple contradictory rules; if you must exception-route a subdomain differently from its parent, put the more specific rule higher. For streaming and banking sites, explicit domain rules beat guessing based on IP alone because CDNs shift.

When you introduce Rule Providers, keep a short comment map in your personal notes (not necessarily inside YAML) listing each provider’s purpose and maintainer. Months later, you will thank yourself when a provider changes format or goes offline.

Testing changes safely

Reload the profile after each meaningful edit. Watch the log for parse errors—Meta usually prints the file and line. Use small probe sites to verify path: a domain you control, a known IP check, and a domestic site that should stay direct. If something looks wrong, swap the last MATCH target temporarily to a conservative group until you isolate the offending rule.

GUIs and YAML: who owns the truth?

Many clients expose policy groups in the UI while generating YAML underneath. That is excellent for daily use until you need a feature the GUI does not surface—then you edit YAML and risk the next save overwriting your hand edits. Learn your client’s merge or override mechanisms: “profiles + mixin,” “patch,” or external rule files. The clients we list generally favor workflows where Meta stays current and your customizations survive updates, but the exact knobs vary by app.

If you maintain pure YAML in git, treat providers as cached artifacts: ignore downloaded paths if they churn, or commit them only when reproducibility matters for your team.

Troubleshooting quick reference

When logs are clean but behavior feels random, simplify: collapse to a tiny ruleset—one direct, one proxy, one match—and confirm fundamentals. Then reintroduce complexity in layers rather than toggling ten things at once.

Open source and documentation

Clash Meta (mihomo) evolves quickly; field names and rule keywords occasionally gain aliases or stricter validation. For authoritative syntax, keep the upstream documentation at hand. The mihomo repository is the right place for issues, release notes, and advanced examples—separate from day-to-day installer downloads, which we keep on our site for clarity.

Closing thoughts

Routing is where “a proxy app” becomes your network policy. Policy groups give you structure; rules express intent; Rule Providers scale that intent without turning your YAML into an unmaintainable scroll. The combination is more reliable than chasing per-app toggles when you move between Wi-Fi, tethering, and desktop environments.

Compared with clients that hide everything behind opaque menus, a Meta-backed workflow with readable groups and curated lists tends to feel steadier once the initial learning curve passes—especially when you revisit a profile after months away.

For core upgrades and newer protocols, continue with the Meta upgrade tutorial; for more networking topics, browse the full tech column.