Search intent: “My rule exists, so why is traffic ignoring it?”
Forums are full of screenshots where a careful DOMAIN line points at Proxy, yet the live flow still rides DIRECT or some other group. The YAML is not lying; the reader is simply looking at the wrong line. Clash Meta evaluates rules: as an ordered list. The moment one predicate returns true, the engine stops and hands the packet to whatever policy you named on the right-hand side. Later lines—including that clever exception you added at the bottom—never get a chance to speak.
Another frequent story is the opposite: you expected a broad GEOIP,CN,DIRECT bucket to keep domestic CDNs local, but a multinational SaaS still exits through a domestic path—or the reverse—because an earlier line already matched. Fixing those cases is less about memorizing every rule type and more about treating your profile like a firewall ACL: narrow, high-confidence rows on top; wide country catch-alls lower down; a deliberate MATCH at the tail. Once you internalize that shape, the GEOIP and GEOSITE tutorial stops feeling like a separate universe and becomes a specialized vocabulary for the same ladder.
Rule priority in one sentence: first match wins
There is no secondary scoring system, no “more specific wins” tie-breaker, and no hidden weight for GEOSITE versus IP-CIDR. Specificity only helps you because you physically placed the precise line above the broad one. If both lines could match the same flow, the upper line always steals the decision. That single fact explains why moving a row a few dozen lines upward or downward can change exit nodes dramatically even though you did not edit a single character in the predicate itself.
Think of each connection attempt as walking down a checklist. The engine asks: does this DOMAIN-SUFFIX match the metadata we have? If yes, stop and apply the policy. If no, continue. Does this GEOIP rule match the destination IP class we can see? If yes, stop. The loop continues until either a line matches or you reach the end of the array. If you never wrote an explicit final row, some builds still expect you to provide MATCH; if you did write it, it guarantees every flow eventually lands somewhere predictable instead of failing open in an implementation-defined way.
Debugging habit: for any confusing flow, capture the log line that names the matched rule index or type. If your client UI does not show it, enable debug logging briefly. Guessing by reading YAML alone will waste hours.
What MATCH actually does
MATCH is the unconditional predicate. It always matches, which makes it the canonical catch-all or default route for traffic that survived every earlier test. Most community templates end with something like MATCH,Proxy or MATCH,DIRECT depending on whether the designer assumed a default-secure or default-minimal posture. If you omit MATCH entirely, you are relying on implicit behavior that varies with client packaging; explicit is better than implicit when you are troubleshooting at midnight.
Because MATCH swallows everything, anything placed after it is dead YAML. Generators sometimes append advertising blocks or user snippets in the wrong order; the symptom is a profile that parses yet mysteriously ignores your personal exceptions. When you merge files, always visualize the final concatenated array. If your editor supports folding, collapse everything except rules: and scroll once from top to bottom—no shortcuts.
# Tail of a sane rules array (illustrative names)
rules:
- DOMAIN-SUFFIX,corp.example,DIRECT
- GEOSITE,youtube,YouTube
- GEOIP,CN,DIRECT
- GEOIP,!CN,Proxy
- MATCH,Proxy
The sample above is not the only valid philosophy; it simply shows MATCH acting as the final safety net after country buckets. Swap policies to match your threat model, but keep the idea: explicit carve-outs first, coarse geography in the middle, unconditional fallback last.
Right-hand side: policies, proxy-groups, and name typos
The token after the last comma is not free-form prose; it must name something the core knows how to resolve. Built-in keywords such as DIRECT, REJECT, and REJECT-DROP (exact spelling depends on your build) map to internal handlers. Any other string is looked up as a proxy-group or a single proxy entry from proxies:. A classic typo—PROXY in all caps versus your group Proxy—either breaks validation or silently points at a group you did not mean to create.
Nested groups do not rewrite the rule list. If MATCH,Auto selects a url-test group named Auto, the rule engine is finished; the group logic only chooses which upstream node wins inside that bucket. That distinction matters when you blame “rule order” for latency: sometimes the rule is correct and the group selection is jittery—see our url-test and failover guide for health-check tuning, then return here to confirm the first hop into Auto was intentional.
Why your GEOIP line “does nothing”
GEOIP predicates need a usable destination IP. If metadata still carries only a hostname because TLS has not revealed addresses yet, the engine may defer or skip evaluation depending on context and modifiers such as no-resolve. Conversely, if an earlier DOMAIN or GEOSITE line already matched, your GEOIP row is never consulted. Users describe that as “GEOIP broken,” but the truth is simpler: something above it already decided the flow.
Country catch-alls should usually sit below the domain precision you care about. The GEOIP / GEOSITE guide walks through China-direct patterns and GEOSITE,geolocation-!cn-style bundles; the key takeaway for this page is ordering, not geography trivia. If a multinational service keeps landing on the wrong side of your split, move its GEOSITE or explicit DOMAIN lines above the GEOIP,CN row instead of duplicating ten more IP-CIDR entries.
When domain rules never fire: Sniffer and metadata shape
DOMAIN and GEOSITE need a domain string in the metadata the core sees at classification time. HTTPS flows often arrive as raw IPs first; without Sniffer (or equivalent) recovering SNI or QUIC hints, your beautiful domain rows simply do not match, and the packet falls through to IP-CIDR, GEOIP, or ultimately MATCH. The fix is not to spam more GEOIP lines; it is to restore hostname visibility or accept IP-based predicates until you do.
Pair this article with the Sniffer setup walkthrough if your logs show IPs where you expect hostnames. Once names reappear, revisit rule order: the domain rows you wrote “months ago” may suddenly start matching and shadow your newer GEOIP experiments—another example of first-match dynamics changing when metadata quality improves.
DNS, FakeIP, and “the rule matched but the app still fails”
Even perfect rule order cannot save you if the resolver and the forwarding path disagree about what name maps to which address. FakeIP modes make rules easier to write, yet they also introduce a second layer where mistakes hide: the client might think it opened 203.0.113.10 while your dashboard still displays a domain-based rule from an earlier DNS phase. When symptoms look like DNS rather than routing, switch to the DNS leak prevention guide before reordering rules: again.
As a quick triage, answer three questions: what name did the application resolve, what name did Clash attach to the flow, and which rule index fired? If the first two differ, fix DNS alignment first. If they agree but the third is unexpected, fix ordering. Mixing the two debug tracks is how people end up toggling random switches for an entire weekend.
Rule providers, RULE-SET, and merge order
Large profiles rarely keep every row inline. Rule providers download remote lists and expand into the rules array at a defined position—usually wherever the RULE-SET entry sits. That means a remote bundle placed near the top can accidentally outperform your hand-written exceptions if those exceptions appear later. Some generators insert provider blocks above user snippets; others append them at the end before MATCH. Know your tool.
When comparing community mega-templates, read ACL4SSR versus Loyalsoldier-style rulesets for maintenance trade-offs, but remember: whichever file you choose, your personal overrides must land in the merged document above any catch-all that collides with them. Many GUI clients expose a “prepend” or “override” pane specifically to solve this without forking the entire subscription.
Process rules and other parallel ladders
PROCESS-NAME and similar predicates follow the same first-match principle, but they key off executable identity rather than destination metadata. They are invaluable when two apps share domains yet require different compliance paths. They do not exempt you from ordering discipline: a broad process rule above a careful domain carve-out will still shadow that carve-out. For executable-focused examples, see the PROCESS-NAME routing tutorial.
A practical debugging checklist
1Confirm the profile you think is running actually loaded
Remote controllers, multiple YAML tabs, and failed hot-reloads have all produced cases where users edit file A while the core still runs file B. Restart cleanly once, watch the log for the profile path, then continue.
2Identify the winning rule, not your favorite rule
Match the log’s rule index against the flattened rules: array. If the index points at a provider-expanded block, open that provider output temporarily so line numbers line up with human expectations.
3Check metadata: domain present or only IP?
If only IPs appear, enable or tune Sniffer, or temporarily test with an IP-CIDR rule to prove connectivity, then return to domain predicates once names exist.
4Reorder before you duplicate
Copy-pasting the same domain ten times throughout the file makes future merges painful. Move the single authoritative line instead.
5Keep MATCH meaningful
After edits, ensure MATCH still reflects your default posture and that nothing accidental sits beneath it.
Common pitfalls that look like “Clash ignored me”
- Broad rules above narrow ones: a catch-all
GEOSITEbundle or a giant remoteRULE-SETinserted before personal splits. - Dead YAML after
MATCH: exceptions appended by a script that always placesMATCHtoo early. - Case-sensitive group names:
proxyversusProxyversus Unicode look-alikes from copy-paste. - Assuming specificity without reordering: Clash will not magically prefer the “better” line.
- Debugging only with browser while TUN is off: system proxy bypass paths never hit the rules you are editing.
Open source and packaged clients
Mihomo publishes source and changelogs so you can verify rule-engine details for your exact semver. That transparency matters when a release note mentions tweaked no-resolve semantics or new Sniffer defaults. For day-to-day installers, prefer curated client channels: keep GitHub for issues and code review, and use the official Clash download page when teammates need a reproducible build.
Summary
Clash Meta and Mihomo route traffic with a strict first matching rule wins ladder. Place precise DOMAIN / GEOSITE / process exceptions above coarse GEOIP buckets, keep remote rule bundles where you can reason about their priority, finish with an explicit MATCH, and validate metadata (hostnames versus bare IPs) before you blame predicates. Once ordering, DNS, and Sniffer agree, the “wrong node” problem usually collapses into a single misplaced row—or a typo in a proxy-group name—that you can fix in minutes instead of days.
Compared with chasing node latency alone, learning this control plane pays off across every future profile merge: you spend less time fighting ghosts and more time tuning groups that actually matter.