策略組(proxy-groups)是 Clash 代理架構的核心排程層,負責決定流量最終經由哪個節點輸出。合理的策略組設計能在速度、穩定性與靈活性之間取得最優平衡。本文為 Clash 官方策略組使用指南,透過完整設定範例詳細說明四種策略組類型的適用場景與官方推薦設定方法。
select:手動選擇
select 類型是最基礎的策略組,使用者在圖形介面中手動點擊切換目前使用的節點或子策略組。它的 proxies 清單中可以混合放置具體的代理節點名稱和其他策略組的名稱,這一特性使得策略組之間的巢狀組合成為可能。
proxy-groups:
- name: "🚀 節點選擇"
type: select
proxies:
- "♻️ 自動選擇" # 引用另一個策略組
- "🇭🇰 香港節點"
- "🇺🇸 美國節點"
- DIRECT # 內建直連策略
select 策略組通常作為頂層入口,讓使用者可以隨時手動切換到不同的節點或自動策略,而無需修改設定檔。
url-test:自動選速
url-test 類型會週期性地向 url 欄位指定的位址發送 HTTP 請求,測量每個節點的延遲,並自動將流量切換到延遲最低的節點。
- name: "♻️ 自動選擇"
type: url-test
url: http://www.gstatic.com/generate_204
interval: 300 # 測速間隔,單位秒
tolerance: 50 # 容差:只有新最優節點比當前節點快 50ms 以上才切換
lazy: true # 懶測速:只在有流量時才測速,節省資源
proxies:
- "🇭🇰 香港-01"
- "🇭🇰 香港-02"
- "🇭🇰 香港-03"
tolerance(容差)參數非常重要。如果不設定容差,當多個節點延遲接近時,url-test 會因為微小的延遲波動而頻繁切換節點,造成連線中斷。設定 50ms 的容差後,只有當新發現的最優節點比當前節點快 50ms 以上時才會切換,大幅提升了穩定性。
fallback:故障轉移
fallback 類型同樣會週期性測速,但其行為邏輯與 url-test 不同:它始終優先使用清單中第一個可用(測速成功)的節點,只有當前節點不可用(測速失敗或逾時)時才切換到下一個。
- name: "🛡️ 故障轉移"
type: fallback
url: http://www.gstatic.com/generate_204
interval: 180
proxies:
- "🇭🇰 香港-01" # 主節點,優先使用
- "🇯🇵 日本-01" # 備用節點一
- "🇸🇬 新加坡-01" # 備用節點二
fallback 非常適合對穩定性要求高的場景,例如視訊通話、線上直播等不能中斷的連線。主節點出現故障時,fallback 會在下次測速後(預設 180 秒內)自動切換到備用節點,等主節點恢復後再切回來。
load-balance:負載均衡
load-balance 類型將新建立的連線均勻分配到 proxies 清單中的多個節點上,充分利用每個節點的頻寬,適合需要同時建立大量連線的場景(如多執行緒下載、批次 API 請求)。
- name: "⚖️ 負載均衡"
type: load-balance
url: http://www.gstatic.com/generate_204
interval: 300
strategy: consistent-hashing # 同一域名的連線固定分配到同一節點
proxies:
- "🇭🇰 香港-01"
- "🇭🇰 香港-02"
- "🇭🇰 香港-03"
strategy 參數控制分配演算法,consistent-hashing(一致性雜湊)模式會將同一目標域名的所有連線固定分配到同一節點,避免某些對 IP 一致性有要求的網站(如登入狀態驗證)出現異常;round-robin 模式則完全輪詢,適合無狀態的批次請求場景。
策略組架構設計建議
一個合理的策略組架構通常採用分層設計:頂層是一個 select 策略組作為使用者手動控制的總入口;中層是按地區或用途劃分的 url-test 自動選速組;底層是具體的代理節點。分流規則指向頂層策略組,使用者可以隨時在頂層策略組中切換使用自動選速還是指定節點。
對於串流服務解鎖場景,建議單獨建立一個「串流服務」策略組,專門放置支援解鎖 Netflix、Disney+ 等平台的節點,並在規則中將相關域名指向該策略組,避免頻繁在主節點和解鎖節點之間切換。這樣既不影響日常使用體驗,在需要觀看串流時切換到對應策略組即可。