進階設定 預計閱讀 9 分鐘

Clash 策略組 url-test、fallback、load-balance 差異與設定寫法

三種自動策略組各解決什麼問題:url-test 選最快、fallback 保可用、load-balance 分攤流量。逐一拆解 interval、tolerance、strategy 等參數含義,並給出可直接套用的 YAML 設定範例。

Clash 與 Clash Meta(mihomo 核心)的 proxy-groups 裡,除了手動選擇的 select,還提供三種自動化策略組類型:url-test、fallback、load-balance。三者都會週期性對組內節點做健康檢測,但檢測結果的用途完全不同——一個用來挑最快的,一個用來保證有節點能用,一個用來把流量攤開。不理解這個差異,直接抄網上的設定片段,很容易出現「明明設了自動測速,結果一直用著同一個慢節點」之類的困惑。這篇文章按類型逐一拆解參數,並給出可以直接套用的 YAML 寫法。

三種自動策略組解決的問題不同

先明確一個前提:這三種策略組都需要組內至少兩個可用節點才有意義,單節點組內它們和 select沒有差別。它們的核心差異在於「選中哪個節點」的判斷邏輯:

  • url-test:定期給組內每個節點發測速請求,選延遲最低的一個作為當前出口。目標是「總是用最快的那條線」。
  • fallback:按設定裡節點的順序依次檢測可用性,用第一個檢測通過的節點,只有當前節點失敗才切換到下一個。目標是「保證有節點能連上」,不追求最快,追求穩。
  • load-balance:不做「哪個最好」的判斷,而是把不同請求按演算法分散到組內多個節點上,目標是「把流量攤開」,避免單一節點長期承壓或被針對性限速。

選哪種類型,取決於你更看重延遲、穩定性,還是流量分攤,三者不能互相替代。

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

url-test 是最常用的自動策略組類型,適合「手上有一批節點,不想手動切換,只想始終用延遲最低的那個」的場景。典型寫法:

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

關鍵欄位說明:

  • url:測速請求的目標位址,通常用海外可存取的輕量接口,請求成功即視為節點可用,回應耗時即視為延遲值。
  • interval:測速週期,單位秒。週期太短會增加節點的探測負載,太長則延遲變化後切換不及時,常見取值在 180~600 之間。
  • tolerance:容差值,單位毫秒。只有新測得的延遲比當前節點低出這個容差,才會觸發切換。設定容差是為了避免節點延遲在幾毫秒內抖動就頻繁切換出口,導致連線反覆中斷。
  • lazy:為 true 時,只有該策略組被實際使用時才執行定時測速,組未被選中則暫停探測,減少不必要的請求。
提示

url-test 組切換節點時,已建立的 TCP/UDP 連線不會被打斷,只有新發起的連線會走新選中的節點。如果觀察到下載中的檔案「卡一下」,通常不是策略組切換導致的,更可能是節點本身波動。

fallback:保證可用性的備用切換

fallback 的定位是「主備」而非「擇優」。它按 proxies 清單裡的順序,從第一個開始檢測,只要當前使用的節點還能連通,就不會主動切到後面延遲更低的節點。只有當前節點檢測失敗時,才會依次向後尋找第一個可用的節點。寫法範例:

proxy-groups:
  - name: 备用链路
    type: fallback
    proxies:
      - 主节点-上海中转
      - 备节点-东京直连
      - 备节点-首尔直连
    url: http://www.gstatic.com/generate_204
    interval: 180

fallback 沒有 tolerance 參數,因為它本身不比較延遲高低,只判斷「通」或「不通」。這種類型適合對連線穩定性要求高、不希望節點頻繁切換的場景,例如長期掛在後台的下載任務或需要保持會話的服務。清單順序即優先順序,把最穩定、最看重的節點放在最前面。

load-balance:多節點分攤流量

load-balance 不追求「選最優」,而是把不同的請求分配到組內多個節點上,常用於同時掛多個規格相近的節點、希望流量分攤以避免單節點長期高負載的場景。設定範例:

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

strategy 決定分配演算法,常見兩種:

  • consistent-hashing:按來源位址與目標位址的雜湊值分配節點,同一個連線會話在有效期內固定走同一個節點,適合需要會話保持的場景(例如某些登入狀態依賴出口 IP 一致的網站)。
  • round-robin:按順序輪流分配,新連線依次分給下一個節點,分配更均勻,但不保證同一目標始終走同一節點。

load-balance 同樣會週期性檢測節點可用性,失效的節點會被暫時排除在分配範圍之外,等恢復後再重新納入。它和 url-test 的本質差異是:url-test 永遠只用「當前最優」的一個節點,load-balance 是同時用多個節點分攤請求。

參數含義速查與常見誤區

參數適用類型作用
url三者通用健康檢測請求位址,回應成功判定節點可用
interval三者通用檢測週期,單位秒
tolerance僅 url-test延遲容差,避免節點抖動導致的頻繁切換
lazy僅 url-test策略組未被使用時暫停定時檢測
strategy僅 load-balance流量分配演算法:一致性雜湊或輪詢

幾個容易踩的坑:

  1. fallback 組裡節點順序寫反,導致優先用了延遲更高的備用節點——fallback 不比較延遲,只看清單順序和當前節點是否失效。
  2. 把 tolerance 設為 0,會導致 url-test 組只要新的一輪測速裡有任何節點比當前節點快 1 毫秒就切換,出口頻繁跳動,建議至少保留 30~50 毫秒的容差。
  3. load-balance 裡塞進延遲差異很大的節點(比如把高延遲中轉節點和低延遲直連節點混在一組),分攤流量後整體體驗反而不如挑單個最優節點,更適合放規格相近的節點。
  4. interval 設定過短(例如 10 秒以內),會讓節點探測請求變得頻繁,部分機場或自建節點服務端可能因此限流,建議不低於 120 秒。

三種策略組該怎麼選

如果只能記一句話:優先延遲就用 url-test,優先穩定就用 fallback,優先分攤就用 load-balance。實際使用中,也可以把三者組合起來——例如用 url-test 組作為日常出口,再單獨建一個 fallback 組掛著幾個穩定的直連節點,專門給需要長連線的場景(如下載工具、遠端桌面)通過規則單獨分流過去,兼顧速度與穩定性。策略組類型選定後,再配合規則集把不同網域/應用分流到不同策略組,才是完整的分流邏輯,策略組本身只解決「這一類流量該走哪個/哪些節點」的問題。

下載客戶端