ClashX Rule Priority in Practice: How to Avoid Conflicts Between DOMAIN-SUFFIX, GEOIP, and MATCH

Most failures are not node outages. They come from rule shadowing. ClashX matches top-down and stops at the first hit, so ordering is part of logic, not formatting.

Why rules look randomly broken

Most failures are not node outages. They come from rule shadowing. ClashX matches top-down and stops at the first hit, so ordering is part of logic, not formatting.

If broad rules like MATCH or GEOIP appear too early, specific business rules will never execute.

💡

First match wins

Each request uses only the first matched rule. Wrong ordering makes correct rules unreachable.

Typical symptomsUnstable routing despite healthy nodes
Expected policy groups never hit
Home page works but auth/media fails
Small edits break unrelated traffic

⚠️

Common mistake

Placing MATCH in the middle ends evaluation early. Keep it last.

Core model of rule priority

Use a funnel model: precise conditions first, fallback conditions last. Recommended order: DOMAIN → DOMAIN-SUFFIX → DOMAIN-KEYWORD → IP-CIDR → GEOIP → MATCH.

Exact domain rules are predictable
Critical business domains should be explicit
Fallback must be unique and final

                            
                                Rule typePriorityUse caseRisk

                                DOMAIN1Critical hostsMaintenance cost
DOMAIN-SUFFIX2Service family routingCan overmatch
DOMAIN-KEYWORD3Temporary bridgeHigh false positives
IP-CIDR4Network rangesno-resolve usage
GEOIP5Country fallbackCDN mismatch
MATCH6Final fallbackMust be last

Rule type	Priority	Use case	Risk
`DOMAIN`	1	Critical hosts	Maintenance cost
`DOMAIN-SUFFIX`	2	Service family routing	Can overmatch
`DOMAIN-KEYWORD`	3	Temporary bridge	High false positives
`IP-CIDR`	4	Network ranges	no-resolve usage
`GEOIP`	5	Country fallback	CDN mismatch
`MATCH`	6	Final fallback	Must be last

📌

Role split

DOMAIN handles precision; GEOIP and MATCH handle broad fallback.

DOMAIN

Fastest

DOMAIN-SUFFIX

Fast

GEOIP

Medium

MATCH

Fallback

Funnel: business-exact rules → service suffix rules → keyword bridge rules → network/geo fallback → MATCH.

Common conflict scenarios and fixes

Case 1: internal apps routed to proxy. Usually caused by upper GEOIP,CN,DIRECT conflict or missing whitelist. Add exact internal domains first.

Case 2: streaming instability. Split API and media domains into separate rules instead of one broad keyword.

Office systems route incorrectly

🧨

Problem config

Early GEOIP shadows auth callback rules.

rules:
  - GEOIP,CN,DIRECT
  - DOMAIN-SUFFIX,corp.example.com,DIRECT
  - DOMAIN,sso.corp-auth.com,PROXY
  - MATCH,PROXY

✅

Fix

Move exact SSO/API domains before broad rules.

rules:
  - DOMAIN,sso.corp-auth.com,PROXY
  - DOMAIN,api.corp.example.com,DIRECT
  - DOMAIN-SUFFIX,corp.example.com,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

Streaming region detection fails

🎬

Problem config

Single keyword rule misses auth/media domains.

rules:
  - DOMAIN-KEYWORD,netflix,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,DIRECT

✅

Fix

Separate API/media/main domains explicitly.

rules:
  - DOMAIN,api.netflix.com,PROXY_STREAM
  - DOMAIN-SUFFIX,nflxvideo.net,PROXY_STREAM
  - DOMAIN-SUFFIX,netflix.com,PROXY_STREAM
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

Domestic CDN accidentally proxied

📦

Problem config

Broad keyword sends static CDN traffic through proxy.

✅

Fix

Keep app domain proxied but force CDN suffix to DIRECT.

UDP games disconnect

🎮

Problem config

Policy group does not provide stable UDP path.

✅

Fix

Create a dedicated UDP-capable game group and route game hosts there.

Practical templates

rules:
  - DOMAIN,api.example.com,ProxyA
  - DOMAIN-SUFFIX,example.com,ProxyA
  - DOMAIN-KEYWORD,office,DIRECT
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,ProxyB

Keep hierarchy unchanged and only replace policy-group names.

Basic template

rules:
  - DOMAIN,login.company.com,PROXY
  - DOMAIN-SUFFIX,company.com,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

Advanced template (rule-providers)

rule-providers:
  direct:
    type: http
    behavior: classical
    url: https://example.org/rules/direct.yaml
    path: ./ruleset/direct.yaml
    interval: 86400

rules:
  - RULE-SET,direct,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

Streaming-focused template

rules:
  - DOMAIN-SUFFIX,netflix.com,PROXY_STREAM
  - DOMAIN-SUFFIX,nflxvideo.net,PROXY_STREAM
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

Template blocks: critical rules, scenario rules, geo fallback, final catch-all.

🛠️

Customization tip

Modify one layer at a time, then run immediate regression checks.

5-minute troubleshooting flow

Enable logs and reproduce one request
Identify matched rule line
Inspect broad rules above it
Verify rule-set sync timestamp
Run regression on key domains

Minute 1 reproduce, minute 2 locate hit, minute 3 inspect shadowing, minute 4 minimal fix, minute 5 regression.

tail -f ~/Library/Logs/ClashX/clashx.log
grep "api.example.com" ~/Library/Logs/ClashX/clashx.log
grep -E "MATCH|GEOIP|DOMAIN" ~/Library/Logs/ClashX/clashx.log | tail -n 50

Step 1

Reproduce

Step 2

Locate

Step 3

Inspect shadow

Step 4

Minimal fix

Step 5

Regression

📍

Log location

Usually under ~/Library/Logs/ClashX/ on macOS.

Team collaboration and versioning

For multi-editor setups, split rules into layers: business whitelist, system services, geo-routing, and final fallback. Every change should include intent, impact, and rollback notes.

This structure makes incident triage fast because each layer has a clear responsibility.

config/
  base.yaml
  rules/
    10-business.yaml
    20-services.yaml
    30-geo.yaml
    99-fallback.yaml

feat(rule): add explicit routing for corp SSO callbacks
fix(rule): move MATCH to last line and reduce keyword shadowing
chore(ruleset): bump streaming provider to 2026-02-10

🤝

Sharing strategy

Use rule-providers for team-wide consistency and easier rollbacks.

FAQ: rule priority

Q1: What is no-resolve?

A: It prevents extra DNS resolution for IP rules, useful for LAN CIDRs.

Q2: Where should MATCH be?

A: Last line, once.

Q3: What if local rules and rule-set conflict?

A: Final order decides behavior. First hit wins.

Q4: Why does one service work partially?

A: Different subdomains hit different rules. Split by function.

Q5: DOMAIN-SUFFIX or DOMAIN-KEYWORD?

A: Prefer DOMAIN-SUFFIX; use keyword as temporary bridge.

Q6: Can GEOIP be placed early?

A: Usually no. It may shadow high-priority business rules.

Q7: When do changes apply?

A: After reload, then verify with logs.

Q8: How to avoid team conflicts?

A: Layered files, commit conventions, and order-focused review.

Q9: Should I add more and more rules?

A: Not necessarily. Keep rules minimal and explicit. Too many broad rules increase collisions.

Q10: Should every host be a DOMAIN rule?

A: No. Reserve DOMAIN for critical hosts; use suffix and provider rules for scalable maintenance.

Q11: How often should rule-providers refresh?

A: Daily is a practical default. For sensitive environments, update with release windows and rollback tags.

Q12: Can I optimize and refactor in one commit?

A: Better split changes: first behavior-safe reordering, then optimization. It simplifies incident rollback.

Appendix: priority lab (copy and test)

Use these mini experiments in a test profile to see how ordering changes behavior immediately.

Experiment 1: early MATCH

rules:
  - DOMAIN,api.example.com,PROXY
  - MATCH,DIRECT
  - DOMAIN-SUFFIX,example.com,PROXY

🧪

Expected result

DOMAIN-SUFFIX,example.com,PROXY never runs because MATCH terminates evaluation first.

Experiment 2: keyword overreach

rules:
  - DOMAIN-KEYWORD,cdn,PROXY
  - DOMAIN-SUFFIX,assets.example.cn,DIRECT
  - MATCH,DIRECT

🧪

Expected result

Any domain containing cdn is captured early, so the specific DIRECT rule below is shadowed.

Experiment 3: explicit auth host first

rules:
  - DOMAIN,auth.example.com,PROXY
  - DOMAIN-SUFFIX,example.com,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

With explicit auth host first, login and business traffic can be routed independently and remain deterministic.

Experiment 4: GEOIP placed too early

rules:
  - GEOIP,CN,DIRECT
  - DOMAIN,api.global-service.com,PROXY
  - MATCH,PROXY

🧪

Expected result

Requests resolved into CN IP space can be routed DIRECT before the explicit domain rule is reached.

Experiment 5: split media and API domains

rules:
  - DOMAIN,api.stream.example,PROXY_STREAM
  - DOMAIN-SUFFIX,media.stream.example,PROXY_STREAM
  - DOMAIN-SUFFIX,img.stream.example,DIRECT
  - MATCH,PROXY

🧪

Expected result

Control plane and data plane can use different routes without random behavior.

Experiment 6: explicit LAN ranges with no-resolve

rules:
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - MATCH,PROXY

🧪

Expected result

Internal network traffic stays direct and avoids unnecessary DNS lookup overhead.

Experiment 7: fallback only once

rules:
  - DOMAIN,critical.example,PROXY
  - MATCH,PROXY
  - MATCH,DIRECT

🧪

Expected result

The second MATCH is unreachable and should be removed for clarity and safety.

Lab 1

Terminal rule behavior

Lab 2

Keyword overreach

Lab 3

Explicit host benefits

Lab 4

GEOIP placement risk

Lab 5

Split-domain stability

Summary

Stable routing starts with deterministic rule order. Node quality matters, but priority design matters first.

Before release, run three checks: critical-domain hit validation, MATCH-at-bottom validation, and small-scope regression validation.

When ordering is treated as architecture, not formatting, troubleshooting time drops dramatically.

Was this article helpful?

✓Thanks for your feedback!

Tags:ClashXRule PriorityTraffic RoutingDOMAIN-SUFFIXGEOIP

Why rules look randomly broken

Typical symptoms

Core model of rule priority

Common conflict scenarios and fixes

Office systems route incorrectly

Streaming region detection fails

Domestic CDN accidentally proxied

UDP games disconnect

Practical templates

Basic template

Advanced template (rule-providers)

Streaming-focused template

5-minute troubleshooting flow

Team collaboration and versioning

FAQ: rule priority

Q1: What is no-resolve?

Q2: Where should MATCH be?

Q3: What if local rules and rule-set conflict?

Q4: Why does one service work partially?

Q5: DOMAIN-SUFFIX or DOMAIN-KEYWORD?

Q6: Can GEOIP be placed early?

Q7: When do changes apply?

Q8: How to avoid team conflicts?

Q9: Should I add more and more rules?

Q10: Should every host be a DOMAIN rule?

Q11: How often should rule-providers refresh?

Q12: Can I optimize and refactor in one commit?

Appendix: priority lab (copy and test)

Experiment 1: early MATCH

Experiment 2: keyword overreach

Experiment 3: explicit auth host first

Experiment 4: GEOIP placed too early

Experiment 5: split media and API domains

Experiment 6: explicit LAN ranges with no-resolve

Experiment 7: fallback only once

Summary

Was this article helpful?

Related Articles

ClashX DNS Leak Prevention Checklist: Browser Layer to System Layer

ClashX Proxy Group Strategy: Auto-select, Fallback, and Manual Override

How to Enable ClashX TUN Mode: Enhanced Setup and Troubleshooting