自动选节点，为什么没换到延迟最低的那条？

自动选节点后，列表里明明有更小的延迟数字，当前节点却没有变化，不一定是客户端失灵。先确认正在使用哪一种策略，再看它是否设置了“切换容差”。

本文适用于使用 Mihomo 内核的 Clash 类客户端，讨论的是自动选择组的判断方式。不同客户端的按钮和菜单可能不同，不能把下面的参数说明直接套到所有代理软件。

先认清：组名叫“自动”，不代表类型就是自动

策略组可以理解成一份候选名单，再加上一套选人办法。配置中的名称和类型是两回事，名字可以由配置提供方填写。

先查看当前配置或请提供方确认：

实际类型	怎样理解
select	手动选择，由你指定其中一个成员
url-test	根据健康检查结果进行自动选择

手动组也可以包含一个自动组。如果外层手动组仍选着某条固定节点，里面的自动组即使换了节点，也不能据此认定这次访问会跟着变。Mihomo 手动选择示例与代理组字段说明展示了类型、名称以及嵌套关系。

不想读配置也没关系，可以直接问：“我现在选中的这一项，实际是手动组还是自动选择组？这次访问有没有经过它？”

容差：快一点点，未必要马上换

Mihomo 的自动选择组提供 tolerance，中文可以理解为“切换容差”，单位是毫秒，也就是延迟数字旁常见的 ms。自动选择文档说明了这一字段。

它给节点切换留出余量：当前节点仍可用时，另一条节点只领先一点，可能继续保留当前选择。

下面是解释原理的虚构示例，不是本站测速结果，也不是推荐参数：

• 当前使用 A，本轮相关测试延迟为 80 ms。
• 候选 B 为 60 ms，比 A 少 20 ms。
• 该组切换容差设为 50 ms。

如果走的是正常的自动比较分支，当前选择仍有效，20 ms 的优势没有超过这份余量，就可能继续用 A。不能看到 B 的数字更小，就认定自动选择没有工作。

这也不是对所有配置的运行保证。本次核对的 Mihomo v1.19.33 选择逻辑还会考虑已有选择是否存在、是否可用，以及是否有手动指定的选择；具体结果要结合实际内核版本和状态判断。

列表上的数字，也可能不是这一轮的结果

健康检查是客户端按测试地址检查节点，和你手动打开某个网页是不同的动作。

检查间隔 interval 以秒计，不代表每次刷新页面都立即重测。配置中的 lazy 还会影响未被选中策略组的测试。官方文档说明，它默认开启，未选择到该组时不进行测试。查看健康检查相关字段

因此，比较之前先确认三个条件：

1. 两条节点确实属于正在判断的同一个自动组。
2. 观察的是接近同一时间、相同测试地址的结果。
3. 本轮测试已经完成，而不是一边仍显示旧数字。

如果不知道组的测试地址或测试范围，请配置提供方核对。不要为了让数字“对齐”，随意照抄别人的检查地址和时间间隔。

新手可以按这个顺序核对

先记下当前节点和原有选择，再做一次简短检查：

1. 打开一个平时需要代理的网站。 如果客户端有连接记录，查看这次请求实际经过的组和节点，避免只看旁边另一个组。
2. 核对组类型。 是手动组，就先确认它选中了哪一个成员；是自动组，再继续查看容差。
3. 检查是否手动固定过节点。 部分客户端会把这类操作保留下来。如果界面明确提供恢复自动选择的功能，按该客户端说明操作；找不到时不要猜按钮含义。
4. 在当前组完成一次检查后，再观察新的访问。 记录测试时间、候选延迟及最终选择，不必连续猛点测速。
5. 实际访问正常，就先保留设置。 自动组没有追着每一次微小波动切换，不等于你必须修改参数。

把容差调成零，也不能证明使用体验会更好。本文的检查目标是解释选中状态，不是用更小的显示数字代替实际访问结果。

如果节点已经超时，就别只盯着容差

“仍能使用，只是没有选最低延迟”和“当前节点已经不可用”，需要分开处理。核对的实现把当前选择不可用列为重新判断的条件之一，不能拿容差解释所有卡住或断线现象。对应版本实现

如果当前节点反复测试超时，实际网页也打不开，先确认候选中是否还有可用节点。若有可用备选却仍未恢复，可以保存以下信息，向客户端项目或配置提供方反馈：

• 客户端版本、内核版本、发生时间。
• 当前组的名称、实际类型和容差。
• 本轮测试地址、当前节点及候选的结果。
• 新发起的请求实际经过哪一组，能否打开目标网页。

截图或提交配置前，遮住订阅地址、密码和节点认证信息。这样记录的是可核查的现象，不会仅凭一次数字不一致，就把问题归结为机场线路故障。

资料核对日期：2026 年 10 月 27 日。