負載均衡與故障轉移實戰

節點再多，不會排程也是白搭：尖峰時段一個個手動換節點，或者半夜掛機時節點掛了沒人管。這篇教你用三種自動化策略組把排程全交給我，目標是——快的時候更快，掛掉的時候無感。

三種自動策略組回顧

類型	排程邏輯	最適合
`url-test`	定時全員測速，永遠走最快的那個	日常瀏覽，追求低延遲
`fallback`	按清單順序檢測，第一個存活的頂上	有明確主備偏好的情境
`load-balance`	把不同連線分攤到多個節點	多執行緒下載、防單節點限速

url-test：加上 tolerance 防抖

預設設定下 url-test 有個惱人的問題：兩個節點延遲接近時會反覆跳動，每次切換都可能中斷正在進行的連線。解法是加 tolerance：

防抖動的 url-test

proxy-groups:
  - name: "自動測速"
    type: url-test
    proxies: [香港 01, 香港 02, 東京 01, 新加坡 01]
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 50   # switch only if 50ms+ faster than current

意思是：新節點必須比目前節點快 50ms 以上才切換。數值按需調整，越大越穩定、越小越激進。

fallback：主備線路的正確姿勢

如果你有一條高品質專屬線路和幾條普通線路，fallback 是最佳選擇——平時永遠走專屬線路，專屬線路故障時自動降級，恢復後自動切回：

主備 fallback

proxy-groups:
  - name: "主備切換"
    type: fallback
    proxies: [香港-專屬線路, 香港-普通 01, 美國-備用]   # priority order
    url: "http://www.gstatic.com/generate_204"
    interval: 120    # check more often for faster failover

注意 proxies 的順序就是優先權順序，檢測間隔建議比 url-test 短一些，故障轉移才夠快。

load-balance：兩種雜湊策略

load-balance 範例

proxy-groups:
  - name: "負載均衡"
    type: load-balance
    proxies: [香港 01, 香港 02, 香港 03]
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    strategy: consistent-hashing   # or: round-robin

consistent-hashing：同一個目標網站固定走同一個節點，登入狀態不會亂，日常推薦。
round-robin：連線輪流分配到各節點，多執行緒下載提速明顯，但部分網站可能因 IP 跳動要求重新登入。

組合拳：巢狀出一個「既快又穩」的體系

策略組可以引用策略組。下面這套三層結構是社群口碑很好的方案：

巢狀組合方案

proxy-groups:
  # Layer 1: user-facing switch
  - name: "節點選擇"
    type: select
    proxies: [智慧排程, 香港專屬線路, 手動選擇]

  # Layer 2: auto scheduling with failover
  - name: "智慧排程"
    type: fallback
    proxies: [低延遲組, 負載均衡組]
    url: "http://www.gstatic.com/generate_204"
    interval: 120

  # Layer 3: workers
  - name: "低延遲組"
    type: url-test
    proxies: [香港 01, 香港 02, 東京 01]
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 50

  - name: "負載均衡組"
    type: load-balance
    proxies: [新加坡 01, 新加坡 02, 美國 01]
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    strategy: consistent-hashing

日常流量走「低延遲組」自動測速；整組不可用時 fallback 自動降級到「負載均衡組」；你想手動接管時，在「節點選擇」裡一鍵切換。三層各司其職。

效能提醒 每個帶 url 的策略組都會定時發出測速請求，組太多、interval 太短會產生可觀的背景流量。一般使用者 3~5 個自動組、300 秒間隔完全夠用。

三種類型到底該怎麼選，一句話版

看完前面的參數細節，如果還是拿不準該選哪種，記住這個簡化判斷法：不在乎走哪個節點、只要最快→ url-test；心裡有明確的主備優先順序→ fallback；想把頻寬壓榨到極限、不介意偶爾重新登入→ load-balance。絕大多數人日常使用只需要一個 url-test 組就夠了，fallback 和 load-balance 更多是「有明確需求」之後才補上的進階玩法，不必一開始就追求設定得多複雜。

排查策略組不生效的幾個方向

設定好之後發現排程好像沒起作用？按這個順序查：

先看 rules 有沒有真的引用這個組：策略組定義了不代表它在用，得有規則（或者最終的 MATCH）指向它才會生效，這是最容易漏掉的一步。
打開控制面板的代理頁確認組內節點狀態：如果組內節點全部逾時或掉線，url-test/load-balance 自然「看起來沒用」，其實是沒有可用節點可選。
檢查 url 測速位址本身是否可達：預設的 generate_204 位址在個別網路環境下可能被擋，導致測速結果全部逾時，可以換成同類的其他檢測位址試試。
fallback 的 interval 是否太長：如果檢測間隔設定成了 600 秒以上，節點故障後要等很久才會被發現並切換，體感上就像「沒生效」。

排程這件事沒有一次到位的標準答案，建議先用最簡單的單層 url-test 跑一段時間，觀察真實使用中的痛點，再針對性地疊加 fallback 或 load-balance，比一開始就搭三層結構更容易維護。

什麼時候值得投入時間做多層巢狀

不是所有人都需要文章前面那套三層結構，投入精力搭建複雜排程之前，先問自己幾個問題：家裡/公司有沒有多條不同品質的線路需要區分主備？是否經常需要多執行緒下載、單節點頻寬明顯吃不滿？是否已經遇過「節點突然掛了卻沒人第一時間發現」的情況？如果這幾個問題的答案大多是「沒有」，那麼一個簡單的 url-test 組完全夠用，沒必要為了「看起來更專業」去堆砌設定。反過來，如果你是替全家或團隊提供網路出口，多層排程帶來的穩定性提升是實打實的，值得花時間打磨。

另外提一句，策略組的名字盡量取得直觀（比如「香港專屬線路」「負載均衡-新加坡」），半年以後你自己再打開設定檔，也能一眼看懂當初為什麼這麼設計，而不是對著一堆 select/fallback/url-test 面面相覷。

小結

三種策略組各司其職：url-test 追求「永遠最快」，適合絕大多數日常情境；fallback 追求「主備分明」，適合有明確線路優先順序的使用者；load-balance 追求「壓榨頻寬」，適合多執行緒下載或防單節點限速的情境。別小看 tolerance 和 interval 這兩個參數，調對了能省去很多莫名其妙的「節點抖動」和「切換太慢」的困擾。先從一個簡單的 url-test 組開始用起來，等真正遇到需求再逐步疊加，比一次性搭出複雜結構更符合大多數人的實際使用節奏。