本文目录
手动选中节点后网页能打开，延迟测试却失败，自动选择也不愿选它。这时先别重导订阅：Mihomo 曾有一个很窄的计时问题，测试目标响应不足 1 毫秒时，成功耗时会被截成 0。
节点能用，为什么测速还是报失败？
官方 #3316 记录的现象是：同一节点的测试历史出现 alive: true 与 delay: 0，单节点延迟接口却返回 503，自动组还可能把这个 0 当作没有有效延迟。这类测试目标通常在同一主机、局域网或很近的边缘节点，并非所有测速失败。
图形客户端可能把内核错误统一显示为失败或超时，界面不一定直接显示 0ms。只看到一个 Timeout，或只看到 alive: true，都不能确认这个缺陷；必须核对同一节点、同一测试 URL 和相近时间的结果。
先区分三种看起来相似的情况
| 现象 | 应该怎样处理 |
|---|---|
| 测试很快完成，旧内核却记成 0，并与失败提示并存 | 核对 #3316 的计时情形，再按支持的渠道取得修复。 |
| DNS、TLS、连接失败或真实请求超过 timeout | 按对应日志排障，不能用亚毫秒修复解释所有超时。 |
| Provider 刷新后自动组不切换，但没有上述计时证据 | 保留当时记录，另查组状态；不能把它当作同一个已修复问题。 |
v1.19.33 改的是计量，不是网络速度
v1.19.33 正式发布说明列入 #3316。固定源码在 URLTest 正常返回路径把耗时换算为整毫秒后，若结果为 0，就记录为 1，避免与“没有有效延迟”的 0 混淆。unified-delay 开启时，第二次成功请求的计时也经过这一共同处理。
这个 1ms 是计量下限，不代表网络真的用了整整 1 毫秒，更不是提速保证。测试请求仍要经过连接、HTTP 请求和配置的状态码判断；测试目标、节点和客户端的实际情况仍需分别检查。
调大 timeout 只能改变等待时间，tolerance 影响自动组的切换容差，都不能补上截成 0 后丢失的有效计时。不要靠反复改这两个值来验证本修复。
先记录哪个节点、哪个 URL 在失败
不同客户端的菜单名称不同。使用应用已有的内核信息、启动日志、节点测速和连接记录入口即可，不必为了核对而开启 external-controller、暴露端口或分享 secret。客户端版本也不能代替正在运行的 Mihomo 版本。
把测速结果和实际连接对应起来
确认实际内核与当前配置
在内核信息或本次启动日志记录完整版本，记下启用的配置、节点名称和测试 URL。不要用另一个目录下的内核文件版本代替。
区分单节点、自动组与 Provider 检查
查看实际生效配置里的测试入口、url、timeout、interval、expected-status 和 unified-delay。组的 url 用于其 proxies；由 use 引入的 Provider 另有健康检查，不能假定它们使用同一目标。
在同一条件下少量复测
选中同一节点，运行客户端已有的单节点测试，并在连接记录确认一次真实请求确实经过它。记录时间和错误；成功打开网页与测速请求本来就是两种观察。
只使用能取得的证据
若原有本地诊断能看到 delay/history，就对照同一节点和 URL 的 0 与失败结果；看不到时保留界面和日志，把它标为待确认，不从 UI 的 Timeout 推断亚毫秒耗时。
若测试 URL 返回的状态码不符合 expected-status，或日志显示解析、证书、连接错误，先处理这些明确原因。不要为制造小于 1ms 的结果搭建服务、猛刷测试或关闭证书校验。
怎样用上修复，并验证它真的生效？
先独立备份当前配置、客户端数据和可恢复的原版本。应用支持单独更新内核时，通过其认可的正式渠道选择包含 #3316 的版本；不支持时，使用维护者确认集成该修复的正式客户端包，不覆盖应用内部文件。
更新后保持测试对象一致
确认真正启动了新内核
v1.19.33 已确认收录修复。更新并按客户端要求重启后，再读内核信息或新日志，不仅看应用的更新成功提示。
重测相同节点和相同目标
恢复同一配置与测试 URL，先进行单节点测试，再观察原自动组或 Provider 检查。各入口分别比较，不能拿不同目标的结果当作升级前后对照。
同时验证使用中的请求
确认客户端的连接记录仍指向预期节点，再验证之前能用的网页或应用请求。若原有诊断可见，核对该测试不再因有效耗时被记成 0 而误报；不要要求所有节点都显示 1ms。
若暂时没有受支持的修复包，可在确认节点实际可用后手动选择它，作为临时使用方式。它不修复计时，也不证明自动故障切换已经恢复；无法确认时保持原配置并等待正式更新，不删除订阅或改写整份配置。
哪些检查通过，才算完成这次处理？
逐项核对，不只看一个绿色数字
- 已经记录正在运行的内核完整版本，并确认更新渠道和实际加载配置。
- 升级前后使用同一节点、同一测试 URL，各检查入口的状态码要求与时间单位已分清。
- 没有同时改 DNS、TLS 校验、timeout、tolerance 或订阅，避免把其他变化当作修复效果。
- 原有单节点测速及实际请求均已复查；自动组或 Provider 的健康检查另行观察，没有仅凭一次手动测试推断全部恢复。
- 仍失败时保存具体错误、时间和脱敏结果，把真实超时、状态码不符及 Provider 刷新问题分别记录。
本文依据官方修复和固定源码解释计时情形，没有下载内核或替你的环境做实机复现。若升级后仍显示失败，应沿新的具体错误继续排查，不能把 v1.19.33 当成解决所有延迟测试问题的承诺。
更新后出现其他异常，怎样恢复？
停止受影响操作，通过原受支持更新方式恢复保存的原版本，再恢复与它对应的独立备份。不要让两个版本同时写入同一个数据目录，也不要覆盖唯一备份。恢复后检查实际内核、配置、手动选择和真实请求。
回退可能重新带回计时缺陷，只适合恢复可用环境。向维护者反馈时附系统、内核完整版本、测试入口、脱敏 URL、时间和具体错误；移除订阅令牌、控制密钥与私人信息。不要仅凭 issue 已关闭，就判断手中的安装包包含修复。