Clash 策略組怎麼選:url-test、fallback、load-balance 三種類型詳解

策略組在配置檔中的位置

Clash 的節點分流依賴 proxy-groups 這一段配置。它把 proxies 裡列出的具體節點打包成一個個「邏輯出口」,規則段 rules 引用的正是策略組的名稱,而不是某個具體節點。這樣做的好處是:換機場、換節點都只需要改 proxies 和 proxy-groups,規則本身不用動一行。

每個策略組必須聲明一個 type,這決定了用戶端在這個組裡「怎麼選節點」。常見的四種類型是 select(手動選擇)、url-test(自動測速)、fallback(故障轉移)、load-balance(負載均衡)。select 最簡單,完全靠人手切換,不在本文討論範圍;後三種都帶「自動決策」邏輯,也是最容易被誤用的三類,下面逐一拆開講。

url-test:延遲驅動的自動測速

url-test 是三種自動類型裡最常見的一種。它的運作方式可以概括為:用戶端按固定週期向組內每個節點發起一次 HTTP 請求(目標位址由 url 欄位指定),記錄往返延遲,然後始終把流量導向當前測得延遲最低的節點。

關鍵欄位說明:

• url:測速目標位址,通常填一個海外可連通、回應快的位址,例如連通性檢測常用的輕量介面;
• interval:測速週期,單位秒,常見取值 300(5 分鐘)左右,過短會增加節點端壓力,過長則延遲變化回應不夠即時;
• tolerance:切換容差,單位毫秒。只有當新節點的延遲比目前節點低出這個容差值,用戶端才會真正切換,避免延遲在兩個節點之間來回抖動導致連線頻繁重建;
• lazy(Clash Meta/mihomo 支援):開啟後,只有在實際發起請求時才會觸發測速,而不是無論有沒有流量都按週期空跑,適合長期掛機、連線數不高的場景。

適用場景很明確:機場提供的是同質化的中轉節點(例如都是同一線路的多個出口),你不在意具體走哪條線,只要延遲最低即可。缺點也在於此——url-test 只看延遲,不看丟包率和實際吞吐量,某些節點延遲低但限速嚴重,測速階段完全看不出來。

fallback:按順序探測的故障轉移

fallback 的邏輯和 url-test 完全不同。它不比較延遲高低,而是嚴格按照 proxies 清單裡節點的先後順序逐一探測可用性:第一個節點只要能連通(探測請求成功),就一直使用它;只有目前使用的節點探測失敗,才會依序切換到下一個還能連通的節點。

這意味著 fallback 天生帶「主備」語義——你需要提前規劃好節點順序,把最想用的主節點放在最前面,備用節點依序排在後面。它的關鍵欄位和 url-test 基本一致(url、interval、tolerance),但 tolerance 在 fallback 裡的作用較弱,因為切換判斷依據是「能不能連通」而不是「延遲差多少」。

典型使用場景:你有一個穩定的自建節點作為主力,同時保留一兩個機場節點作為兜底,平時希望流量優先走自建節點,只有自建節點出問題(斷線、被限速到無法存取)時才自動轉移到備用線路。這種「有主有備、按需接管」的需求,fallback 比 url-test 更貼切——url-test 會因為備用節點某一次測速延遲更低就切過去,而 fallback 不會,只要主節點還通,它就不動。

load-balance:分攤連線的負載均衡

load-balance 解決的是另一類問題:當組內多個節點效能相近、都可用,你希望把並發連線分攤到多個節點上,而不是所有流量擠在一個節點上跑。它的核心欄位是 strategy,常見取值兩種:

• consistent-hashing:按請求的目標位址做一致性雜湊,同一個目標網域/IP 大概率固定分配到同一個節點,這樣能減少因為節點切換導致的連線中斷,對需要保持連線一致性的場景(例如影片播放、下載中的大檔案)更友善;
• round-robin:按輪詢順序依次把新連線分配給組內節點,分配更均勻,但同一個目標位址前後兩次請求可能落到不同節點上。

load-balance 同樣支援 url 和 interval 做健康探測,探測到不可用的節點會被暫時從分配池中剔除,等恢復可用後再重新納入。需要強調的是,load-balance 分攤的是「連線數」,不是即時限速意義上的「頻寬」,如果組內某個節點本身頻寬上限很低,分到它頭上的連線依然會慢,負載均衡不會替你補齊單節點的效能短板。

三種類型該怎麼選

把三者放在一起對比,選型思路可以簡化成一句話:看你要解決的是「選最快的」、「保主備」還是「攤並發」。

• 組內節點線路相近、純粹想要延遲最優 → 用 url-test;
• 有明確的主用節點和備用節點,希望優先用主節點、故障才切換 → 用 fallback;
• 組內節點數量較多、想把並發連線攤開避免單點過載 → 用 load-balance;
• 只是想自己手動切、不需要任何自動邏輯 → 用最基礎的 select。

實際配置中,這幾種類型經常是嵌套使用的:外層用 select 讓使用者在「自動測速」「固定線路」「全部節點手選」之間切換,內層的「自動測速」選項本身又是一個 url-test 組,這樣既保留了自動化,又不失去手動兜底的靈活性。

可直接套用的配置片段

以下是三種類型各自的最小可用配置範例,可以按需替換 proxies 裡的節點名稱後直接貼到 config.yaml 的 proxy-groups 段落裡。

proxy-groups:
  - name: "自動選擇"
    type: url-test
    proxies:
      - "節點A"
      - "節點B"
      - "節點C"
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 50

  - name: "主備切換"
    type: fallback
    proxies:
      - "自建主節點"
      - "機場備用1"
      - "機場備用2"
    url: "https://www.gstatic.com/generate_204"
    interval: 180

  - name: "均衡分流"
    type: load-balance
    proxies:
      - "節點A"
      - "節點B"
      - "節點C"
      - "節點D"
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    strategy: consistent-hashing

Clash Meta(mihomo)核心在此基礎上額外支援 max-failed-times(連續探測失敗多少次才判定為不可用,用於減少偶發網路抖動導致的誤判)和 lazy 參數,如果用戶端標註支援 Meta 核心規則集,可以按需加入這兩個欄位進一步調校,原版 Clash 核心不識別這些欄位,寫了也不會報錯,但不會生效。

常見誤區與排查建議

配置策略組時最容易踩的幾個坑:

1. 把延遲差異很大的節點混進同一個 load-balance 組——負載均衡不挑延遲,慢節點照樣會分到連線,體驗反而不如 url-test;
2. fallback 組裡節點順序寫反,主力節點排在了後面,導致平時優先用的是備用線路;
3. url-test 的 tolerance 設得過小(例如 0 或 5ms),節點延遲本身就有波動,容差太小會導致頻繁切換,連線被反覆打斷;
4. 測速位址 url 選用了中國大陸可直連的位址,導致所有節點測出來延遲都接近,失去了區分節點優劣的意義。

把策略組類型和參數配對好之後,規則段的編寫會順暢很多——因為規則只需要關心「該走哪個策略組」,具體走哪個節點、什麼時候切換,已經交給策略組自身的判斷邏輯處理了。這也是 Clash 分流體系裡規則和節點解耦的核心價值所在。