策略群組(Proxy Group)決定了一條規則命中後,具體走哪個節點。很多人設定訂閱後從來沒碰過策略群組,一直用機場給的預設分組,其實預設設定往往只是「能用」,距離「好用」還有不少調整空間。
三種類型分別解決什麼問題
| 類型 | 解決的問題 | 代價 |
|---|---|---|
| select | 讓你手動固定使用某個節點,行為完全可預期 | 節點故障時不會自動切換,需要手動處理 |
| url-test | 自動選延遲最低的節點,免去手動測速切換 | 測速本身消耗一點流量與時間,參數不當會頻繁切換 |
| fallback | 主節點故障時按順序自動切到下一個可用節點 | 「可用」只代表連通,不代表延遲最低 |
| load-balance | 把連線分攤到多個節點,單節點頻寬壓力更小 | 同一時間的不同連線可能走不同節點,不適合需要「IP 一致」的情境 |
url-test:自動測速的兩個關鍵參數
url-test 是最常用的類型,但很多人只設定了 proxies 清單就不管了,其實 interval 和 tolerance 這兩個參數才是決定體驗好壞的關鍵。
proxy-groups: - name: Auto type: url-test proxies: [HK-01, HK-02, SG-01, JP-01] url: http://www.gstatic.com/generate_204 interval: 300 # 每 300 秒測速一次,太頻繁會增加流量消耗 tolerance: 50 # 延遲差小於 50ms 時不切換,避免抖動導致頻繁跳節點 lazy: true # 沒有實際流量時暫停測速,省電省流量
tolerance 是最容易被忽略但影響最大的參數。如果設成 0,只要兩個節點延遲差 1ms 就會觸發切換,長期使用會感覺「莫名其妙一直在跳節點」;設到 50~100ms 是比較均衡的取值,能過濾掉正常的網路抖動,只在延遲差距真正明顯時才切換。
fallback:給主力線路配一條備援
如果你有一條延遲很低但偶爾抽風的「主力節點」,與其手動盯著它斷線再切換,不如用 fallback 包一層:正常情況下始終用第一優先級的節點,一旦偵測到不可用,自動順移到下一個。
proxy-groups: - name: Fallback type: fallback proxies: [HK-Premium, Auto, SG-01] url: http://www.gstatic.com/generate_204 interval: 180
這裡的順序很重要:HK-Premium 是主力節點,排第一;Auto 是前面設定的 url-test 分組,作為「更聰明的備援」;SG-01 是最後的保底。fallback 會按順序依次偵測,只有前一個不可用才會用後一個,平時幾乎感知不到它的存在,只有在主力節點真的出問題時才會體現價值。
load-balance:什麼時候真的需要它
load-balance 常被誤解為「能加速」,其實它解決的是「單節點頻寬不夠用」或者「希望連線分攤到多個出口」的問題,對單個下載任務的速度提升有限——因為一個 TCP 連線始終只走一個節點,只有多個並發連線時才會體現分攤效果。
- 如果你的情境是「看影片、日常瀏覽」,大概率用不上 load-balance,url-test 已經夠用。
- 如果你有多個客戶端裝置共用同一套節點,或者經常有多個並發下載任務,load-balance 能讓壓力分攤得更均勻。
- load-balance 支援 round-robin(輪詢)和 consistent-hashing(一致性雜湊,同一目標位址盡量走同一節點)兩種策略,後者更適合需要「同一網站保持同一出口 IP」的情境。
組合起來:一套實用的三層結構
實際設定中,更推薦把三種類型疊起來用,而不是只選一種:
- 最底層用 url-test 分組把同地區節點收攏起來,自動選最快的。
- 中間用 fallback 包一層,把「主力節點」與「url-test 分組」按優先級排好,保證故障時能自動兜底。
- 最外層用一個 select 分組暴露給規則使用,候選清單裡放 fallback 分組、以及幾個手動可選的備用節點,方便你隨時手動介入。
規則永遠只引用最外層的 select 分組,測速與容災邏輯都封裝在它的候選清單裡,這樣調整策略群組內部邏輯時,完全不需要改動任何規則。