策略組進階：負載均衡與故障轉移怎麼配置

先回顧一下三種基礎策略組

url-test（自動選擇）會定期測速，始終使用目前延遲最低的節點；select（手動切換）完全由使用者指定；這兩種是最常見的預設配置。當節點數量變多、使用場景變複雜之後，load-balance 和 fallback 這兩種型別能解決更具體的問題。

load-balance：把流量分攤到多個節點

load-balance 組會把不同的連線請求分配給組內的多個節點，而不是像 url-test 那樣始終只用「最優」的那一個。這樣做的好處是可以分攤單個節點的頻寬壓力，尤其是在多裝置同時使用同一份訂閱、流量較大的場景下比較有意義。它有兩種分流策略，透過 strategy 欄位指定：

proxy-groups:
  - name: 負載均衡
    type: load-balance
    strategy: consistent-hashing
    proxies: [節點A, 節點B, 節點C]
    url: http://www.gstatic.com/generate_204
    interval: 300

• consistent-hashing —— 按目標位址做一致性雜湊，同一個目標始終分配到同一個節點，適合需要「連線狀態保持」的場景（例如某些網站會因為來源 IP 頻繁變化而觸發異常驗證）；
• round-robin —— 按請求順序依序輪詢組內節點，分攤更均勻，但同一個目標位址不保證每次都走同一個節點。

不確定選哪個的話，優先用 consistent-hashing，多數場景下體驗更穩定。

fallback：主節點掛了自動補位

fallback 組會按配置順序依序檢查節點是否可用，正常情況下始終使用清單裡第一個可用節點；一旦目前使用的節點測速失敗（判定為不可用），立即自動切到下一個可用節點，等主節點恢復後再切回去。這和 url-test「誰延遲低就用誰」不同，fallback 更強調「優先用首選節點，不行了才退而求其次」：

proxy-groups:
  - name: 故障轉移
    type: fallback
    proxies: [主節點, 備用節點A, 備用節點B]
    url: http://www.gstatic.com/generate_204
    interval: 300

組合起來用

實際配置中，這幾種策略組型別經常是巢狀使用的——例如先用 url-test 從同一地區的多個節點裡選出延遲最低的，再把幾個不同地區的 url-test 組當作整體，用 select 手動選擇目前使用哪個地區；需要分攤頻寬的場景則可以把一組節點單獨設為 load-balance，再和其他策略組並列放進最終的手動選擇選單裡，按需切換。

別忽略 tolerance，它能減少無意義的切換

url-test 和 load-balance 組還有一個經常被忽略的參數——tolerance（延遲容差，單位毫秒）。如果不設定，用戶端會嚴格按「誰延遲最低就用誰」的邏輯執行，而測速結果本身存在天然的抖動，兩次測速之間差個幾毫秒很常見，如果沒有容差緩衝，會導致節點在幾個延遲相近的候選之間頻繁來回切換，反而影響使用體驗（尤其是正在進行的下載或影片會因為切換瞬間產生短暫卡頓）。

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

設定 tolerance: 50 之後，只有新節點的延遲比目前節點低了至少 50 毫秒，用戶端才會真正觸發切換，否則會繼續沿用目前節點，即便測出來的瞬時延遲略高一點。這個值不需要設得很大，通常 50～100 毫秒就能過濾掉大部分無意義的抖動切換。

該用哪一種，看你的實際問題

回到最開始的問題：如果只是延遲切換太頻繁，先加 tolerance 就能解決，不一定要換成更複雜的策略組型別；如果是希望把多裝置的流量分攤到不同節點、降低單節點壓力，才需要用 load-balance；如果關心的是「主節點掛了能不能自動補位」，答案是 fallback。三個問題、三種方案，不需要一次性全部用上，按實際遇到的情況對症配置即可。想了解更多策略組參數，可以查看進階配置文件。