Clash 策略組選型指南:url-test、fallback、load-balance 區別與適用場景

策略組是什麼:決策組與執行組的關係

Clash 與 Clash Meta(mihomo)的設定檔裡,proxies 段列出的是具體的代理節點,而 proxy-groups 段定義的是「策略組」——一種把多個節點或多個下級策略組打包起來、按某種規則決定實際走哪一條的邏輯單元。規則(rules)段最終指向的往往不是某個具體節點,而是某個策略組的名字,由策略組在執行時決定流量落到哪個節點上。

目前主流的策略組類型有四種:select(手動選擇)、url-test(自動測速選擇)、fallback(故障轉移)、load-balance(負載均衡)。四者共享相同的欄位結構(name、type、proxies),但判定邏輯完全不同,混用不當會導致「明明配了備用節點卻不切換」或者「節點頻繁跳動」之類的問題。理解每種類型的觸發條件,是設定一份穩定訂閱規則的前提。

select:手動選擇型策略組

select 是最基礎的類型,它本身不做任何測速或健康檢查,單純把一組節點或策略組擺出來給使用者在客戶端介面裡手動切換。預設顯示 proxies 清單裡第一個,切換後客戶端會記住上次選擇(寫入執行時狀態,不會更動設定檔本身)。它的典型用途是作為頂層入口組,讓使用者在「自動選優」和「直接手動指定某個節點」之間自由切換。

proxy-groups:
  - name: 节点选择
    type: select
    proxies:
      - 自动选优
      - 香港中转
      - 日本专线
      - DIRECT

由於沒有測速與故障偵測,select 組裡放進去的節點如果本身已經失效,流量依舊會被硬塞過去直到使用者手動切換。因此實務中通常不會把裸節點直接鋪滿 select,而是把測速類的下級策略組(比如下文的 url-test 組)作為選項之一放進來,兼顧手動可控與自動兜底。

url-test:自動測速與切換判定機制

url-test 組會週期性地向設定的測試位址發起請求,記錄每個節點的回應延遲,並自動選用目前延遲最低、且延遲差異超過容差閾值的節點。核心欄位有三個:

• url:測速請求目標,通常用一個國際可達的輕量位址;
• interval:測速週期,單位秒,過短會增加節點負擔和電量消耗,過長則故障發現變慢;
• tolerance:容差值,單位毫秒。只有新的最優節點比目前節點快出容差值以上才會真正切換,避免延遲在幾毫秒範圍內抖動導致節點反覆跳變。

proxy-groups:
  - name: 自动优选
    type: url-test
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 50
    proxies:
      - 香港中转
      - 新加坡专线
      - 日本专线

url-test 適合節點數量較多、且希望「誰快用誰」而不關心具體是哪一個的場景,比如日常瀏覽、看影片這類對延遲敏感但不要求固定線路的用途。它的侷限在於測速結果只反映測速那一刻的網路狀況,如果實際業務流量的目標伺服器與測速位址網路路徑差異很大,選出來的「最優」未必是業務場景下真正最快的節點。

fallback:故障轉移的觸發條件與延遲

fallback 組按 proxies 清單裡的順序依次探測,優先使用排在前面且探測通過的節點,只有目前使用的節點探測失敗(逾時或回傳非預期狀態)時才會依序切換到下一個可用節點。它同樣依賴 url、interval 兩個欄位做健康檢查,但判定邏輯與 url-test 不同:url-test 比的是「哪個最快」,fallback 比的是「排在前面的是否還活著」。

proxy-groups:
  - name: 故障转移
    type: fallback
    url: "https://www.gstatic.com/generate_204"
    interval: 180
    proxies:
      - 主用专线
      - 备用专线-A
      - 备用专线-B

fallback 適合有明確優先順序、希望「非必要不切換主線路」的場景,例如把穩定但成本較高的專線放第一位,把速度一般但勝在穩定的備用節點排在後面,只在主線路真正斷線時才切走,而不是因為主線路某一次測速延遲稍高就跳走。需要注意的是,fallback 的健康檢查間隔決定了故障發現的延遲——偵測週期設得太長,主線路故障後會有一段時間流量仍卡在失效節點上;設得太短又會增加探測請求的頻率。

load-balance:負載分攤的兩種策略

load-balance 組不追求「選出唯一最優」,而是把請求分攤到多個節點上,常用於希望多條線路共同分擔頻寬壓力、避免單一節點長時間承擔全部流量的場景。它透過 strategy 欄位指定分配演算法,主要有兩種取值:

• consistent-hashing:按請求的目標位址做一致性雜湊,同一個目標網域/IP 會穩定落到同一個節點,適合需要會話保持(比如某些需要固定出口 IP 才能正常登入的站點)的場景;
• round-robin:按輪詢順序把請求依次分配給不同節點,分攤更均勻,但同一個目標在不同請求之間可能落到不同節點,不適合對出口 IP 一致性有要求的業務。

proxy-groups:
  - name: 分流负载
    type: load-balance
    strategy: consistent-hashing
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    proxies:
      - 专线-A
      - 专线-B
      - 专线-C

load-balance 組同樣帶健康檢查,失效節點會被自動排除在分配範圍之外。它更適合多條同質化線路(頻寬、延遲相近)並存、目的是分攤壓力而非擇優的場景,如果幾條線路品質差異明顯,盲目負載均衡反而會讓請求隨機落到較差的節點上,體驗不如 url-test 穩定。

常見分組組合與實務建議

實際設定中很少只用單一類型,更常見的是分層組合:頂層放一個 select 組供使用者手動干預,下面掛多個不同策略的子組,再由 rules 按網域/IP 規則分派到具體的子組。一個常見結構如下:

proxy-groups:
  - name: 出站策略
    type: select
    proxies:
      - 自动优选
      - 故障转移
      - DIRECT

  - name: 自动优选
    type: url-test
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 50
    proxies: [专线-A, 专线-B, 专线-C]

  - name: 故障转移
    type: fallback
    url: "https://www.gstatic.com/generate_204"
    interval: 180
    proxies: [主用专线, 备用专线-A]

選型時可以按下面的思路判斷:如果目標是「平時自動挑最快、允許偶爾跳動」,用 url-test;如果目標是「有明確主備順序、不希望輕易離開主線路」,用 fallback;如果目標是「多條線路一起扛流量」,用 load-balance;如果目標只是「給使用者一個手動開關」,用 select。四者可以互相嵌套——比如把一個 url-test 組作為 select 組的一個選項,既保留自動選優,又保留手動指定單一節點的退路。

另外需要提醒的是,策略組的判定只覆蓋代理層面的連通性與延遲,不涉及規則比對是否命中、DNS 解析是否走了正確的出口、TUN 模式下系統路由表是否生效等其他環節。如果切換策略組後問題依舊,建議先確認規則段是否真的把目標流量指向了這個策略組,再回頭檢查測速位址與容差參數是否合理,逐層排查比一次性更動多個欄位更容易定位問題所在。