Mihomo 节点测速怎么做？延迟、丢包与实际速度判断

更新于 2026-11-13 · xn--mesv7f5toqlp.shop

简答：Mihomo 的节点测速主要是通过指定 URL 发起代理健康检查，返回的是一次 HTTP 测试延迟，不等于 ICMP Ping、丢包率或完整下载速度。更可靠的做法是固定测试 URL、网络和时间段，连续测试多次，再用超时次数、延迟波动、实际下载和网页访问结果综合判断。先在 Mihomo 中选定一个节点或代理组，用 API 的 delay 接口测试 5 次，再用 mixed-port 配合 curl 做一次真实传输验证。

定义：Mihomo 节点测速，是通过代理节点访问指定健康检查 URL 并记录响应耗时、超时和实际传输表现的过程，不是单独查看 Ping 数值。

先看结论：Mihomo 测速结果分别说明什么

官方 API 的节点 delay 接口会对指定代理发起测试，并返回毫秒级延迟；代理组也可以通过 URL、timeout、interval 和 expected-status 执行健康检查。因此，面板中的“延迟”首先代表测试 URL 的响应耗时，不应直接当作完整下载速度或长期稳定性。Mihomo 官方 API 文档

重要的是，Mihomo 官方 API 文档列出了 delay 和 history 等字段，但没有直接提供通用的“丢包率百分比”字段。本文把多次超时、连接中断、网页反复重试和持续传输断流作为丢包或链路不稳定的间接信号，不给出脱离网络、地区和用途的固定阈值。

第一步：统一测速条件，避免结果不可比

在开始测试前先做一张记录表。每一轮只改变节点，尽量保持设备、网络、测试 URL、Mihomo 配置、代理模式和测试时间段不变。代理组的健康检查支持 url、interval、timeout、lazy 和 expected-status 等参数，具体字段和默认行为应以当前官方文档为准。Mihomo 官方代理组配置文档

• 固定网络：同一台设备、同一个 Wi-Fi 或有线网络，测试期间暂停后台下载、云盘同步和系统更新。
• 固定测试 URL：例如 https://www.gstatic.com/generate_204，不要在同一轮中混用多个地址。官方代理组文档将 URL 定义为健康检查地址。
• 固定节点状态：手动选定一个节点，不要让 url-test 自动切换后再把不同节点的结果混在一起。
• 固定时间：至少分为日间和晚间两轮记录。某一次结果只能表示当时条件，不能直接推断长期表现。
• 保存配置：记录 Mihomo 内核版本、客户端名称、代理模式、是否使用 TUN，以及测试 URL 和 timeout。

可以使用下面的记录格式：节点名称｜测试时间｜测试 URL｜timeout｜第 1 至第 5 次延迟｜超时次数｜下载结果｜网页结果｜备注。订阅链接不要粘贴进公开截图、工单或文章，以免泄露访问权限。

第二步：用 Mihomo 客户端界面或 URL Test 做初筛

不同图形客户端的菜单名称可能不同，通常可在代理组、节点列表或延迟测试入口中选择单个节点测试。先只筛掉明显超时或连续失败的节点，再进入 API 和真实传输测试，不要只按一次最低延迟排序。

1. 打开使用中的 Mihomo 客户端，进入节点或代理组页面。
2. 选择一个固定的健康检查 URL；如果页面没有自定义入口，就记录客户端当前显示的测试地址。
3. 手动测试同一节点 5 次，记录每次延迟和是否超时。
4. 更换下一个节点，保持 URL、timeout 和网络条件不变。
5. 把结果按中位数、最大波动和超时次数整理，而不是只保留最小值。

如果配置文件中使用代理组，可以参考以下最小片段。它只展示健康检查相关字段，节点名称和订阅内容需要替换为你自己的配置：

proxy-groups:
  - name: "测速组"
    type: select
    proxies:
      - "节点 A"
      - "节点 B"

  - name: "自动测试组"
    type: url-test
    proxies:
      - "节点 A"
      - "节点 B"
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    timeout: 5000
    expected-status: 204

url-test 会按健康检查结果参与自动选择；如果你要做横向对比，建议先手动固定节点，避免自动组在测试期间改变选择。代理组文档说明，expected-status 可用于限定健康检查必须匹配的 HTTP 状态码。

第三步：用 Mihomo API 测试单个节点或代理组

如果客户端开放了 external-controller，可以直接调用 Mihomo API。API 请求通常需要在请求头中携带配置里的 secret；下方示例使用占位值，不要把真实密钥发布到网页或截图。官方 API 文档列出了单节点和代理组的 delay 接口。Mihomo 官方 API 文档

先确认 API 是否可访问：

curl -H "Authorization: Bearer YOUR_SECRET" \
  "http://127.0.0.1:9090/version"

如果你的 API 没有设置 secret，可以按客户端实际配置删除 Authorization 请求头。然后测试一个名称经过 URL 编码的节点：

curl -H "Authorization: Bearer YOUR_SECRET" \
  "http://127.0.0.1:9090/proxies/NODE_NAME/delay?url=https%3A%2F%2Fwww.gstatic.com%2Fgenerate_204&timeout=5000&expected=204"

正常时会返回类似 {"delay":123} 的 JSON；具体数值以实际返回为准。节点名含空格、中文或特殊字符时，先进行 URL 编码，否则可能得到 404 或请求路径错误。

如果要测试代理组，可使用：

curl -H "Authorization: Bearer YOUR_SECRET" \
  "http://127.0.0.1:9090/group/GROUP_NAME/delay?url=https%3A%2F%2Fwww.gstatic.com%2Fgenerate_204&timeout=5000&expected=204"

该接口会返回组内节点到测试 URL 的延迟映射。全部节点都超时，先检查 API 地址、测试 URL、当前网络和 Mihomo 日志；只有一个节点超时，则先把它单独标记为待复核，不要据此判断整组不可用。日志接口支持 info、warning、error 和 debug 等级，可用于确认是超时、连接失败还是规则分流问题。

第四步：用 mixed-port 做实际传输验证

延迟测试只能代表短请求响应。要判断下载表现，需要让 curl 通过 Mihomo 的本地入站端口访问一个你有权限访问的测试文件或页面。Mihomo 官方入站文档说明，mixed-port 同时支持 HTTP(S) 和 SOCKS5 代理；端口号以当前配置和客户端界面显示为准。Mihomo 官方代理端口文档

假设本地 mixed-port 是 7890，可以先测试响应头：

curl -x http://127.0.0.1:7890 \
  -I --max-time 15 \
  https://example.com/

再用一个你确认可访问、且允许测试的文件地址做持续传输：

curl -x http://127.0.0.1:7890 \
  -L --max-time 60 \
  -o test.bin \
  -w "\ncode=%{http_code} time=%{time_total}s speed=%{speed_download}B/s\n" \
  "https://example.com/test.bin"

如果使用 SOCKS5 入站，将 -x http://127.0.0.1:7890 改为 --socks5-hostname 127.0.0.1:7890。结果需要同时记录 HTTP 状态码、总耗时、下载速度和是否中途断开。TCP 或 HTTP 下载结果不能代表 UDP、QUIC、游戏延迟或视频会议质量；这些场景要用实际业务验证。

测速文件的服务器位置、文件大小、并发连接数、本地带宽和目标站点负载都会影响结果。因此，不要把某个文件的一次下载速度写成节点的固定带宽。

第五步：用重复结果判断延迟、丢包与稳定性

建议每个节点至少做 5 次短延迟测试，再做 1 次 30 至 60 秒的持续传输。短测用于发现响应慢和超时，长测用于发现断流、速度大幅下降和连接重建。这里的“丢包”不是 Mihomo API 直接返回的百分比，而是通过重复请求、超时和传输中断交叉观察。

不要设置“低于某个毫秒数就一定好”的全球通用标准。对于网页浏览，优先看超时和网页打开；对于视频会议，优先看连续传输、断流和实际音视频表现；对于大文件下载，优先看长时间速度和是否中断；对于游戏或其他 UDP 业务，TCP 下载测试只能作参考。

按使用场景选择节点：不要只看最低延迟

• 网页浏览：先排除超时和 DNS、规则错误，再比较多次延迟的中位数。
• 跨境办公：优先验证实际办公系统、登录、文件上传和长连接，不要只测公共健康检查地址。
• 视频会议：观察连续传输、音视频是否断续，以及切换节点后是否需要重新连接。
• 流媒体：用目标平台的实际页面或播放流程验证，健康检查成功不等于目标服务一定可用。
• 大文件下载：使用固定文件做 30 至 60 秒以上的传输记录，同时保留总耗时、平均速度和断流次数。
• UDP 或 QUIC 业务：不要用 TCP curl 结果直接代替 UDP 质量，需在实际应用中验证。

一轮测试结束后，建议保留原始记录，不要只保留“最佳节点”。如果晚间结果明显不同，可以分别建立日间和晚间记录，并在相同网络条件下重复测试。

最小排查清单：测速异常时按顺序处理

1. 确认 Mihomo 客户端正在运行，节点列表没有因订阅更新而改变。
2. 确认测试的是单个节点，而不是自动切换中的 url-test 组。
3. 确认 API 地址、端口和 secret 正确；不要把 API 暴露到公网。
4. 确认测试 URL 能在当前网络中访问，并检查 expected-status 是否设置过严。
5. 确认本地 mixed-port 或 SOCKS 端口确实在监听，端口号以当前配置为准。
6. 用 DIRECT 或浏览器直连做基线，再比较代理结果。
7. 打开 Mihomo 日志，区分 DNS、规则、连接超时、TLS 或远端响应错误。
8. 最后才判断节点本身表现，并用第二个测试 URL 或实际业务复核。

如果你使用代理提供者的健康检查，官方文档还支持为 provider 设置 health-check、url、interval、timeout、lazy 和 expected-status。provider 的健康检查结果同样应结合真实业务验证，不宜作为唯一筛选依据。Mihomo 官方代理提供者配置文档

常见问题

1. Mihomo 面板显示的延迟是不是 Ping？

不应直接当作传统 ICMP Ping。Mihomo 的官方健康检查和 API delay 接口围绕指定 URL 发起测试并返回响应耗时，所以它更接近一次代理 HTTP 可达性测试。要判断实际使用表现，还需要做持续下载和目标业务验证。

2. 为什么延迟最低的节点下载反而慢？

因为延迟测试通常只是一次短请求，不能覆盖持续传输、目标服务器、并发连接、规则和本地带宽。重新固定测试文件和端口，做 30 至 60 秒传输，并记录平均速度和断流情况。

3. Mihomo API 测速失败，是不是节点失效？

不一定。先区分单节点失败和全部节点失败；再检查 API 地址、secret、测试 URL、expected-status、本地网络和日志。只有单节点在多个条件下都失败，才适合把它标记为待复核。

4. 如何判断节点有没有丢包？

Mihomo API 本身不直接给出通用丢包率。可以连续请求 5 次，再做一次持续传输，观察超时、断流、重试和速度波动，并结合真实网页或办公业务复核。不要把一次超时换算成固定百分比。

5. url-test 自动选中的节点就是最适合我的节点吗？

不一定。url-test 按健康检查结果参与选择，适合做初筛，但它不覆盖所有目标网站、UDP 业务、下载吞吐和晚间变化。需要手动固定候选节点，再按自己的使用场景复核。

6. 测速时可以同时开 TUN、系统代理和浏览器代理吗？

不建议在同一轮中混用多个流量入口，否则难以确认请求实际经过哪个端口、规则或节点。先选择一种入口完成基线测试，再单独测试另一种模式，并记录模式变化。

常见问题

Mihomo 面板显示的延迟是不是 Ping？

不应直接当作传统 ICMP Ping。官方健康检查和 API delay 接口围绕指定 URL 测试并返回响应耗时，还需要结合持续下载和实际业务验证。

为什么延迟最低的节点下载反而慢？

短延迟测试不能代表持续吞吐。请固定测试文件和端口，做 30 至 60 秒传输，并记录平均速度、断流和超时。

Mihomo API 测速失败，是不是节点失效？

先区分单节点失败和全部节点失败，再检查 API、secret、测试 URL、expected-status、本地网络和日志。

如何判断节点有没有丢包？

Mihomo API 不直接提供通用丢包率。可用多次请求、持续传输、超时、断流和实际业务结果交叉判断，不要把一次超时换算成固定百分比。

url-test 自动选中的节点就是最适合我的节点吗？

不一定。url-test 主要依据健康检查结果，仍需按网页、办公、视频会议、下载或 UDP 业务分别复核。

相关阅读

• Mihomo 延迟低但速度慢怎么判断
• Mihomo 混合端口配置与端口冲突排查
• Mihomo 系统代理无法上网排查
• Mihomo 规则不生效排查
• Mihomo DNS 检查与回滚

参考资料

1. APIs - mihomo docs
2. proxy-groups configuration - mihomo docs
3. proxy-providers configuration - mihomo docs
4. Proxy Port - mihomo docs
5. inbound configuration - mihomo docs