多數問題不是節點故障，而是規則被上方條件提前命中。ClashX 採自上而下匹配，命中即停止，因此順序本身就是策略邏輯。
本文會把規則優先級拆成可執行模型、模板與排障流程，讓你在維持可讀性的同時，也能得到可預測的分流結果。
為什麼規則會看起來隨機失效
多數問題不是節點故障，而是規則被上方條件提前命中。ClashX 採自上而下匹配，命中即停止，因此順序本身就是策略邏輯。
若將 MATCH、大範圍 GEOIP 或過寬 DOMAIN-SUFFIX 放在前面，下方精準規則就不會生效。
每次請求只會命中第一條規則。後面規則再正確，只要前面先命中，就等於不存在。這就是為什麼「順序」要和「內容」一起評審。
常見症狀
- 流量行為忽快忽慢，看似節點波動。
- 日誌永遠落在 GEOIP 或 MATCH，精準規則沒出現。
- 首頁可開，登入/播放/下載請求卻失敗。
- 改一條看似無關的規則，另一個系統突然異常。
MATCH 應只保留一條，且必須最後。放在中段會直接終止後續匹配。
規則優先級的核心模型
建議採漏斗模型：精準條件在前、兜底條件在後。常用順序：DOMAIN → DOMAIN-SUFFIX → DOMAIN-KEYWORD → IP-CIDR → GEOIP → MATCH。
- 精準域名規則可預測性最高
- 關鍵業務域名先寫，避免被寬規則蓋掉
- 兜底規則只留一條並放最後
| 規則類型 | 建議優先級 | 典型用途 | 風險提示 |
|---|---|---|---|
DOMAIN |
1（最高） | 登入回調、支付介面、核心 API | 需持續維護精準清單 |
DOMAIN-SUFFIX |
2 | 整站或服務族群分流 | 後綴過寬容易誤傷 |
DOMAIN-KEYWORD |
3 | 短期過渡規則 | 誤判機率最高 |
IP-CIDR |
4 | 內網、辦公網段、固定出口 | 注意 no-resolve 使用 |
GEOIP |
5 | 國別層級兜底 | CDN/Anycast 可能偏差 |
MATCH |
6（最後） | 最終兜底 | 不可提前 |
DOMAIN 負責精準鎖定，DOMAIN-SUFFIX 負責服務族群，DOMAIN-KEYWORD 作為過渡，IP-CIDR 處理網段，GEOIP 做大範圍兜底，MATCH 防止漏網流量。
漏斗模型（由上到下）
第一層：關鍵業務精準域名
第二層：服務域名後綴規則
第三層：關鍵字過渡規則
第四層：網段與地理分流
第五層：MATCH 最後兜底
常見衝突情境與修復
情境 1：內網系統走錯線路。通常是被上方寬規則覆蓋，需把內網白名單前置。
情境 2：影音服務不穩。建議拆分 API 與內容域名，避免單一關鍵字規則過寬。
情境 A：辦公系統走錯線路
SSO 網域在海外、主站在本地；若 GEOIP 前置，登入回調可能走錯策略，造成偶發失敗。
rules:
- GEOIP,CN,DIRECT
- DOMAIN-SUFFIX,corp.example.com,DIRECT
- DOMAIN,sso.corp-auth.com,PROXY
- MATCH,PROXY先放精準登入與 API 規則，再放服務後綴，最後才是 GEOIP 與 MATCH。
rules:
- DOMAIN,sso.corp-auth.com,PROXY
- DOMAIN,api.corp.example.com,DIRECT
- DOMAIN-SUFFIX,corp.example.com,DIRECT
- GEOIP,CN,DIRECT
- MATCH,PROXY情境 B：串流識別失敗
只寫一條關鍵字規則會漏掉鑑權、媒體與靜態資源網域，導致可進站但播放異常。
rules:
- DOMAIN-KEYWORD,netflix,PROXY
- GEOIP,CN,DIRECT
- MATCH,DIRECT拆分 API、媒體與主域後綴規則，再交給 GEOIP 與 MATCH 收尾。
rules:
- DOMAIN,api.netflix.com,PROXY_STREAM
- DOMAIN-SUFFIX,nflxvideo.net,PROXY_STREAM
- DOMAIN-SUFFIX,netflix.com,PROXY_STREAM
- GEOIP,CN,DIRECT
- MATCH,PROXY情境 C：國內 CDN 被誤代理
主站需要代理，但靜態資源由國內 CDN 提供。若用寬關鍵字統一代理，會造成回源繞路與延遲。
rules:
- DOMAIN-KEYWORD,example,PROXY
- MATCH,DIRECT把主站和 CDN 域名拆開：主站代理，CDN 直連，避免誤導流量。
rules:
- DOMAIN,app.example.com,PROXY
- DOMAIN-SUFFIX,static.examplecdn.cn,DIRECT
- DOMAIN-SUFFIX,example.com,PROXY
- GEOIP,CN,DIRECT
- MATCH,PROXY情境 D：UDP 遊戲不通
遊戲流量被送到不穩定或不支援 UDP 的策略組，導致登入成功但對戰掉線。
rules:
- DOMAIN-SUFFIX,game.example.com,PROXY
- MATCH,PROXY為遊戲域名與遊戲網段建立獨立 UDP 策略組，並保留原有兜底規則。
rules:
- DOMAIN-SUFFIX,match.game.example.com,GAME_UDP
- IP-CIDR,203.0.113.0/24,GAME_UDP,no-resolve
- DOMAIN-SUFFIX,game.example.com,GAME_UDP
- GEOIP,CN,DIRECT
- MATCH,PROXY實用模板（可直接套用）
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模板核心是層次與順序，不是節點名稱。替換策略組時，請保留結構。
模板一：基礎版（個人日常）
rules:
- DOMAIN,login.company.com,PROXY
- DOMAIN-SUFFIX,company.com,DIRECT
- DOMAIN-SUFFIX,google.com,PROXY
- DOMAIN-SUFFIX,github.com,PROXY
- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
- IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
- GEOIP,CN,DIRECT
- MATCH,PROXY模板二：進階版（rule-providers）
rule-providers:
direct:
type: http
behavior: classical
url: https://example.org/rules/direct.yaml
path: ./ruleset/direct.yaml
interval: 86400
proxy:
type: http
behavior: classical
url: https://example.org/rules/proxy.yaml
path: ./ruleset/proxy.yaml
interval: 86400
rules:
- RULE-SET,direct,DIRECT
- RULE-SET,proxy,PROXY
- GEOIP,CN,DIRECT
- MATCH,PROXY模板三：串流優先版
rules:
- DOMAIN-SUFFIX,netflix.com,PROXY_STREAM
- DOMAIN-SUFFIX,nflxvideo.net,PROXY_STREAM
- DOMAIN-SUFFIX,disneyplus.com,PROXY_STREAM
- DOMAIN-SUFFIX,youtube.com,PROXY_STREAM
- DOMAIN-SUFFIX,bilibili.com,DIRECT
- DOMAIN-SUFFIX,iqiyi.com,DIRECT
- GEOIP,CN,DIRECT
- MATCH,PROXY模板解讀重點
所有模板都採同一骨架：前段高優先規則、中段場景規則、後段 GEOIP、最後 MATCH。改策略組名稱即可，不建議改層次。
一次只改一層，改完立刻回歸測試。多層同時改動會讓排障難度指數上升。
排查流程（5 分鐘版）
- 開啟日誌並重現目標請求
- 確認實際命中規則
- 檢查上方寬規則是否覆蓋
- 核對規則集更新時間
- 做關鍵域名回歸測試
5 分鐘實戰版
第 1 分鐘：重現並記錄時間點；
第 2 分鐘：抓到命中規則；
第 3 分鐘：查看上方是否被寬規則覆蓋；
第 4 分鐘：最小改動並重載；
第 5 分鐘：回歸三類關鍵流量。
# 追蹤 ClashX 日誌
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常見路徑在 ~/Library/Logs/ClashX/。不同版本檔名可能不同，但通常都位於這個目錄。
團隊協作與版本管理
多人協作時，建議按「業務白名單、系統服務、地理分流、兜底」分層管理，並保留每次變更的目的、影響與回退點。
只要分層明確，線上異常時就能快速定位責任區段，避免全檔回滾。
建議目錄結構
config/
base.yaml
rules/
10-business.yaml
20-services.yaml
30-geo.yaml
99-fallback.yaml
providers/
direct.yaml
proxy.yaml# Commit message 建議格式
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將規則集集中維護，主配置只負責組合與策略映射，可降低多人維護造成的漂移與衝突。
FAQ：規則優先級高頻問題
Q1：no-resolve 是什麼？
A：表示該 IP 規則不再做額外 DNS 解析，常用於內網網段，能減少不必要延遲與誤解析。
Q2：MATCH 應該放哪裡？
A：最後一行，且只保留一條。
Q3：規則集和本地規則衝突怎麼辦？
A：看最終執行順序，不看來源。最上方命中者生效。
Q4：為什麼同一服務有時正常有時失敗？
A：主域、API、媒體域可能分別命中不同規則，需拆分規則而非用單一關鍵字覆蓋。
Q5：DOMAIN-SUFFIX 與 DOMAIN-KEYWORD 如何選？
A：優先用 DOMAIN-SUFFIX；DOMAIN-KEYWORD 建議只作短期過渡。
Q6：GEOIP 可以放前面嗎？
A：通常不建議。前置 GEOIP 會吞掉高優先級業務規則，造成難以追蹤的副作用。
Q7：規則改完多久生效？
A：重載配置後立即生效，但建議重新發起請求並查看日誌確認命中路徑。
Q8：如何避免多人維護互相覆蓋？
A：分層檔案 + 提交規範 + 審查順序變更，三者缺一不可。
總結
先建立可預測的規則順序，再優化節點品質，才能長期穩定。
規則優先級不是排版細節，而是流量行為的核心設計。