节点多不等于体验好。真正决定稳定性的，是策略组如何分层、如何切换、如何回滚。很多配置在测速时很漂亮，但一到晚高峰就反复重选，最终表现为会话抖动、登录失效和业务中断。
这篇文章给出一套可落地、可维护的策略组设计方案。你会得到一份结构模板、分工规则、上线流程和故障转移参数建议，目标是把“不可控的快”改成“可预测的稳”。
为什么节点多但体验不稳
当所有流量都压进单层自动组时，系统会频繁在“当前最优节点”之间跳转。这个跳转不是免费的：连接重建、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：先回滚到最近稳定快照，恢复业务后再分析日志，避免在故障期间叠加改动。
总结
好策略组不是“最激进自动化”，而是“自动与手动各司其职”。把关键业务从切换噪声中隔离出来，再用命名规范和快照回滚托底，节点再多也能跑得稳、改得动、查得清。