Clash YAML 規則分流完全指南 2026：策略組與 Rule Providers 最佳實踐

為什麼「分流」比開關代理更重要？

多數使用者第一次接觸 Clash 類客戶端時，直覺會把模式切成「全域」或「規則」。全域模式最簡單，卻會讓在地影音、網路銀行與 CDN 節點統統繞路，延遲上升、體感變差；純手動選節點則無法應付大量網域。規則模式的核心，就是讓每一筆連線在送出前，先經過一組可預測的決策流程：符合某條規則就走指定策略組，否則往下一條繼續比對，直到命中最後的兜底規則。

在 Clash Meta（mihomo）環境裡，這套流程由同一個 YAML 設定檔中的 proxies、proxy-groups 與 rules（以及可選的 rule-providers）共同完成。你不需要記住所有關鍵字，但一定要理解兩件事：規則順序即優先權，以及策略組是「把多個出口打包成一個邏輯名稱」。掌握這兩點，後面無論是機場訂閱還是自訂覆寫，都會輕鬆很多。

若你尚未使用支援新協定的 Meta 核心，建議先完成核心升級，再回來調整規則；舊版核心在 Rule Providers 與部分規則行為上可能不一致，排查時會多走冤枉路。

規則怎麼生效？由上而下，第一條命中即停

Clash 的 rules 是一個有序陣列。對每一個新連線，核心會從第一條開始比對；一旦某條規則的條件成立，就採用該規則指定的目標（某個策略組名稱、DIRECT 或 REJECT 等），並不再檢視後面的規則。因此，越「具體、想優先處理」的例外，越要放在清單越上方；越「寬鬆、用來兜底」的規則則放在越下方。

實務上常見的排列思路是：先處理區域網與本機（例如 IP-CIDR 內網段、DOMAIN,localhost），再放必須直連或必須拒絕的網域，接著是訂閱產生的遠端規則集（透過 Rule Providers 展開），最後才用 GEOIP 或寬鬆的 MATCH 收尾。若你把寬規則放在前面，後面細緻規則將永遠沒機會生效，這也是許多「怎麼改都不對」的根源。

記一個口訣 規則清單不是「全部條件加總」，而是「像防火牆一樣的第一條命中」。調整分流時，請用「插入位置」思考，而不是只新增在檔案末尾。

策略組（proxy-groups）：把出口變成可選邏輯

proxy-groups 條目中的每一項都會變成一個可在規則裡引用的名稱。同一個實體節點可以出現在多個策略組裡；規則裡寫的永遠是「策略組名」，不是單一節點名稱（除非你直接把某節點當成唯一成員的策略組）。這層抽象讓你能用不同邏輯重用同一批節點。

常見策略組類型怎麼選？

select：由使用者手動選擇子節點或子策略組，最適合做「主線路／備用線路」切換。
url-test：依延遲自動選最快節點，適合「同一地區多節點」的懶人方案；記得設定合理的 url 與 interval。
fallback：依序檢測可用性，適合強調先求連得上的情境。
load-balance：在符合條件的節點間分攤（實作細節依核心與設定而異），適合多連線下載等進階場景，一般使用者較少手動撰寫。

設計策略組時，建議先畫出三層心智模型：入口決策（我要直連、走代理、還是拒絕？）→ 區域或用途策略（例如「國際媒體」「開發者站」）→ 具體出口（哪個機場、哪個自動測速組）。把「會频繁改名的訂閱節點」放在底層策略組，上層只引用穩定別名，之後換訂閱時就不必全檔搜尋取代。

proxy-groups:
  - name: "手動選擇"
    type: select
    proxies:
      - "自動測速"
      - "DIRECT"
  - name: "自動測速"
    type: url-test
    proxies:
      - "香港-01"
      - "新加坡-02"
    url: "https://www.gstatic.com/generate_204"
    interval: 300

上例中，規則只要寫 手動選擇，使用者即可在介面裡切換「整包自動測速」或直連；細節節點名稱變更時，多半只需改 自動測速 組內成員。

常用規則類型：從網域到 IP 到進程

以下列出實務最常見、也最需要搞懂差異的幾類規則。實際專案名稱與欄位請以你所用核心版本文件為準；Meta 持續擴充匹配器，但「由上到下的第一條命中」原則不變。

類型概念	典型用途	使用提醒
`DOMAIN`／`DOMAIN-SUFFIX`	精準指定單一網域或整個後綴樹	`DOMAIN-SUFFIX,google.com` 會涵蓋子網域；順序要與其他規則協調
`DOMAIN-KEYWORD`	網址任一處含關鍵字即命中	容易過度匹配，僅建議用在非常明確的關鍵字
`GEOIP`	依目標 IP 所屬國家／地區決定走向	需可靠的路由資料庫；常與 `,no-resolve` 等修飾搭配控制 DNS 行為
`IP-CIDR`／`IP-CIDR6`	網段級分流	適合內網、對接固定出口；IPv6 環境別忘了對應規則
`PROCESS-NAME` 等	依本機行程分流	適合遊戲、特定 App；名稱依作業系統而異，需實測
`MATCH`	兜底，匹配所有剩餘流量	一定放在最後一行；通常指向你的主策略組或 `DIRECT`

GEOIP 與 IP-CIDR 類規則往往牽涉「先解析出 IP 再比對」還是「只看網域」的細節。若你發現某些網站「有時走代理、有時直連」，優先檢查 DNS 是否與規則預期一致，以及是否有 no-resolve 之類修飾改變了匹配路徑。這類問題不屬於單行語法錯誤，而是流量解析鏈路的整體設定問題。

Rule Providers：把「超大規則表」變成可訂閱的模組

當你需要維護上千條網域規則時，全寫進主設定檔會讓版本管理與合併衝突變得痛苦。Rule Providers 的做法是：在 rule-providers 區塊宣告一個名稱、來源 URL、格式（如 yaml 或 text）、更新間隔 interval，必要時設定 behavior（決定展開成哪種匹配類型）。接著在 rules 裡用 RULE-SET,provider_name,policy 一行的方式引用，核心會在執行時把遠端規則集展開為實際規則。

這帶來三個實際好處：主設定檔保持精簡；規則集可由社群或機場獨立更新；你可以在同一專案裡組合多個 Provider（例如「媒體類」「廣告攔截」「開發者站」分開維護）。要注意的是，Provider 仍然受「規則順序」約束：你在 rules 裡插入 RULE-SET 的位置，就決定了這批規則相對於其他手寫規則的優先權。

rule-providers:
  media:
    type: http
    behavior: classical
    url: "https://example.com/rules/media.yaml"
    path: "./ruleset/media.yaml"
    interval: 86400

rules:
  - RULE-SET,media,手動選擇
  - GEOIP,CN,DIRECT
  - MATCH,手動選擇

與訂閱的 proxy-providers 不同 proxy-providers 負責拉節點清單；rule-providers 負責拉規則集。兩者名稱空間不同，請勿混淆。若更新失敗，請在客戶端日誌中查看 HTTP 錯誤或格式解析錯誤。

DNS 與規則：分流「看起來怪」時先查這裡

規則再漂亮，若 DNS 先把網域解析到「不符合你預期」的 IP，GEOIP 與部分基於 IP 的規則就會跟著偏離預期。常見做法包括：在設定檔中指定可信的 DNS 上游、為不同網域使用不同解析策略、以及避免敏感網域被污染。完整 DNS 專題超出本文篇幅，但請記住：分流是「網域／IP／行程」與「DNS 行為」的聯立題，單改 rules 有時無法根治。

若你希望在地流量穩定直連，請確認最後的 MATCH 或 GEOIP,CN 與你的實際需求一致；若你常跨區存取雲端主機，也要留意目標是網域還是裸 IP，對應規則類型是否正確。

一份可長期維護的分流「骨架」

以下是一份偏結構化的思路，方便你複製後再依環境填空：先固定「必須直連」與「必須代理」的小清單，再用 Rule Providers 承接大宗網域分類，最後用 GEOIP 或 MATCH 收尾。機場訂閱通常已內建類似骨架，你只需在 UI 或覆寫檔裡調整少數策略組名稱與插入點。

列出離不開直連的服務（網路銀行、區域政府網站、區域 CDN）— 用精確 DOMAIN 或可信規則集置頂。
為「國際媒體、開發者站、AI 服務」建立獨立策略組，避免全擠在同一個自動測速組。
將大型網域清單改為 Rule Providers，設定合理快取路徑與更新間隔。
保留一行清晰的兜底規則，並在客戶端確認其指向符合你預期的預設策略組。

維護時請習慣備份完整 YAML，並在變更後觀察日誌命中與實際延遲，而不是只憑感覺切換節點。這樣當訂閱更新或機場調整規則集時，你能快速判断是「節點品質」還是「規則順序」出了問題。

常見誤區與排查順序

第一，以為規則「越多越好」。實際上規則越多，除錯越難；應優先保證順序正確，再用 Provider 模組化。第二，複製他人設定檔卻未改策略組名，導致規則指向不存在的名稱，載入時直接失敗或默默退回預設。第三，忽略訂閱覆寫與本機覆寫的合併順序：不同客戶端合併規則的方式不同，遇到「我明明改了檔案卻沒生效」，請先確認最終送進核心的設定內容。

建議排查順序：確認核心版本（與 Meta 升級文一致）→ 確認設定檔語法載入成功 → 從日誌觀察命中規則 → 再檢查 DNS 與 GEOIP 資料是否過期。多數「偶發走錯線」都能在這四步內定位。

寫在最後：結構對了，分流才會越用越順

相比一次性的節點測速，規則分流更像是幫網路流量建立「長期可維護的路由表」。當你把策略組當成清晰的邏輯層、把 Rule Providers 當成可更新的模組、並嚴格遵守由上而下的匹配順序，Clash 就不再只是開關代理的工具，而會變成可依場景精細調校的網路控制台。相較介面繁瑣、設定項四散的方案，把核心能力放在「看得懂的 YAML 結構」上，長期維護成本通常更低。

若你希望客戶端在視覺化介面中完成訂閱匯入、策略切換與規則除錯，並內建最新 Meta 核心，不妨直接從我們的下載中心取得適合你系統的版本，省去手動拼湊的時間。

→ 立即免費下載 Clash 客戶端，以視覺化方式管理訂閱與分流，搭配 Meta 核心完整發揮規則與 Rule Providers 能力

想先確認核心與新協定設定，可延伸閱讀Clash Meta 核心升級完整教學；若還需要更多主題，歡迎在技術專欄持續追蹤更新。