select、url-test、fallback、load-balance 到底该用哪个

一句话结论：不确定就用 select（手动选）。 其余三种都会自动切换节点，而自动切换的前提是你能接受「它替你决定」——大多数人的困扰其实来自没搞清它们各自是怎么决定的。

四种类型的实际行为

url-test 和 fallback 的区别是关键

这两个最容易混，因为都会「测速」，但选节点的逻辑完全相反。

url-test 看的是快慢。 它测所有节点的延迟，谁最低用谁。你列表的顺序无所谓——写在最后的节点只要够快就会被选中。

fallback 看的是顺序。 它按你写的顺序，用第一个能连通的。只要第一个还活着，哪怕它延迟 500ms、后面有个 30ms 的，它也不换。

所以：想要「自动挑最快的」用 url-test；想要「优先走某条线，那条挂了才退」用 fallback。把 fallback 当成 url-test 用，会疑惑「为什么它不选最快的」——它本来就不看快慢。

两个高频误解

load-balance 不会让下载变快

它分摊的是连接，不是带宽。一个大文件下载通常只建立一条连接，那条连接只走一个节点，速度和单节点一样。它真正有用的场景是同时有大量并发连接（比如网页里几十个资源同时加载，或者多个应用一起用）。

指望它把两条 50M 的线路合成 100M 是不可能的——那需要多路径传输，不是负载均衡能做的。

它还有个副作用：round-robin 策略下，同一个网站的请求会来自不同 IP，容易触发风控（表现为频繁要求验证码、或者登录态丢失）。如果要用，优先选 consistent-hashing，它保证同一个目标域名总是走同一个节点。

url-test 不设 tolerance 会反复横跳

tolerance 是容差，单位毫秒，意思是「只有当另一个节点比当前快出这么多时才切换」。

不设的话默认是 0，那么只要测出来快 1 毫秒就切。而网络延迟本身是抖动的，两个延迟接近的节点会测出来一会儿你快一会儿我快，结果就是每轮测速都在切换。表现是连接频繁中断、视频卡顿、下载断流。

设成 50–150 毫秒能解决绝大多数横跳。

还有两个字段值得设对

lazy: true —— 只在这个策略组正在被使用时才测速。不开的话，即便你根本没选这个组，客户端也会按 interval 一直在后台测。配置里如果有五六个 url-test 组都不开 lazy，测速流量会很可观，节点侧也会看到大量无谓连接。

interval —— 测速间隔，常见 300 秒。太短徒增流量，太长则节点挂了不能及时发现。

策略组可以套策略组

proxies 列表里除了节点名，还能填另一个策略组的名字。常见的组织方式是分两层：

proxy-groups:
  - name: 节点选择        # 上层：手动选走哪一类
    type: select
    proxies: [自动选择, 香港自动, DIRECT]
  - name: 自动选择        # 下层：在全部节点里自动挑最快
    type: url-test
    proxies: [香港01, 日本01, 新加坡01]
  - name: 香港自动        # 下层：只在香港节点里挑
    type: url-test
    proxies: [香港01, 香港02]

这样你在界面上只需要在「节点选择」里点，具体走哪个由下层自动决定。

注意别让策略组互相引用成环（A 引用 B、B 又引用 A），那会导致运行异常。

生成和检查

不想手写的话，策略组生成器可以按类型生成 YAML，并逐字段解释每个参数在做什么——包括上面说的 tolerance 和 lazy。

写完之后建议用配置校验器过一遍，它会检查策略组引用的节点名是否真实存在（改订阅之后这是最常见的失效原因），以及有没有空策略组。

两个工具都在你的浏览器里运行，配置不会上传。

小结

• 不确定就 select，自动切换的前提是你接受它替你决定
• url-test 看快慢，fallback 看顺序——这是两者的根本区别
• load-balance 分摊连接不分摊带宽，别指望它加速下载
• tolerance 必设，否则节点反复横跳；lazy 建议开