Clash/Mihomo 开启 unified-delay 后延迟变低，节点真的更快了吗？
unified-delay 改变的是 Mihomo 的延迟计算口径，不会单凭一个开关增加带宽。解释开关前后毫秒数为何不能直接比较。
先看重点不一定。Mihomo 官方把 unified-delay 定义为用 RTT 统一不同类型节点的延迟计算，减少连接握手等因素造成的口径差异。开关后数字变小，首先说明测速算法变了，不能据此认定线路、带宽或实际网页速度提升；比较节点时应保持开关、测试 URL、网络和时段一致。
你只把配置里的 unified-delay 从 false 改成 true，面板数字比如从 110 ms 变成了 70 ms。网页打开速度却没什么变化，下载也没有变快。这个结果并不矛盾：两次显示的数字已经不是同一种计算口径。
开关前后的毫秒数不能直接当作线路提速幅度。 Mihomo 官方对这项配置的说明是“计算 RTT，以消除连接握手等带来的不同类型节点的延迟差异”。它调整的是延迟怎样计算，没有说明会更换线路、叠加带宽或改变机场节点本身。
它是在换测速口径，不是在换线路
不同代理类型建立连接时，可能经过不同的握手阶段。若测速把这些额外过程都算进结果，同一条网络路径也可能因为协议不同而出现不容易横向比较的数字。unified-delay: true 的目的，是用统一延迟口径减少这类差异。
这不代表被排除的握手过程在真实连接里不存在，也不代表数值越接近纯 RTT，网页就一定按相同比例加快。浏览器实际访问还会经过 DNS、代理协议握手、TLS、服务器响应和内容传输；列表里的一个毫秒数只覆盖测速工具定义的那一段。
可以把几种观察分开理解：
| 看到的现象 | 能说明什么 | 不能直接说明什么 |
|---|---|---|
| 打开开关后所有节点数值下降 | 延迟计算口径改变了 | 所有线路同时提速 |
| 同一口径下 A 持续低于 B | A 访问当前测试目标的延迟更低 | A 的下载、视频和游戏都更快 |
| 毫秒数更低，下载速度不变 | 延迟与持续吞吐不是同一指标 | 测速一定出错 |
| 数值忽高忽低 | 当前测试路径或网络存在波动 | 一定是机场超售或协议失效 |
IETF 的 RFC 9439 也把往返延迟、延迟变化、丢包与带宽、TCP 吞吐量列为不同指标。延迟数字更好看，并不能替代吞吐量或稳定性测试。
自动选择可能会变，但原因仍是测速结果
url-test 组会使用配置里的测试 URL、时间间隔和毫秒容差。统一延迟改变测得的数值后，节点之间的差距也可能变化，于是自动组的选择结果可能跟着变。
这仍然不是开关直接优化了节点。自动组只是在新的测量口径下比较候选项。测试 URL 离某个节点更近、某一刻网络更空闲，或者节点之间只差几毫秒，都可能影响排序；tolerance 的作用则是避免很小的差异频繁触发切换。
需要固定登录出口或保持长连接时，不要因为打开统一延迟后某个节点暂时排到第一，就把自动排序当作长期质量结论。url-test、fallback 和容差的区别说明了自动选择与故障转移各自解决的问题。
前后比较要用同一把尺子
想判断节点差异，至少要让 unified-delay 状态、测试 URL、客户端版本、当前网络和测试时段保持一致。先改开关，又换节点、换 DNS 或切到手机热点，最后只剩下一串无法归因的数字。
如果只是确认这个字段的影响，可以在同一网络、同一节点和同一测试目标下观察开关前后的显示变化，但结果只能回答“计算口径怎样改变”，不能充当线路加速测试。没有自己完成对照时，也不要照着别人的截图写出固定能降低多少毫秒。
真正关心网页和下载体验时，保持同一口径比较节点，再用实际任务确认：网页是否及时响应、下载能否维持吞吐、连接是否频繁中断。节点列表很低但实际仍慢，可继续看低延迟节点为什么网页和下载仍然慢；这些问题不是把数字算得更统一就会消失。
unified-delay 也不要和旁边常见的 tcp-concurrent 混在一起。后者会竞速同一目标解析出的多个 IP，采用最先成功的连接；前者只涉及延迟计算。两项都不是多节点带宽叠加，具体边界可对照tcp-concurrent 到底并发了什么。
配置原本稳定时，不必为了让面板数字更小反复切换。选择一个口径后持续使用，节点之间的相对变化才有可比性；是否真的更适合你的网络，仍要回到实际访问结果。
资料来源
以下来源于 2026/8/29 复核。版本、支持平台和发布状态以后续官方页面为准。
持续更新
收到新教程，也欢迎纠错
想收到新文章，可以关注 TG 频道；发现下载失效、套餐变化或步骤不一致，请附上页面链接和可公开的截图。不要发送订阅链接、密码或完整账户信息。
读者互动
这篇内容对你有帮助吗？
最新评论
- 正在加载评论……