節點多不等於體驗好。真正決定穩定性的，是策略組如何分層、如何切換、如何回退。很多配置在測速時很漂亮，但一到晚高峰就反覆重選，最終表現為會話抖動、登入失效和業務中斷。
這篇文章給出一套可落地、可維護的策略組設計方案。你會得到一份結構模板、分工規則、上線流程和故障轉移參數建議，目標是把「不可控的快」改成「可預測的穩」。
為什麼節點多但體驗不穩
當所有流量都壓進單層自動組時，系統會頻繁在「當前最優節點」之間跳轉。這個跳轉不是免費的：連線重建、TLS 重協商、會話遷移都會帶來瞬時損耗，長連線業務最容易受影響。
設計策略組時，先思考「哪些流量可以被打斷」，再決定自動化邊界。把高容錯業務放自動層，把低容錯業務放手動層，才是長期可用的結構。
診斷清單
- 10 分鐘內連續兩次斷線或重連。
- 測速正常但網頁首包明顯變慢。
- 日誌出現連續策略切換記錄。
- SSH、會議、遠端桌面比瀏覽網頁更容易卡頓。
- 改為固定節點後問題明顯緩解。
三層策略組結構
推薦結構是：入口層（總開關）→ 區域層（自動收斂）→ 節點層（執行連線）。入口層保證可控，區域層負責彈性，節點層保持清晰。這樣能同時得到速度和穩定性。
YAML 模板
proxy-groups:
- name: "G-ENTRY"
type: select
proxies: ["G-AUTO", "G-MANUAL", "G-FAILOVER", DIRECT]
- name: "G-AUTO"
type: url-test
url: "http://www.gstatic.com/generate_204"
interval: 300
tolerance: 80
proxies: ["R-HK-AUTO", "R-SG-AUTO", "R-JP-AUTO"]
- name: "G-MANUAL"
type: select
proxies: ["R-HK-MANUAL", "R-SG-MANUAL", "R-JP-MANUAL"]
- name: "R-HK-AUTO"
type: url-test
url: "http://cp.cloudflare.com/generate_204"
interval: 240
tolerance: 100
proxies: ["HK-01", "HK-02", "HK-03"]
- name: "R-HK-MANUAL"
type: select
proxies: ["HK-01", "HK-02", "HK-03"]| 結構 | 優勢 | 問題 | 適用 |
|---|---|---|---|
| 單層 | 配置最簡單 | 切換噪聲大、難排障 | 臨時測試 |
| 雙層 | 有一定分組能力 | 入口職責仍混亂 | 輕度個人使用 |
| 三層 | 可控、可觀測、可回退 | 初期搭建稍複雜 | 長期穩定運行 |
入口層專注決策，區域層專注品質，節點層專注可達。分層後每次變更都能限定影響範圍，避免全域連鎖抖動。
三層結構的實際好處
- 關鍵業務可以綁定手動穩定組。
- 普通流量繼續享受自動優化。
- 故障只影響局部層級，不會全域擴散。
- 日誌與排障路徑更可讀，團隊協作成本更低。
自動與手動如何分工
分工原則很簡單：可重試業務優先自動，低容錯業務優先手動。不要把「自動最優」誤當成「全量自動」。
| 業務類型 | 推薦策略 | 說明 |
|---|---|---|
| 網頁瀏覽 / 社群媒體 | G-AUTO | 高容錯，適合自動切換 |
| 串流媒體 | 區域自動 + 人工兜底 | 地區穩定性優先 |
| 支付 / 企業後台 | G-MANUAL | 避免切換導致登入態失效 |
| 會議 / SSH | 固定手動組 | 長連線對抖動最敏感 |
| 下載更新 | G-FAILOVER | 優先可用性 |
把低容錯業務放在自動組，等於把會話穩定性交給網路波動。建議關鍵網域先固定到手動組，再逐步放權給自動層。
規則示例
rules:
- DOMAIN-SUFFIX,corp-admin.com,G-MANUAL
- DOMAIN-SUFFIX,pay.example.com,G-MANUAL
- DOMAIN-SUFFIX,zoom.us,G-MANUAL
- DOMAIN-SUFFIX,netflix.com,R-SG-AUTO
- DOMAIN-SUFFIX,youtube.com,R-HK-AUTO
- GEOIP,CN,DIRECT
- MATCH,G-ENTRY故障轉移設計要點
故障轉移的目標不是「永不切換」，而是「發生切換時影響最小、恢復路徑明確」。參數設計要避免過度靈敏。
fallback 配置示例
proxy-groups:
- name: "G-FAILOVER"
type: fallback
url: "http://www.gstatic.com/generate_204"
interval: 180
lazy: true
proxies: ["R-HK-MANUAL", "R-SG-MANUAL", "R-JP-MANUAL"]
- name: "B-WORK"
type: select
proxies: ["G-MANUAL", "G-FAILOVER", DIRECT]
rules:
- DOMAIN-SUFFIX,corp.example.com,B-WORK
- DOMAIN-SUFFIX,git.example.com,B-WORK
- MATCH,G-ENTRYinterval 推薦 120-300 秒；探測 URL 選輕量且穩定地址；跨洲線路建議適當放寬容忍閾值，減少誤切換。
10-30 秒級別探測通常會引入噪聲，系統會被「探測波動」而非「真實故障」驅動，最終出現反覆橫跳。
可維護的命名規範
策略越複雜，命名越關鍵。命名混亂會導致「能跑但沒人敢改」。建議使用固定前綴，做到名稱即用途。
命名約定表
| 前綴 | 用途 | 示例 |
|---|---|---|
| G- | 全域入口組 | G-ENTRY / G-AUTO / G-MANUAL |
| R- | 區域組 | R-HK-AUTO / R-SG-MANUAL |
| B- | 業務組 | B-WORK / B-STREAM |
| F- | 兜底組 | F-BACKUP / F-EMERGENCY |
統一命名後，值班同事可以直接從日誌定位責任層級，新成員也能快速理解配置結構，減少「改動恐懼」。
命名實戰示例
proxy-groups:
- name: "G-ENTRY"
type: select
proxies: ["G-AUTO", "G-MANUAL", "F-BACKUP", DIRECT]
- name: "B-STREAM"
type: select
proxies: ["R-SG-AUTO", "R-HK-AUTO", "R-JP-AUTO", "F-BACKUP"]
- name: "B-WORK"
type: select
proxies: ["G-MANUAL", "F-BACKUP", DIRECT]
rules:
- DOMAIN-SUFFIX,zoom.us,B-WORK
- DOMAIN-SUFFIX,openai.com,B-STREAM
- MATCH,G-ENTRY上線與回退建議
策略組重構是高影響變更。上線要分階段，回退要可一鍵恢復，避免在生產高峰時做「大爆改」。
上線步驟
- 匯出當前穩定配置，儲存為
stable-snapshot。 - 在測試裝置啟用新策略，觀察 24 小時。
- 優先遷移普通流量，關鍵業務最後遷移。
- 追蹤會話中斷率、切換頻率、關鍵業務成功率。
- 確認穩定後全量發佈，並保留回退窗口。
只回退 rules 不回退 proxy-groups，會導致組名引用失配。回退必須使用完整快照，保證規則與策略組定義同步恢復。
保留三類快照：長期基線、變更前快照、故障現場快照。這樣能快速定位問題來源並減少恢復時間。
常見問題 FAQ
Q1：節點只有十幾個，仍然要三層嗎？
A：要。三層的價值是職責分離，不是節點規模。小規模同樣需要穩定入口和明確回退路徑。
Q2：url-test 和 fallback 怎麼搭配？
A：一般是區域層用 url-test，關鍵業務兜底用 fallback，入口層用 select 做人工覆蓋。
Q3：自動組讓速度變慢，為什麼？
A：通常是檢查頻率太高或閾值太敏感，觸發過度切換。先放寬參數再看 24 小時趨勢。
Q4：手動組是不是更落後？
A：不是。手動組用於保障關鍵業務穩定，自動組用於追求普通流量效率，兩者是協同關係。
Q5：如何判斷命名規範是否合格？
A：如果新同事不看文件也能根據組名判斷用途與影響範圍，說明命名是合格的。
Q6：上線後異常，第一步做什麼？
A：先回退到最近穩定快照，恢復業務後再分析日誌，避免在故障期間疊加改動。
總結
好策略組不是「最激進自動化」，而是「自動與手動各司其職」。把關鍵業務從切換噪聲中隔離出來，再用命名規範和快照回退托底，節點再多也能跑得穩、改得動、查得清。