先搞懂:自上而下,第一條命中就停
規則寫了半天卻彷彿無效,第一句應對照站內的 Clash 規則分流最佳實踐 裡同一句話:rules 陣列是由上而下逐一比對,第一條符合條件的規則決定該請求的策略組(或等同於策略組的回傳),之後的同一次請求不會再往後評估。換句話說,並不存在「全域合併各條再投票」的流程;你也不應假定「底下的 DOMAIN 比較具體就會自動蓋過上面」。具體性與順序要你親自排出先後。
實務上常見的情境是:RULE-SET 或過寬的 GEOIP,TW,DIRECT/GEOIP,TW,...(誤國碼)被放在你想要的 DOMAIN-SUFFIX 之前,請求早已被前面某條帶往 DIRECT 或某個 預設代理組,表面看起來像「規則沒寫進去」。因此要排障時,請先打開連線紀錄看規則名稱或命中鍵值實際顯示了哪一行;若紀錄層級仍搞不清楚,可把 連線日誌與 TLS/逾時拆解 當成輔助,避免只靠改節點猜方向。
MATCH 一定要寫最後嗎?漏了會怎樣
MATCH 代表「對前面都沒攔住的流量再給預設出口」。在多數範例裡它被放在規則陣列最尾端,並非因為程式魔法,而是為了讓細則有機會先匹配。若你把 MATCH,ProxyGroup 放在數十行細則之前,結果就是全部都命中 MATCH,後面細則永遠不會執行;搜尋「RULE 寫了沒用」「分流不走代理」類長尾詞時,這是最常見的誤會之一。
另一端是沒有任何 MATCH 或等價兜底:視核心版本而定,可能退回未預期的預設、或令你以為規則表不完整。標準做法是最後一行保留 MATCH,對應到明確命名的「最終策略組」(例如 Final),並確認該策略組在 proxy-groups 中有定義——若你希望依延遲或備援自動切節點,可對齊 策略組 url-test/fallback 的文內作法,而不要讓兜底策略組含糊指到未定義的名稱。
GEOIP/IP-CIDR 為何會「繞過」你以為生效的網域規則
搜尋意圖若包含「誰先生效」,可以記一個對初學者不直覺的點:並非「GEOIP 一定在 DOMAIN 之後評估」——在 rules 裡順序由上而下,並沒有名稱類型上的自動排序。若在 Fake-IP 或某些規則前即已決定為 IP 級匹配的情境中,靠前的 IP-CIDR 或GEOIP(依 IP 對照地理)就會優先決策,看起來像「GEOIP/IP-CIDR 繞過了網域規則」。
CDN 類站台的後端離岸 IP也會造成你寫好的「國內站應該 DIRECT」卻依 GEOIP/mmdb國別對照誤標而分到代理的反直覺現象。更新 GEOIP 資料(mmdb)與 GeoSite,或改以已驗證的網域規則優先鎖國內意圖,都是常見對策——重點仍是對照順序,不是單換節點。
| 若先命中 | 對使用者的體感 |
|---|---|
| 靠前的 DOMAIN/RULE-SET(代理) | 請求視為應該組策略送出,底下的 GEOIP 直連區段不再檢視此請求。 |
| 靠前的 GEOIP/IP-CIDR(例如 DIRECT) | 若以 IP 級規則先符合,可能被直連拉住,看似「DOMAIN 類規則沒套上」。 |
補充:TUN 與規則層分開想
TUN/系統代理決定有哪些流量會經過 Clash 的規則引擎,與規則陣列內誰先誰後是不同層次。若在「規則都對」與現象對不起來時,可再讀 TUN 模式深度解析,先排除程式根本未進入規則層的情境。
GEOIP 誤判:mmdb 與 DNS/Fake-IP 對齊
GEOIP 誤判常見來源:mmdb/GeoLite 國別標註過舊或離岸 CDN IP被你誤會成「國內應 DIRECT」。對策除了更新資料庫與對照日誌,也要檢視 DNS 解析鏈:enhanced-mode: fake-ip 下,規則階段若仍依賴你已解析的真實 IP,而該解析與 nameserver/fallback Policy 不符,GEOIP 就會對著「我以為的國別」做文章。請把 Meta DNS · nameserver · fallback · fake-ip-filter 的段落與本篇文章一起讀——多數規則寫了無感其實是決策對象與 DNS 對象錯位。
一次走完的修正步驟清單
- 在問題重現當下查出命中的規則列:是 RULE-SET、DOMAIN、GEOIP,還是 MATCH?若紀錄顯示類型/行號與你預期不同,順序問題通常已經浮上檯面。
- 將更細、已驗證的網域或進程規則(核心支援進程級時)上移;把過寬的
RULE-SET、大段GEOIP/IP-CIDR與兜底用MATCH下移,使細則有機會先被比對到。 - 確認最末端有 MATCH,且對應策略組在
proxy-groups已定義;若兜底要自動換節點,請對齊 策略組 url-test/fallback,避免名稱未解析而退回他組。 - 若懷疑 GEOIP 誤判:更新 mmdb/geosite並對照紀錄;必要時對該站台改以網域規則為主、GEOIP 僅負責漏網之魚。
- 若懷疑 DNS 與 Fake-IP:對齊
fake-ip-filter、nameserver-policy與出站解析路徑,避免規則決策對 A、實際連線卻對 B IP 再跑 GEOIP 的分岔。 - 修正後同一 URL/同一應用重放,直到連線紀錄上的規則標籤/策略組與設計一致。
設定片段示意(僅結構)
下列片段僅示意「類型區塊順序」;實際規則名、策略組名請依你的訂閱與環境調整。程式註解使用英文為佳。
rules block — structural sketch onlyrules:
# Narrow, verified domain/process rules FIRST (examples only):
# - DOMAIN-SUFFIX,example.com,PREFERRED_GROUP
# - PROCESS-NAME,SomeApp,DIRECT
# Then broader rule-set blocks you trust:
# - RULE-SET,proxy-lite,PROXY
# LAN / RFC1918 BEFORE catch-all GEO if you intend local direct:
- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
# - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
# IP / country rules — order vs DOMAIN matters for each request profile:
# - GEOIP,TW,DIRECT
# Final catch-all LAST:
- MATCH,Final
no-resolve 與是否在 IP 級規則前解析網域,視核心與規則行為標誌而定;若你在訂閱模板裡複製過片段,請保留官方註解中的選項語意而不要混用來自不同意圖來源社群的整坨規則,否則又會發生自上而下被不相容的一條掃過的現象。
結語
Clash 規則優先級在寫法上並不神秘:第一條命中的規則說了算,因此「rule 自上而下」並非口號,而是調整順序與對照紀錄的實際依據。MATCH 通常應兜底;GEOIP 與 IP-CIDR 也不比 DOMAIN 更「優先」,而是誰先被比到。把 mmdb 與 DNS/Fake-IP一併納檢後,你就能把這類問題從「感覺規則沒生效」收成可重現的調整項目。
比起再堆一層泛泛的規則集,多數卡住的人缺的只是這份排障順序。與泛泛的分流架構總論相比,本篇刻意收斂在寫對仍走錯的長尾強意圖:先對紀錄、再對順序與兜底、最後才動資料檔。
→ 立即免費下載 Clash,開啟流暢上網新體驗——用可追溯的規則命中與清楚的最終兜底,省下在看似寫對的列上反覆試錯的時間。