Mihomo 延迟低为什么还是很慢？节点测速这样判断
简答：先记住两个结论：Mihomo 显示的毫秒数不是网速，单次最低延迟也不一定代表节点最好。打开代理组或节点列表，找到“延迟测试”“测速”“URL Test”或闪电图标，先在同一网络、同一测试地址下测三轮，再用实际网页、文件传输或办公连接验证。本文适用于已经导入节点并能正常运行 Mihomo 的配置，不覆盖安装、订阅获取和特定面板的精确菜单位置。
定义：Mihomo 节点延迟是内核通过健康检查地址测试代理后得到的响应耗时，单位通常为毫秒，用于比较测试条件下的响应表现，不等同于持续下载带宽。
先做 30 秒速查：测速入口和结果怎么判断
不同 Mihomo 外部面板的按钮名称可能不同，优先寻找“延迟测试”“测速”“URL Test”“健康检查”或闪电图标。最快的判断流程是：同一网络→同一测试地址→连续测三轮→看波动→做实际业务验证。
- 确认 Mihomo 已启动，节点已经出现在代理列表或策略组中。
- 打开当前正在使用的策略组，或进入节点列表，找到测速入口。
- 等待节点显示具体毫秒数、失败或
timeout。 - 记录每个节点至少三次结果，不要只保留一次最低值。
- 切换到候选节点后，打开你真正需要访问的网页、文件或办公服务，确认连接表现。
| 看到的结果 | 先怎么理解 | 下一步 |
|---|---|---|
| 显示毫秒数 | 当前健康检查在超时时间内完成 | 重复测试并做实际业务验证 |
| 数值低但变化大 | 响应可能不稳定 | 看多次结果，不要只选最低值 |
| timeout | 当前检查未在规定时间内完成 | 交叉测试其他节点和测试地址 |
| 延迟正常但网页打不开 | 健康检查通过不代表目标业务一定正常 | 检查当前策略组、规则、DNS 和连接日志 |
官方 API 文档说明，节点延迟接口返回的是毫秒数；策略组延迟接口可以返回组内节点名称及对应延迟。Mihomo API 文档 wiki.metacubex.one
Mihomo 测到的到底是 Ping、握手还是下载速度？
不要把 Mihomo 列表里的数字直接当作“网速”。官方配置文档将 url 定义为健康检查地址，将 timeout 定义为健康检查超时时间；因此结果首先反映当前节点完成该健康检查的响应表现，不能单独证明持续下载带宽。Mihomo 代理组配置文档 wiki.metacubex.one
- 延迟测试：判断节点能否在规定时间内完成当前健康检查，以及响应大约用了多久。
- 持续传输测试：观察文件或视频传输过程中速度是否持续、是否反复下降、连接是否中断。
- 实际业务验证：确认网页、办公系统、语音或其他目标服务是否真正可用。
如果配置启用了 unified-delay，官方说明是通过统一 RTT 计算方式，减少不同代理类型在连接握手等差异造成的延迟差别。它用于改善延迟比较条件，具体表现仍取决于版本和配置，不能把它理解为带宽测试。Mihomo 全局配置与 Unified Delay wiki.metacubex.one
下载测速怎么做：不用把毫秒数当成网速
如果你的问题是“哪个节点下载更快”，需要单独做持续传输观察。建议使用同一个公开文件或同一个实际业务页面，在同一网络、相近时间、同一设备上进行比较；每个节点固定观察一段时间，记录开始速度、稳定阶段速度、是否反复下降和是否中断。这个方法适合做相对比较，不是精确的线路带宽测量。
- 先选择两个或三个延迟较稳定的候选节点。
- 每次只更换节点，其他条件保持不变。
- 使用同一个文件或页面，避免把不同资源的服务器差异误认为节点差异。
- 观察传输过程，而不是只看刚开始出现的瞬时速度。
- 重复至少两轮；如果结果差异很大，记录测试时间和网络环境。
如果你使用 Mihomo API，还可以查看实时流量字段。官方 API 将 down 定义为当前下载速率，将 downTotal 定义为累计下载字节数；这些数据可辅助观察传输过程，但仍不能替代具体业务验证。Mihomo API 中的实时流量接口 wiki.metacubex.one
| 测试类型 | 回答的问题 | 不能证明什么 |
|---|---|---|
| 延迟测试 | 当前健康检查能否完成、响应多快 | 不能证明持续下载速度 |
| 持续传输 | 传输过程中是否稳定、是否容易中断 | 不能代表所有网站都同样表现 |
| 实际业务 | 目标网页、办公系统或服务是否可用 | 不能把一次成功访问当成长期稳定保证 |
url-test、select、interval、timeout 和 tolerance 怎么看
select 适合手动指定节点；url-test 会根据健康检查结果在组内节点之间进行自动选择。具体是否自动切换，还会受到当前策略组、外部面板和配置状态影响，因此不要默认所有客户端都必须手动切换。
官方文档中，interval 是健康检查间隔，单位为秒；timeout 是健康检查超时时间，单位为毫秒；tolerance 是节点切换容差，单位为毫秒；lazy 默认为启用时，未被使用的策略组可能不执行测试。Mihomo url-test 配置说明 Mihomo 代理组通用字段 wiki.metacubex.one
如果只想理解字段关系，可以参考下面的最小片段。修改现有配置前先备份；节点名称、测试地址和其他代理组必须替换为你自己的实际内容。
proxy-groups:
- name: 自动测速
type: url-test
proxies:
- 节点A
- 节点B
url: https://www.gstatic.com/generate_204
interval: 300
timeout: 5000
tolerance: 50其中，url 是健康检查地址，不是下载文件地址。若你修改后出现字段错误或策略组消失，立即恢复备份，不要同时叠加 TUN、DNS、MTU 等其他变量。
timeout、连接失败、低延迟但很慢：按顺序分流
- 只有一个节点 timeout：先用同一测试地址测试其他节点。如果其他节点正常，先把问题限定在该节点或节点配置，不要立即修改全局 DNS、TUN 或 MTU。
- 所有节点都 timeout：确认 Mihomo 正在运行、本机网络正常，并检查健康检查地址、超时时间和当前策略组。若使用代理集合的健康检查，还要注意官方文档对检查范围的说明。
- 测速有结果但网页打不开：确认当前实际使用的策略组，查看规则命中、DNS 和连接日志。健康检查地址成功，不等于目标网站一定成功。
- 延迟低但下载很慢：转到持续传输层面，观察速度曲线、连接重置和目标服务表现，不要用毫秒数直接推导带宽。
- 不同网络结果差异大：分别记录家庭宽带、移动热点或办公网络下的结果；只有某个网络失败时，优先检查该网络的 DNS、网关或出口策略。
如果需要手动调用 API，官方接口支持对指定节点或策略组发起延迟测试。指定节点的接口形式为 /proxies/{节点名称}/delay?url=测试地址&timeout=5000，策略组接口形式为 /group/{策略组名称}/delay?url=测试地址&timeout=5000，也可以传入 expected 指定期望的 HTTP 状态码。名称和 URL 需要进行实际编码，且 API 密钥和控制器应只在受控环境中使用。Mihomo 延迟测试 API 接口 Mihomo 外部控制器配置 wiki.metacubex.one
最后怎么选：稳定的实际表现优先于单次最低延迟
更合适的节点通常不是列表里一次显示最低毫秒数的节点，而是在相同条件下延迟波动较小、持续传输不容易中断，并且能完成你实际任务的节点。
- 普通网页：先看多次延迟是否稳定，再确认页面能否正常打开。
- 视频或文件：重点看持续传输是否稳定，不要只看延迟。
- 跨境办公：分别验证登录、文档同步和长连接，不要只测试公共健康检查地址。
- 实时语音或交互：关注延迟波动、连接中断和长时间表现。
完成初筛后，若使用的是 url-test 组，可以让客户端按配置进行自动选择；若使用 select 组，则根据外部面板实际操作手动切换。无论哪种方式，都建议重新打开目标业务或重新建立连接，确认当前连接确实使用了候选节点。
本文仅提供 Mihomo 节点测速与连接判断方法，站点与 Mihomo 项目不存在官方归属关系；涉及具体服务的订阅、节点和状态，应以对应服务的公开说明为准。
常见问题
Mihomo 延迟多少算正常？
不建议用一个固定毫秒数判断所有节点。测试地址、网络位置、本地网络和时间段都会影响结果。更可靠的方法是在同一网络、同一测试地址下重复比较，并结合实际网页或业务验证。
Mihomo 显示 timeout，是不是节点已经失效？
不一定。timeout 只表示当前节点没有在设定的健康检查超时时间内完成测试，也可能与本地网络、测试地址、DNS、临时拥塞或超时设置有关。先用其他节点交叉测试，再查看日志。
为什么延迟最低的节点下载却很慢？
延迟测试主要反映健康检查请求的响应表现，不能代表持续下载带宽、长连接稳定性或目标服务限制。应使用同一文件或页面进行持续传输观察。
url-test 会不会自动选择节点？
url-test 用于根据健康检查结果进行自动选择，但实际是否定时检测和切换，还取决于 interval、lazy、当前策略组是否被使用以及外部面板实现。select 组则通常用于手动选择。
测速时要不要同时开启 TUN、修改 DNS 或 MTU？
不建议。先用当前配置完成基础节点测速和实际连接验证。只有基础连通性确认后仍有异常，才按单项变量排查，并在每次修改前备份、修改后保留恢复方式。