負載均衡與故障轉移：多節點如何智慧排程

四種策略組類型對比

類型	行為	適合場景
select	手動選擇，只用你點的那個節點	習慣固定使用某個節點
url-test	定期測速，自動切到延遲最低的節點	希望始終使用當前最快的線路
fallback	按清單順序使用第一個可用節點，目前節點故障才切下一個	有明確的主 / 備節點優先級
load-balance	按策略把請求分散到多個節點，分攤連接壓力	節點數量充足，希望分攤頻寬壓力

左右滑動檢視完整表格

url-test：自動追著低延遲走

url-test 會按設定的間隔對組內所有節點發起一次測速請求，並自動切換到延遲最低的一個，不需要你手動點測速按鈕。

url 是測速時請求的目標位址，通常用一個回應很輕的位址；interval 是測速間隔（秒），太頻繁會增加不必要的請求，一般設定成幾分鐘一次即可。

fallback：主備節點的故障轉移

fallback 按你寫入 proxies 清單的順序，優先使用排在前面的節點；一旦目前使用的節點測速失敗（不可用），會自動切換到清單中下一個可用的節點，直到主節點恢復。適合你明確知道「哪個節點線路更好，哪個是備用」的場景。

load-balance：把壓力分攤出去

load-balance 不追求「選出最好的那一個」，而是把不同的請求分散到多個節點上，常見的分配策略有按連接的一致性雜湊（同一個目標始終走同一節點，避免會話中斷）和輪詢。適合你有多個節點、且都還算穩定，希望分攤頻寬和連接數壓力的情況。

常見調優建議

把策略組用起來之後，還有幾個細節值得留意，能讓自動排程的效果更貼近預期：

• 測速位址選輕量目標：url 欄位建議使用回應體很小、幾乎不占頻寬的位址（例如回傳 204 狀態碼的健康檢查介面），避免測速本身消耗過多流量。
• 合理設定 interval：間隔太短會讓節點被過於頻繁的測速請求打擾，太長又會導致故障發現不及時，幾分鐘一次是比較常見的折中方案。
• tolerance 容差：部分實作支援設定一個容差值，只有新節點的延遲比目前節點低出這個差值才會觸發切換，避免延遲在閾值附近抖動時反覆切換節點。
• 組內節點數量：load-balance 組內節點太少時分攤效果不明顯，節點數量充足才能真正體現出「分攤壓力」的價值。

常見問題

為什麼 url-test 組裡的節點一直在跳來跳去？

這通常是幾個節點的延遲非常接近，每次測速的微小波動都足以改變「最低延遲」的排名。適當調大 interval，或者使用帶 tolerance 容差的設定，能有效減少這種頻繁切換。

fallback 組裡的節點全部顯示不可用怎麼辦？

先確認測速位址本身是否可以正常存取——如果測速目標位址被防火牆攔截，所有節點都會被誤判為不可用。也可以嘗試更換一個更穩定、造訪量更小的測速位址。

能不能把 select、url-test、load-balance 組合起來用？

完全可以，而且這是比較推薦的做法：按地區把節點分成幾個 url-test 子分組（比如「香港自動選擇」「日本自動選擇」），再用一個最外層的 select 分組手動選擇地區，既保留了手動控制的靈活性，也享受到了組內自動優選的便利。

小結

如果只有一兩個節點，select 手動切換已經夠用；節點數量上來以後，url-test 能省去手動測速切換的麻煩，fallback 適合有明確主備關係的場景，load-balance 則更適合把壓力分攤到一批品質相近的節點上。