Clash 規則分流深度教學：自訂規則組，精準控制每一條流量

為什麼規則分流是 Clash 的核心能力

許多人第一次接觸 Clash 時，最先注意的是「訂閱匯入」與「一鍵連線」。但真正讓它適合長期日常使用的，往往是規則分流：同一台電腦上，工作用的雲端後台可以直連以降低延遲，影音或社群走你信任的出口，開發工具存取套件庫時又可以單獨走另一組策略。這種細緻度，來自兩個彼此配合的區塊——proxy-groups（策略組）與rules（規則列表）。

你可以把策略組想成「可供規則指向的出口名稱」，例如 PROXY、DIRECT、Streaming、AI。規則則依由上而下的順序逐條比對：第一條命中後就不會再往下看。因此，分流是否精準，一半取決於你怎麼設計策略組，一半取決於規則的排序與粒度。

若你希望先建立對 Clash 整體設定的全貌，可先閱讀站內的使用說明文件；若關心各代理協定與核心能力差異，也可一併參考協定說明頁。

自訂 Proxy Group：先把「出口」定義清楚

在撰寫任何 DOMAIN 或 GEOIP 規則之前，建議先整理你真正需要的幾類出口。常見做法不是只有一個 PROXY，而是依場景拆開，避免「所有境外流量都擠在同一個 url-test 組」導致無法針對性調優。

select：手動選擇

select 類型會在客戶端顯示為可點選的清單，適合明確指定節點或作為其他組的「上層開關」。例如一個名為 Region 的 select，底下再掛多個 url-test 子組，便能在維持自動測速的同時，快速切換地區。

url-test：依延遲自動選路

url-test 會週期性對候選節點發起探測（預設以 TCP 握手或 HTTP 請求衡量延遲），並自動選用較快的一個。適合一般上網這類對「當下最快」敏感、但不需要固定 IP 的場景。調整時請留意 interval 與 tolerance：間隔太短會增加無謂流量；容差太小則節點頻繁切換，體感反而不穩定。

fallback：依可用性故障轉移

fallback 同樣會探測，但設計目標是優先使用列表前端節點，當其不可用時才往後遞補。它更適合「必須有備援」的業務出口，而不是單純比誰延遲低。

load-balance：分散負載（進階）

在支援的實作中，load-balance 可依雜湊將連線分散到多個節點。若你的訂閱允許並發連線、且目標服務不綁定單一 IP，可用它降低單節點壓力；但若服務對 IP 一致性要求高，反而應避免對該域名走負載均衡。

規則順序：為什麼「第一條命中」決定一切

Clash 的規則引擎是有序列表，不是「全表打分」。這代表：

• 越具體、越需要例外的規則，應該越靠上。
• 寬泛規則（例如整段 GEOIP,CN）若放得太前，會提前結束匹配，導致後方細粒度規則永遠失效。
• 診斷「為什麼這條連線沒走我預期的組」時，第一步永遠是確認最先命中的是哪一條。

一個穩健的排序思路是：區域網與本機保留位址直連 → 明確要直連或要走特定組的域名／規則集 → 地區或類別規則 → 最後一條 MATCH 總則。總則通常寫成 MATCH,PROXY 或 MATCH,DIRECT，視你的預設立場而定。

常用規則類型與適用情境

DOMAIN 與 DOMAIN-SUFFIX

DOMAIN,www.example.com,PROXY 只匹配完整主機名；DOMAIN-SUFFIX,example.com,PROXY 則匹配該域及其子域。後者在維護上較省事，但要小心過寬的後綴把 CDN 邊緣節點整包送入代理，反而增加延遲。遇到只影響單一子域的情況，優先考慮更精確的 DOMAIN 或關鍵字規則。

DOMAIN-KEYWORD

關鍵字匹配威力強大但也容易誤傷：任何包含該字串的域名都會命中。建議僅在確定不會與無關域名碰撞時使用，或搭配更嚴格的規則集由上游維護。

IP-CIDR 與 GEOIP

當連線目標已經是 IP（或域名已解析為 IP）時，IP-CIDR 與 GEOIP 特別有用。GEOIP,CN,DIRECT 是常見的「國內直連」寫法；若你使用 fake-ip 模式，請同步理解 DNS 與規則的互動，避免以為「走了直連」實際上解析與連線階段不一致。更多與 TUN、DNS 的配合可交叉參考站內 TUN 模式專文與官方文件。

RULE-SET：把規則外包給可更新的集合

當規則數量變大，手動維護單調列表既易出錯也難以協作。RULE-SET 讓你把一整包規則當成一個邏輯條目，並透過 rule-providers 指定來源、格式與更新間隔。這樣社群或專案維護的「廣告攔截」「流媒體域名」「雲端後台 IP」列表，都能以較低摩擦整合進你的設定。

最小可讀範例：分層策略與規則骨架

下列範例僅用於說明結構，實際節點名稱請替換為你訂閱中的 proxies。註解使用英文以利工具相容。

proxy-groups:
  - name: DEFAULT
    type: select
    proxies:
      - AUTO
      - DIRECT

  - name: AUTO
    type: url-test
    proxies:
      - Node-A
      - Node-B
    url: https://www.gstatic.com/generate_204
    interval: 300

  - name: STREAM
    type: select
    proxies:
      - Node-Streaming-1
      - Node-Streaming-2
      - AUTO

  - name: WORK
    type: select
    proxies:
      - DIRECT
      - Node-Office

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

rules:
  - DOMAIN-SUFFIX,corp.internal,WORK
  - RULE-SET,streaming,STREAM
  - GEOIP,CN,DIRECT
  - GEOIP,private,DIRECT,no-resolve
  - MATCH,DEFAULT

這個骨架示範了幾件事：先把業務相關域名指到 WORK；再把影音規則集指到 STREAM；其後才用 GEOIP 處理大範圍直連；最後以 MATCH 收斂預設策略。

除錯思路：當分流不如預期時

實務上最常見的問題不是語法錯誤，而是命中了意料之外的規則。建議依序檢查：

1. 客戶端連線日誌：多數圖形客戶端會顯示域名、規則名稱與實際策略組，請先確認命中規則的「名稱」對應到哪一條。
2. 規則集是否更新：rule-providers 若下載失敗或快取過期，可能導致規則集為空或舊版，行為與你想像的不同。
3. DNS 與 fake-ip：在 fake-ip 模式下，部分工具看到的 IP 並非真實解析結果；診斷時要以 Clash 日誌與規則命中為準，而不是僅看瀏覽器外掛顯示。
4. IPv6 與雙棧：若系統優先走 IPv6，而規則只覆蓋 IPv4 段，可能出現「看似規則沒生效」的情況；可配合網路設定或在 DNS 區塊關閉 IPv6 解析（視核心與客戶端支援而定）。

可維護性：讓設定半年後你還看得懂

隨著規則增長，建議採用分層註解與命名慣例：在檔案中用區塊註解劃分「區網與本機」「訂閱維護的規則集」「個人微調」；對個人微調區維持精簡，避免把上千行臨時規則堆在總檔底部。若客戶端支援配置片段合併，可把 rule-providers 與自訂規則拆檔，降低合併衝突。

相比「全機流量一律同一出口」的傳統 VPN，Clash 的分流模型在學習曲線上稍陡，但一旦策略組與規則層次搭好，你就能在延遲、穩定與隱私之間取得屬於自己的平衡，而不必為了某一個網站頻繁手動切換全局模式。

小結與下一步

這篇文章從策略組設計、規則順序、常見規則類型，一路整理到 rule-providers 與除錯思路。掌握這套方法後，你不再只是「匯入訂閱然後全選自動」，而是能依工作與生活場景，真正把每一條連線分配到合適的出口——這正是 Clash 類工具在長期使用中最值得投資時間的部分。

若你偏好圖形介面管理訂閱與策略、並希望減少手動編輯 YAML 的時間，可以選擇一款與 Mihomo 核心相容、介面清晰的客戶端；相比零散拼湊的腳本與過時核心，成熟客戶端在規則除錯、連線日誌與更新節奏上通常更省心，日常體驗也更容易保持穩定。

立即免費下載 Clash，開啟流暢上網新體驗 →