Clash 策略組怎麼選:url-test、fallback、load-balance 三種類型實測差異

策略組解決的是「選哪個節點」的問題

一份 Clash / Clash Meta(mihomo)設定檔裡,proxies 列出的是所有可用節點,proxy-groups 才是真正決定流量走向的地方。規則(rules)只負責判斷一條連線該交給哪個策略組,策略組內部再決定具體挑哪個節點出站。如果只寫一個 select 類型的手動策略組,選路完全靠人工點選,節點掛了也不會自動切換。這就是為什麼絕大多數設定都會額外準備幾個自動化策略組——它們按各自的演算法,把「挑節點」這件事交給程式而不是人。

mihomo 支援的自動化策略組主要有三種類型:url-test(自動測速)、fallback(故障轉移)、load-balance(負載均衡)。三者共用一套健康檢查機制,但判斷邏輯和適用場景完全不同,混著用效果會打折。下面按參數、行為、場景逐一拆開講。

url-test:按延遲自動選最快節點

url-test 是最常見的自動化類型,核心邏輯是:定期用組內每個節點去請求一個測試位址,記錄回應耗時,然後把目前流量導向耗時最低的那個節點。它解決的是「這麼多節點,哪個此刻最快」的問題,適合大多數以延遲為核心指標的日常場景。

proxy-groups:
  - name: 自動選擇
    type: url-test
    proxies:
      - 香港01
      - 香港02
      - 新加坡01
      - 日本01
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 50
    lazy: true

url:測速請求打向的位址,通常使用輕量、能穩定回傳 204 的位址,避免測試請求本身占用過多頻寬,或因網路審查干擾判斷結果。
interval:兩次測速之間的間隔,單位為秒。上面範例是 300 秒測一次,間隔太短會讓節點頻繁被送測速請求,太長又會導致節點變慢後遲遲沒被換掉。
tolerance:容差值,單位為毫秒。只有當新測得的最快節點比目前使用節點快出這個容差值以上,才會真正切換。設定容差是為了避免兩個延遲接近的節點來回抖動切換,造成連線頻繁中斷。
lazy:設為 true 時,只有組內有連線正在使用才會觸發測速,後台閒置不測速,省流量也省節點負擔;設為 false 則無論是否被使用都會按 interval 定時測速。

需要注意,tolerance 不是「延遲門檻」,而是「切換門檻」。比如目前使用的節點延遲 120ms,另一個節點測出 100ms,容差設的是 50ms,那麼 20ms 的差距不夠大,不會切換;只有差距超過 50ms 才會真正換節點。這個設計是為了避免為了幾毫秒的差異反覆跳來跳去。

fallback:第一優先順序失效才換下一個

fallback 的判斷邏輯跟 url-test 完全不同,它不比較誰最快,只關心「節點是否存活」。組內節點按設定順序排出優先順序,系統始終優先使用清單裡排在最前面且健康檢查通過的節點,一旦目前使用的節點測速失敗(逾時或連不上),才會依次往後嘗試,直到找到一個能連通的節點。

proxy-groups:
  - name: 故障轉移
    type: fallback
    proxies:
      - 主力節點-香港
      - 備用節點-新加坡
      - 備用節點-日本
    url: "https://www.gstatic.com/generate_204"
    interval: 180
    tolerance: 0

這裡的順序就是優先順序,主力節點-香港排第一,只要它健康檢查正常,流量就一直走它,即使後面的節點延遲更低也不會搶占。這跟 url-test「誰快用誰」的逐利策略正好相反,fallback 追求的是穩定與可預期,適合你已經明確知道哪個節點線路品質最好、只是想在它偶爾出狀況時有個保底方案的場景,比如給某個固定專線節點配一到兩個備援。

fallback 裡的 tolerance 參數意義不大,因為它不做「快慢比較切換」,只做「能不能連通」的二元判斷,大多數設定直接設為 0 或省略即可。真正起作用的是 url 和 interval,這兩個參數決定了健康檢查多久跑一次、往哪個位址跑,間隔太長會導致主節點故障後有一段時間流量還打在失效節點上。

load-balance:把流量分散給多個節點

load-balance 解決的是另一類問題——不是「選最快的一個」,而是「把並發連線分散到多個節點上」,常見目的是分攤單一節點的頻寬壓力,或者讓多個品質相近的節點都有事做,避免某一個節點長期滿載而其他節點閒置。

proxy-groups:
  - name: 負載均衡
    type: load-balance
    proxies:
      - 香港01
      - 香港02
      - 香港03
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    strategy: consistent-hashing

strategy 參數是這個類型的關鍵,mihomo 提供兩種分配演算法:

consistent-hashing(一致性雜湊):按連線的來源位址、目標位址等資訊計算雜湊值,固定分配到某個節點。同一個目標站點、同一個來源大機率始終落在同一節點上,好處是同一個會話不會因中途換節點導致登入狀態遺失或下載中斷,適合長連線、需要會話保持的場景。
round-robin(輪詢):新連線依次輪流分配給組內節點,分配更均勻,但同一個網站的不同請求可能落到不同節點上,遇到對 IP 一致性敏感的服務(比如某些需要驗證碼或登入狀態綁定 IP 的站點)容易出問題。

需要提醒的是,load-balance 不會剔除已經失效的節點重新分配全部流量,它依然依賴健康檢查判斷節點是否存活,失效節點會被暫時跳過,但分配邏輯不做「故障轉移優先順序」那種排序處理。如果組內節點品質差異很大,負載均衡反而會讓部分連線落到慢節點上,體驗不如 url-test 穩定,所以這個類型更適合「節點品質彼此接近、想分散壓力」的場景,而不是「節點品質參差不齊、想挑好的用」的場景。

注意三種類型的 url 測速位址必須能被節點正常存取且回傳穩定,如果測速位址本身在某些地區遭到干擾,健康檢查結果會失真,導致該切換的沒切、不該切的亂切。建議固定使用同一個測速位址,方便排查問題時對照。

三種類型怎麼選:場景對照

類型	判斷依據	典型場景	關鍵參數
url-test	延遲最低者優先	日常上網,追求最佳速度	interval / tolerance
fallback	存活優先順序	已知優選節點 + 備援保底	proxies 順序 / interval
load-balance	分散並發連線	多節點品質接近,想分散壓力	strategy

實際設定中,三種類型也可以嵌套組合。比較常見的做法是先用 url-test 建一個「自動選擇」組作為預設出口,再單獨給某些高優先站點(比如串流媒體、下載工具)配一個 load-balance 組分攤頻寬,同時給關鍵節點配一個 fallback 組當保險。策略組之間可以互相引用——一個 select 組的選項裡既可以放具體節點,也可以放另一個策略組的名稱,這樣上層規則只需要指向最外層的 select,內部的自動化邏輯由內層策略組承擔,設定結構會清晰許多。

常見迷思與排查思路

不少人反映「設了 url-test 但節點一直不切換」,大機率是 tolerance 設得過大,或者組內節點延遲本身差距不明顯,系統判斷沒必要切換。可以暫時把 tolerance 調小到個位數驗證是否恢復切換,確認邏輯正常後再調回合理數值。另一個高頻問題是 fallback 組「主節點明明連不上,卻還在用它」,這通常是 interval 設得太長,健康檢查還沒跑到下一輪,或者測速位址回傳的不是預期的 204 而被誤判為存活。

還有一類迷思是把 load-balance 當成「更快的 url-test」來用,期望它自動挑最優節點,但它的設計目標是分攤而不是擇優,如果組內混入一個明顯較差的節點,部分連線體驗會被拖累,這種情況應該把慢節點移出組,或者乾脆換成 url-test。排查這類問題時,建議在用戶端介面上留意各節點目前測速數值和策略組實際選中的節點,大多數圖形化用戶端(如 Clash Verge、Clash for Windows 系用戶端)都會在策略組介面即時顯示每個節點的延遲和目前選中項,比盯著日誌翻找更直觀。

小結追求速度用 url-test,追求穩定用 fallback,追求分攤壓力用 load-balance;三者可以嵌套組合,但不要指望一種類型解決所有選路需求。