策略组(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 分组,测速与容灾逻辑都封装在它的候选列表里,这样调整策略组内部逻辑时,完全不需要改动任何规则。