Clash 策略組類型對比:url-test、fallback 與 load-balance 各適合什麼場景

01 · 出發點

三種策略組解決的不是同一個問題

很多人第一次接觸 Clash 或 Clash Meta(mihomo 核心)的設定檔時,會把 proxy-groups 裡的 type 欄位當成「選一個自動模式就好」的開關,遇到問題再換一種試試看。 這種試錯方式能用,但效率低,而且換錯類型有時反而會掉進新的坑——比如原本想要低延遲,卻選了偏向「能連就好」的 fallback, 延遲沒有明顯改善;或者原本想分攤頻寬壓力,卻選了 url-test,結果流量全部集中在測速最快的那一兩個節點上。

三者的核心差異可以先用一句話概括:

• url-test 關心「誰最快」,持續測速並自動切換到延遲最低的節點。
• fallback 關心「誰能用」,依設定順序找第一個健康的節點,不主動追求最快。
• load-balance 關心「怎麼分」,把並發請求依演算法分散到多個節點上,不是單點最優。

接下來分別拆解它們的判定邏輯和關鍵參數,理解邏輯之後,類型該怎麼選基本就不需要再靠試錯了。

02 · url-test

url-test:延遲優先的自動選擇

url-test 會週期性地對群組內每個節點發出一次 HTTP 請求(請求目標由 url 參數指定),記錄回應耗時作為該節點的延遲值,然後把目前流量切換到延遲最低的節點上。 它是「面板上顯示自動測速節點延遲」這類介面功能背後最常見的實作方式,新手接觸的第一個自動策略組通常就是它。

關鍵參數說明:

tolerance 是最容易被忽略但影響體驗的參數。如果不設定容差,兩個節點延遲只要有 1 毫秒差異就會觸發切換, 高頻切換會導致長連線(比如影片播放、下載任務)被打斷重新連線。設定成 50ms 左右的容差,相當於告訴客戶端「差距不明顯就別換」, 換來的是連線穩定性,代價是不會達到理論上的絕對最優。

proxy-groups:
  - name: 自动选择
    type: url-test
    url: http://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    proxies:
      - 香港01
      - 新加坡02
      - 日本03

適合情境:對延遲敏感、單一節點即可滿足頻寬需求的用途,比如網頁瀏覽、即時通訊、遊戲加速。 它不會主動分流,所有流量預設都走同一個「目前最優」節點,這點和 load-balance 正好相反。

03 · fallback

fallback:保障可用性的備援機制

fallback 同樣會對群組內節點做健康檢測,但判定邏輯不是「選最快」,而是「按順序找第一個能用的」。 設定裡 proxies 清單的排列順序就是優先順序:客戶端會先嘗試排在最前面的節點, 只要它能通過健康檢測(同樣透過 url 參數判斷連通性),就會一直使用它,不會因為後面的節點延遲更低而切換。 只有目前節點被判定為不可用時,才會依序往後嘗試下一個。

proxy-groups:
  - name: 稳定备援
    type: fallback
    url: http://www.gstatic.com/generate_204
    interval: 180
    proxies:
      - 主力节点-专线
      - 备用节点-香港
      - 备用节点-日本

適合情境:有一個明確的「首選節點」(比如專線、自建中繼、企業內網出口),只是希望它斷線時能自動切換到備用線路, 而不是讓系統在多個節點之間頻繁比較延遲。常見於對連線穩定性要求高於速度的場合,比如需要長時間保持在線上的遠端會議、 對丟包敏感的語音通話,或是本身就只信任某一條特定線路、其餘節點僅作應急備援的情況。

需要注意的是,interval 決定健康檢測頻率,間隔設定太長會導致節點已經失效但客戶端還沒察覺, 產生一段時間的連線失敗;間隔太短又會增加不必要的檢測流量和開銷,一般 120~300 秒是比較均衡的區間。

04 · load-balance

load-balance:分攤流量的負載平衡

load-balance 的目標不是選出一個「最優節點」,而是把不同的連線請求分散到群組內多個節點上, 避免流量長期集中在單一出口。它透過 strategy 參數決定分配演算法,常見的兩種是:

• consistent-hashing(一致性雜湊):依連線的來源位址等資訊計算雜湊值分配節點,相同來源的連線大機率會穩定落在同一節點上,適合需要維持連線狀態的情境。
• round-robin(輪詢):依順序依次把新連線分配給下一個節點,分配更均勻,但不保證同一來源的連線固定走同一節點。

proxy-groups:
  - name: 分流均衡
    type: load-balance
    strategy: consistent-hashing
    url: http://www.gstatic.com/generate_204
    interval: 300
    proxies:
      - 节点A
      - 节点B
      - 节点C

適合情境:單個節點頻寬或並發連線數容易觸頂的情況,比如多裝置共用同一套訂閱、下載任務較多、 或者節點本身有並發連線數限制。把流量分散到多個節點後,單點壓力下降,整體吞吐量更容易接近多個節點頻寬之和, 而不是被卡在某一個節點的頻寬上限裡。

05 · 對照

三種類型的參數與情境對照

實際設定檔裡,這三種類型完全可以組合使用,並不是「選一種用到底」。比如把 fallback 作為最外層的總入口, 備用線路本身又是一個 url-test 群組,專門在多個海外節點之間挑最快的;而單獨給下載工具分流出去的規則, 再指向一個 load-balance 群組,避免大檔案下載佔滿某一個節點的頻寬,影響其他應用程式的使用體驗。 這種分層設計比單一策略組更貼近真實使用情境,也是查看別人分享的複雜設定檔時經常能看到的結構。

另外提一點容易被忽略的細節:url 參數指向的偵測位址如果本身不穩定或被限速, 會直接影響三種策略組的判定結果——url-test 會測出偏高的延遲,fallback 可能誤判節點不可用, load-balance 的健康檢測也會失真。選用輕量、回應快、覆蓋範圍廣的偵測位址,是這三種自動策略組都能正常運作的前提條件, 排查「自動選擇結果不對」的問題時,也應該把偵測位址本身的可用性放進排查清單。