負載平衡與容錯移轉：讓多個節點撐起穩定連線
只用一個節點，遲早會遇到它限速、抽風甚至掉線的時候。fallback 和 load-balance 這兩種代理群組類型，就是為了讓「某個節點出問題」不再等於「整個網路出問題」。這篇講清楚它們各自的判斷機制、設定寫法，以及怎麼把多種策略分層組合成一套真正穩定耐用的設定。
為什麼單節點扛不住
節點不是恆定不變的：「服務商臨時維護」「上游線路波動」「同時在線人數太多導致限速」，這些情況即便節點本身沒有下線，也會讓實際體驗明顯變差。
如果代理群組用的是 select 手動模式，節點出問題時你只能自己發現、手動切換，中間這段時間的所有連線都會跟著卡頓甚至逾時。fallback 和 load-balance 分別從「故障時切換」和「壓力分攤」兩個角度解決這個問題，兩者可以同時使用，涵蓋不同情境。
fallback 容錯移轉的判斷機制
fallback 群組會按你設定的節點順序，持續對排在前面的節點做健康檢查，一旦目前使用的節點被判定為「不健康」，才會切換到順序裡的下一個：
proxy-groups:
- name: 容錯移轉
type: fallback
proxies: [主線路, 備用線路A, 備用線路B]
url: "https://www.gstatic.com/generate_204"
interval: 300
max-failed-times: 3幾個關鍵欄位：
url：健康檢查請求的目標位址，通常用一個體積極小、全球可達性好的測試端點，避免檢查本身占用太多流量或因為該網址被限制而誤判interval：健康檢查的週期（秒），太短會增加不必要的探測流量，太長又會導致故障復原不及時，300 秒是比較常見的折衷值max-failed-times：連續失敗多少次才判定為「不健康」，避免一次偶發逾時就誤切換
fallback 只在「目前節點不健康」時才會切換，即便備用節點延遲更低，只要主節點健康檢查正常，也不會主動切過去——這是它和 url-test 最大的行為差異，適合你想固定一個「主力線路」、其他節點僅作為應急備援的情境。
load-balance 的兩種分攤策略
load-balance 不是「擇優使用」，而是把不同的連線主動分散到群組內多個節點上，透過 strategy 欄位決定具體怎麼分：
consistent-hashing 一致性雜湊
- 根據連線的來源位址計算雜湊值，同一個來源大機率固定分到同一個節點
- 對需要「連線保持」的情境更友善，比如某些網站/遊戲對連線跳變敏感
- 某個節點被移除時，只有對應到它的一小部分連線受影響，不會全域重新分配
round-robin 輪詢
- 新連線依次輪流分配給群組內節點，分攤更均勻
- 不保證同一個來源始終落在同一個節點，可能出現「連線跳變」
- 更適合大量短連線、彼此獨立、對連線保持沒有要求的情境
proxy-groups:
- name: 負載平衡
type: load-balance
strategy: consistent-hashing
proxies: [節點A, 節點B, 節點C]
url: "https://www.gstatic.com/generate_204"
interval: 300沒有特殊需求的話，consistent-hashing 通常是更穩妥的預設選擇，因為它對連線穩定性的影響更小。
實戰：分層組合出一套穩定設定
三種策略並不互斥，實際設定裡常見的做法是分層巢狀——外層用 select 給自己留一個手動總開關，中間層用 url-test 或 load-balance 做自動排程，再讓 fallback 兜底應對極端情況：
proxy-groups:
- name: PROXY
type: select
proxies: [智慧排程, 手動指定]
- name: 智慧排程
type: fallback
proxies: [高速分組, 備用線路]
url: "https://www.gstatic.com/generate_204"
interval: 300
- name: 高速分組
type: load-balance
strategy: consistent-hashing
proxies: [節點A, 節點B, 節點C]
url: "https://www.gstatic.com/generate_204"
interval: 300這樣一套設定的效果是：日常情況下「高速分組」把連線分攤到三個節點上，一旦這一層整體出現異常（比如所在機房故障），最外層的 fallback 會自動切到「備用線路」，而你在 PROXY 這一層始終保留手動介入的能力。
常見迷思
- 把健康檢查位址設成造訪頻率很低的普通網站：這類位址回應時間波動大，容易把「正常節點」誤判為「不健康」，務必用輕量、穩定的測試端點。
- load-balance 裡混用速度差異很大的節點：輪詢/雜湊分配不會考慮節點速度，混用會導致部分連線體驗忽好忽壞，盡量讓同一個負載平衡群組內的節點線路品質相近。
- interval 設定過短：頻繁的健康檢查本身也會消耗節點資源和你的流量，多數情境下不需要低於 300 秒。
如果設定之後發現切換行為和預期不一致，可以對照進階手冊的代理群組章節重新核對各欄位含義，或打開 Dashboard 面板直接觀察每個代理群組目前的健康狀態。