節點多了以後，手動切換是最累人的事情。Clash 提供的三種自動化策略組——url-test、fallback、load-balance——各自解決不同的問題，搭配好可以讓節點故障、延遲波動都變得「無感」。
三種自動化策略組速覽
| 類型 | 選節點邏輯 | 適合場景 |
|---|---|---|
| url-test | 定時測速，始終使用延遲最低的節點 | 追求最佳速度，允許偶爾切換 |
| fallback | 按順序使用，目前節點失效才切下一個 | 有明確的「主備」優先度需求 |
| load-balance | 按演算法把不同請求分散到多個節點 | 多節點分攤壓力，避免單節點過載 |
url-test：自動挑最快的節點
這是最常用的策略組類型，Clash 會定時對組內所有節點發起測速請求，並始終選用延遲最低的一個。
tolerance（容差值，單位毫秒）避免了因為幾毫秒的測速抖動就頻繁切換節點：只有新節點的延遲比目前節點低於「目前延遲 − tolerance」時才會真正切換。
fallback：明確的主備順序
如果你有一個「主力節點」，只有它失效時才希望切換到備用節點，fallback 更合適：它按 proxies 清單的順序檢測，始終優先使用清單靠前且可用的節點。
load-balance：把壓力分攤出去
當有多個節點品質相近、希望把連線壓力均攤時，可以用 load-balance，它支援兩種分配演算法：
- consistent-hashing：相同的目標位址會穩定落在同一節點，適合需要會話保持的場景。
- round-robin：按順序輪流分配連線，分布更均勻，但同一目標位址可能落在不同節點上。
健康檢查參數怎麼調
url、interval、tolerance 這幾個欄位共同決定了策略組「多久檢測一次」以及「多大差距才切換」，調得太激進或太保守都會帶來問題。
| 欄位 | 作用 | 調整建議 |
|---|---|---|
| url | 測速請求打到的目標位址 | 用輕量、穩定的探測位址，避免用大檔案或經常波動的網站 |
| interval | 兩次測速之間的間隔（秒） | 調太短會增加節點端負擔，一般 300 秒左右比較均衡 |
| tolerance | 切換所需的最小延遲差（毫秒） | 網路本身抖動大時適當調高，避免因幾毫秒差異頻繁切換 |
tolerance 設定過小，而不是急著懷疑節點品質問題。
策略組可以巢狀嗎
可以。策略組的 proxies 欄位既可以填具體節點名稱，也可以填另一個策略組的名稱，這意味著你可以搭建出「先按地區分組自動測速，再手動選擇用哪個地區」這樣的層級結構。但巢狀層級不建議太深——每多一層巢狀，實際生效的判斷邏輯就多一層，遇到問題時排查起來也會更麻煩，一般兩到三層足夠涵蓋大多數使用場景。
實戰：多地區節點池怎麼搭
一個常見的多層結構是：先按地區建立多個 url-test 子策略組（如「香港自動」「新加坡自動」），再用一個 select 手動策略組，讓最終選擇權交給自己，兼顧自動化與靈活性。
不同規則命中不同策略組
策略組的真正威力要結合 rules 才能發揮出來：不同類型的流量完全可以分別路由到不同的策略組，而不是所有流量都塞進同一個「大雜燴」策略組裡。比如串流媒體類網域可以單獨路由到一個只包含解鎖串流效果好的節點的策略組，遊戲類網域路由到低延遲優先的 url-test 組，其餘流量走通用的自動選擇組。這樣各類流量都能對應到最適合的選節點邏輯，而不是用同一套標準應付所有場景。
怎麼判斷該不該拆分策略組
不是所有場景都需要拆分得很細。判斷標準很簡單：如果某一類流量對「節點選擇邏輯」有明顯不同的偏好（比如遊戲對延遲極度敏感、串流媒體對解鎖地區有硬性要求），就值得單獨拆一個策略組；如果只是普通網頁瀏覽，用一個通用的自動選擇組完全夠用，沒必要為了「看起來更專業」而過度拆分，那樣反而會增加後期維護和排查問題的複雜度。
切換節點後為什麼原連線不受影響
手動或自動切換策略組裡的節點後，你可能會發現已經建立的連線（比如正在下載的檔案、播放中的影片）並不會立刻切換到新節點，而是等這個連線自然結束後，下一次新建連線才會走新節點。這是符合預期的設計：代理層面的節點切換作用於「新建連線」，不會中斷已經建立好的連線，這樣可以避免頻繁切換節點導致正在進行的下載或通話被打斷。如果確實需要讓所有連線立刻切換，可以在面板的 Connections 裡手動關閉舊連線，讓程式重新發起新的請求。
小結
沒有哪種策略組是「萬能」的：追求速度用 url-test，需要明確主備順序用 fallback，想分攤壓力用 load-balance。實際使用中把它們巢狀組合，再用一個手動 select 組兜底，往往是兼顧自動化與可控性的最佳做法。