手里有两三台 VPS？用 sing-box urltest 做自动选优，单节点挂了也不断网

这是什么：给出口加一个“自动选路层”

sing-box 是一个通用的代理平台，一份配置文件里有三个核心部分：入口（inbound，本地程序连进来）、出口（outbound，流量从哪台服务器出去）、路由（route，哪些流量走哪个出口）。平时一个出口对应一台服务器：这台服务器挂了、线路抽风，你的流量就跟着断，只能手动换节点。

urltest 是一种特殊的出口：它自己不直接连外网，而是定期对组里的每个节点测一次延迟，自动把新连接交给当前最快、而且健康的那个节点。节点挂了，下一轮测速失败，它就被排除在候选之外；节点恢复了，测速通过，它又能重新入选。

这篇适合手头有两三台不同商家、不同机房 VPS 的人。如果你只有一个节点，urltest 没有意义；如果所有节点都在同一商家、同一机房，商家整体出问题时会一起挂，选优也救不了——多样性比组本身更重要。

先想清楚：urltest 和手动切换有什么不同

方式	怎么做	适合什么时候
selector（手动选择）	在客户端里手动点选节点	想固定用某个节点、对比测试时
urltest（自动选优）	按实测延迟自动选最快健康节点	日常使用，不想盯着延迟手动换

还有一个必须先讲清的限制：切换只影响新建连接。已经建立的长连接（比如正在下载的文件、正在进行的视频通话）不会中途迁移到新节点，故障瞬间正在传的数据仍可能中断，之后要靠应用自己重连。所以 urltest 的承诺是“新连接不断网”，不是“所有连接全程无缝”。

配置：一个 urltest 组加两条真实出口

下面是一份最小可用的客户端配置骨架，节点信息全部用占位符，换成你自己的服务器信息即可：

{
  "inbounds": [
    { "type": "mixed", "listen": "127.0.0.1", "listen_port": 7890 }
  ],
  "outbounds": [
    {
      "type": "vless", "tag": "node-a",
      "server": "<节点 A 的地址>", "server_port": 443,
      "uuid": "<节点 A 的 UUID>",
      "tls": { "enabled": true, "server_name": "<节点 A 的 SNI>" }
    },
    {
      "type": "vless", "tag": "node-b",
      "server": "<节点 B 的地址>", "server_port": 443,
      "uuid": "<节点 B 的 UUID>",
      "tls": { "enabled": true, "server_name": "<节点 B 的 SNI>" }
    },
    {
      "type": "urltest", "tag": "auto",
      "outbounds": ["node-a", "node-b"],
      "url": "https://www.gstatic.com/generate_204",
      "interval": "1m",
      "tolerance": 100
    },
    { "type": "direct", "tag": "direct" }
  ],
  "route": { "final": "auto" }
}

三个参数这样取舍：

url（测速地址）：用 https://www.gstatic.com/generate_204，它只返回一个空的 204 响应，测的是纯延迟，不会被页面大小干扰。前提是组里所有节点都能访问这个地址，否则测速结果不可信。
interval（测速间隔）：这里写 1m，即每分钟测一轮。不写这个字段时默认值是 3 分钟。间隔越短，故障发现越快，但探测也越频繁；家用场景 1 分钟是个折中，设成几秒反而会让切换抖动、日志刷屏。
tolerance（切换容忍度）：这里写 100，单位是毫秒，意思是新节点必须比当前节点快 100 毫秒以上才切换。两个节点延迟只差二三十毫秒时来回横跳没有意义，还会让出口 IP 频繁变化；容忍度就是用来压住这种抖动的。

注意 direct 没有放进 urltest 组。直连流量应该由路由规则分流，final 兜底才用 auto，不要把直连当成一个“候选节点”参与测速。

上线前三步验证，别直接上生产配置

先校验格式：sing-box check -c config.json，有报错先修 JSON，不要凭感觉启动。
确认出口真的在工作：本地走混合入口发一次请求，例如 curl --proxy socks5h://127.0.0.1:7890 https://www.gstatic.com/generate_204 -o /dev/null -w "%{http_code}\n"，返回 204 说明链路通。用图形客户端的话，直接看 auto 组里各节点的延迟数字是否都测出来了。
做一次故障演练：停掉当前最快节点那台服务器上的代理服务，等一个测速间隔后，再开一个新连接，应该已经走到另一个节点；恢复服务后，再等一轮测速，节点会重新回到候选。演练只在自己的服务器上做，确认切换真的发生过，比只看配置心里有底得多。

三个容易踩的坑

测速地址选错：如果某个节点访问测速地址本身就慢或不通，它会长期被判为“差节点”，哪怕它实际线路并不差。先确认每个节点单独访问测速地址都正常，再组 urltest。
节点同质化：两台同商家、同机房、同线路的机器，故障往往同时发生，组里再多也只是“看起来有备份”。备份的价值来自差异：不同商家、不同地区、不同线路。
把 urltest 当成高可用方案：它只能解决“出口选谁”的问题，解决不了单点入口、DNS、本地网络本身的问题。真要扛商家级故障，还得有另一层准备，比如本地备用网络和重要服务的离线备份——这部分可以对照站长的断网自救思路一起做（主机商被攻击、几十万网站打不开：个人站长的断网自救清单）。

小结

urltest 就干两件事：定期测速，自动把新连接交给最快且健康的节点。配置本身只有十几行，真正的功夫在前面：节点要来自不同商家和机房，测速地址要所有节点可达，参数要在“发现快”和“不抖动”之间取舍，上线前要亲手演练一次故障切换。做到这几点，手里那两三台 VPS 才算真正互为备份。

更多字段说明可以看官方文档的出站配置。