Clash 策略群組類型怎麼選:url-test、fallback 與 load-balance 差異解析

策略群組:流量的分岔口

在一份 Clash 設定裡,rules 決定「哪類流量交給誰處理」,proxy-groups 決定「接到流量的這一組,最終從哪個節點出站」。除了手動選擇的 select 群組,Clash 核心(含 mihomo)還提供三種自動策略群組:url-test、fallback、load-balance。三者都不需要手動切節點,但自動的邏輯完全不同:一個盯延遲,一個盯存活,一個做分流。

先講結論,再逐一展開:日常瀏覽圖省事,用 url-test;手上有明確的主力節點、只要故障能兜底,用 fallback;想把多條線路的頻寬疊加起來,用 load-balance。

url-test:延遲最低者上場

url-test 是使用頻率最高的自動策略群組。運作機制分兩步:每隔 interval 秒,群組內每個節點各自向 url 指定的位址發起一次探測請求,記錄往返耗時;有新連線進入該群組時,核心把連線交給最近一次測速中延遲最低且通過檢查的節點。

兩個參數直接決定它好不好用:

• tolerance:容差,單位毫秒。候選節點必須比目前節點快出這個數值,才會發生切換。幾個節點延遲相近時,沒有容差會來回抖動,連線被反覆重建。
• lazy:開啟時,只在該群組有流量通過時才測速;關閉則按 interval 持續在背景探測。節點數量多的訂閱建議保持開啟,減少不必要的探測流量。

proxy-groups:
  - name: 自動選優
    type: url-test
    proxies:
      - 香港 01
      - 香港 02
      - 日本 01
    url: http://www.gstatic.com/generate_204
    interval: 300
    tolerance: 100
    timeout: 5000

有個常見誤解要拆開講:延遲低不等於速度快。204 探測只是一個小請求的往返時間,反映線路回應快慢,不反映頻寬大小。下載大檔案慢,未必是選錯了節點,可能是節點本身頻寬就小。

適用場景:同一地區有多個品質相近的節點,日常瀏覽、串流、一般下載交給它自己挑就好。mihomo 另支援 expected-status 指定期望的回應狀態碼,探測若回傳非預期狀態即判定該次檢查失敗,可用於識別「能連上但回應異常」的線路。

fallback:主力掛了才換

fallback 不比較延遲,只判斷通與不通。它嚴格按照 proxies 清單的順序運作:永遠使用清單中第一個健康檢查通過的節點。目前節點連續失敗達到 max-failed-times 上限後會被標記為不可用,流量自動落到下一個可用節點;排在前面的節點恢復健康後,再自動切回去。

proxy-groups:
  - name: 故障轉移
    type: fallback
    proxies:
      - 專線主力
      - 備用中繼 A
      - 備用中繼 B
    url: http://www.gstatic.com/generate_204
    interval: 120
    max-failed-times: 3

與 url-test 的本質差異:url-test 是在「都能用」的節點裡挑最快的,fallback 只認順序——就算備用節點延遲更低,也絕不主動切換。這正好符合一種常見情況:主力是貴而穩的專線,備用是一般線路,平時一毫秒都不想讓流量跑到備用上。

健康檢查間隔決定故障發現速度,所以 fallback 的 interval 可以比 url-test 調小,例如 120 秒。再小意義不大,只會增加探測流量與日誌噪音。

load-balance:連線分攤到多條線路

前兩種群組在任一時刻只有一個出口節點,load-balance 讓群組內節點同時運作:每條新連線按 strategy 指定的策略分配給不同節點。

• consistent-hashing(預設):按目標位址做雜湊,同一網站的連線固定落到同一節點。就網站端而言出口 IP 穩定,適合日常混合使用。
• round-robin:逐條連線輪替節點。多執行緒下載工具一次建立幾十條連線時,流量會被均勻分攤,多條線路的頻寬得以疊加。

proxy-groups:
  - name: 負載均衡
    type: load-balance
    proxies:
      - 節點 A
      - 節點 B
      - 節點 C
    url: http://www.gstatic.com/generate_204
    interval: 300
    strategy: round-robin

代價同樣明顯:不同連線會從不同的出口 IP 出站。網路銀行、支付、帳號登入這類對 IP 一致性敏感的場景,出口頻繁變動容易觸發風控,輕則要求重新驗證,重則暫時限制登入。穩妥的做法是用規則把這類網域單獨指向固定節點或直連,其餘流量再進負載均衡群組。

三種策略群組怎麼選

一句話選型:節點品質相近、圖省事,選 url-test;節點有明確等級、只接受故障兜底,選 fallback;追求吞吐量、能接受出口 IP 變動,選 load-balance。拿不準就先建一個 url-test,它能覆蓋絕大多數日常需求。

組合用法與常見坑

策略群組可以互相嵌套,群組名本身就是合法成員。常見寫法是把自動群組塞進一個 select 群組,rules 只引用最外層:

proxy-groups:
  - name: 主代理
    type: select
    proxies:
      - 自動選優
      - 故障轉移
      - DIRECT
  - name: 自動選優
    type: url-test
    proxies:
      - 香港 01
      - 香港 02
      - 日本 01
    url: http://www.gstatic.com/generate_204
    interval: 300

平時走「自動選優」,需要固定出口時在客戶端代理頁手動切到「故障轉移」或 DIRECT,規則檔案一行都不用動。mihomo 使用者還可以用 use 欄位引用 proxy-providers,把訂閱裡的節點成批納入群組內,搭配 filter 正規表示式篩選,省去逐個列名的維護工作。

改動會被訂閱更新覆蓋

直接編輯訂閱產生的設定檔,下次更新訂閱時改動會被覆蓋。長期自訂請使用 Clash Verge Rev 設定頁的合併(覆寫)功能,把策略群組寫進擴充設定,而不是訂閱檔案本體。

interval 不是越小越好

探測間隔太短,幾十上百個節點輪番發送探測請求,CPU、電量與流量都在消耗,日誌也會被健康檢查刷屏。日常設定 300 秒左右是合理的起點;fallback 可以稍短,但不建議低於 60 秒。

探測位址本身要穩定

三種群組都依賴健康檢查:探測請求經節點發出,位址不可達就判定節點失敗。選一個長期穩定的 204 探測位址;某天整組節點集體「逾時」,先懷疑探測位址失效,再懷疑節點本身。

群組名引用要一致

rules 裡引用的群組名必須與 proxy-groups 中的 name 完全一致,多一個空格都會比對失敗。改完設定看一眼日誌頁,載入報錯會直接指出問題所在行。