Mihomo节点测速怎么做？延迟、速度和稳定性排查教程
简答：Mihomo节点测速应先确认配置已激活，再用同一HTTPS地址测试延迟，随后通过代理实际访问和下载，最后至少复测多轮；低延迟不代表真实业务一定更快。
定义：Mihomo节点测速，是通过指定代理节点访问固定HTTPS测试地址并记录响应延迟、成功率或实际吞吐的过程，不等同于本地Ping。
先按四步测试：不要只看延迟数字
本文是与 Mihomo 项目及其开发者无隶属关系的第三方使用指南。最快的做法是：先确认配置已激活，使用同一个 HTTPS 地址做延迟测试，再通过代理访问固定网页或文件，最后在相近网络条件下多轮复测。
| 测试项目 | 主要观察值 | 能判断什么 | 不能单独判断什么 |
|---|---|---|---|
| 节点延迟 | 响应毫秒数、是否超时 | 该节点到测试地址的响应情况 | 视频、下载或长连接一定流畅 |
| 代理连通性 | HTTP状态、页面是否打开 | 节点是否能完成实际代理访问 | 持续吞吐和高峰期稳定性 |
| 实际下载 | 下载耗时、平均速度 | 固定文件或网页场景下的吞吐 | 所有网站和所有时段的速度 |
| 稳定性复测 | 成功率、波动、断连次数 | 结果是否可重复 | 未来时段一定保持相同表现 |
- 暂停后台下载、云盘同步和大型更新，避免本地带宽干扰。
- 固定测试地址、测试时段和客户端配置，不要一轮使用多个不同地址。
- 先做批量延迟测试，再对候选节点做真实网页或文件测试。
- 至少记录多轮结果，优先选择成功率高、波动小且实际任务能完成的节点。
官方 Mihomo API 将延迟定义为针对指定节点和测试 URL 的测量结果；没有成功测量时，应视为测试失败或不可连接，而不是把结果当作零延迟。可查看 Mihomo API 文档。
图形界面怎么测：以官方 Mihomo Dashboard 为例
如果你使用的是带面板的 Mihomo 客户端，先在连接设置中填入 Mihomo 的控制地址和 Secret，再进入代理组或节点列表执行延迟测试。官方 MetaCubeXD 支持代理组管理和延迟测试；桌面版会自动配置本地控制端点，但具体菜单名称可能随客户端版本变化。可参考 MetaCubeXD 官方仓库。
- 打开客户端，确认当前配置已经激活，节点列表不是空白。
- 确认客户端内核正在运行，并记下控制地址与 Secret。不要把 Secret 粘贴到公开聊天或网页。
- 进入代理组或节点列表，选择批量健康检查、延迟测试或相近名称的功能。
- 固定测试地址后开始测试。若面板允许填写地址，优先使用你能稳定访问且返回明确HTTP状态的 HTTPS 地址。
- 查看结果时区分“毫秒数”和“超时”。超时表示本次探测未在规定时间内完成，不应按一个极高延迟参与排序。
- 对排名靠前的节点再做网页访问和文件下载，不要直接把最低延迟节点设为长期使用节点。
如果面板显示的是策略组而不是叶子节点，先确认当前测试对象是具体节点。策略组的结果可能反映组内自动选择逻辑，不能替代对单个节点的复测。
用 Mihomo REST API 测试节点或策略组
API 适合需要重复测试、保存结果或排查面板显示异常的场景。Mihomo 官方接口提供单节点延迟测试和代理组批量测试；接口参数包括测试 URL、超时时间，以及可选的期望HTTP状态码。字段和返回格式以 Mihomo API 官方文档为准。
先确认配置中已开启控制端口，并设置 Secret。示例中的地址、端口、Secret、策略组名称和测试 URL 都要替换为你自己的值：
- 读取代理组信息：
curl -H "Authorization: Bearer YOUR_SECRET" "http://127.0.0.1:9090/group"。判定标准：返回JSON且能看到目标策略组，说明控制接口基本可访问。 - 测试策略组内节点：
curl -G -H "Authorization: Bearer YOUR_SECRET" --data-urlencode "url=https://YOUR-TEST-URL.example/" --data "timeout=5000" "http://127.0.0.1:9090/group/YOUR_GROUP/delay"。判定标准：返回节点名称与毫秒数映射；没有返回或全部失败时，先检查策略组名称、测试地址和内核日志。 - 测试单个节点：
curl -G -H "Authorization: Bearer YOUR_SECRET" --data-urlencode "url=https://YOUR-TEST-URL.example/" --data "timeout=5000" "http://127.0.0.1:9090/proxies/YOUR_NODE/delay"。节点名称含空格、斜杠或特殊字符时，先使用面板或API返回的实际名称，并按URL编码规则处理路径。 - 限定期望状态码：
curl -G -H "Authorization: Bearer YOUR_SECRET" --data-urlencode "url=https://YOUR-TEST-URL.example/" --data "timeout=5000" --data "expected=200-299" "http://127.0.0.1:9090/proxies/YOUR_NODE/delay"。判定标准：只有返回符合期望范围的HTTP响应才计为成功。
示例默认使用本机控制地址和常见端口只是演示，实际端口必须以你的客户端配置或日志为准。若接口返回401、403或无法连接，先检查 Secret、控制端口、监听地址和防火墙；不要为了测试把控制接口无保护地暴露到公网。
用 url-test 自动测：配置文件怎么写
Mihomo 的 url-test 会按照指定测试地址的结果选择延迟较低的节点。官方配置示例包含 type: url-test、proxies、url 和 interval 等字段；可参考 Mihomo 官方配置示例以及 url-test 官方说明。
一个可检查的结构如下，节点名和测试地址必须替换：
proxy-groups:- name: 自动选择type: url-testproxies: [节点A, 节点B, 节点C]url: https://YOUR-TEST-URL.example/interval: 300tolerance: 50
interval 表示自动检测间隔，tolerance 表示节点切换所使用的毫秒容差。不要把它们理解成下载速度或丢包率。修改后先在客户端内校验配置，再重新加载配置；如果配置校验失败，回退到上一个可用版本。
如果你只想手动筛选节点，可以先使用批量延迟测试，不必马上建立自动切换组。自动组的选择结果仍取决于测试地址、检测间隔和当时的网络环境。
真实速度怎么测：通过代理访问和下载
延迟测试只测指定 URL 的响应时间，不能替代实际下载。要测吞吐，先确认 Mihomo 的本地混合端口或HTTP代理端口，再让命令行工具通过该端口访问一个你有权限使用、大小固定的测试文件。下面的地址是占位符，必须替换为你自己的稳定测试文件：
- 测试网页连通性：
curl -x http://127.0.0.1:7890 -I -L --max-time 20 https://YOUR-TEST-URL.example/。判定标准：在超时前返回HTTP响应，且多轮测试都能完成。 - 记录下载耗时：
curl -x http://127.0.0.1:7890 -L -o /dev/null -w "time=%{time_total} speed=%{speed_download} bytes=%{size_download}\n" --max-time 120 https://YOUR-FIXED-FILE.example/test.bin。判定标准：比较相同文件、相同端口和相近时段下的结果，不要把一次结果当成长期代表值。
如果你的客户端没有使用 7890，把命令中的端口替换为实际混合端口；如果只开启了 SOCKS5，则应改用支持 SOCKS5 的参数形式。测试期间关闭后台下载，并记录文件大小、时间、节点名称和是否成功。
视频、远程桌面或跨境办公场景还应单独验证长连接、持续传输和业务页面。一个节点可能短请求延迟较低，但在持续下载或长连接中出现波动，因此最终筛选应以真实使用场景为准。
测速超时、低延迟卡顿和结果波动怎么排查
| 现象 | 可能原因 | 先做什么 | 判定标准 |
|---|---|---|---|
| 全部节点超时 | 测试地址不可达、控制配置未生效或本地网络异常 | 先确认配置激活，再换一个可核验的HTTPS测试地址 | 至少一个节点能稳定返回响应 |
| 低延迟但网页卡顿 | 延迟地址与实际业务路径不同，或持续吞吐波动 | 对同一节点做固定网页和文件测试 | 实际业务连续完成且多轮结果接近 |
| 测试结果忽高忽低 | 后台流量、无线网络变化、测试地址负载或节点拥塞 | 暂停后台任务，固定时段和地址后复测 | 多轮结果的波动明显收窄 |
| 面板能看见节点但API失败 | 控制地址、端口或 Secret 不一致 | 从当前配置和日志重新核对接口信息 | /group 能返回有效JSON |
不要用本地 ping 或 traceroute 直接替代代理测速。客户端是否转发ICMP取决于运行模式和系统路由；即使节点能代理访问网页，也不代表ICMP一定经过该节点。使用 fake-ip DNS 时，域名可能解析到保留地址，进一步使基于域名的本地测试失真。
排查时还要确认规则模式没有把测试地址分流到直连。如果你测试的是节点，却发现日志显示连接走了 DIRECT，应先检查规则、策略组选择和系统代理状态。
如何根据结果选节点：建议保存一张测试记录
不要设置脱离网络环境的固定“合格毫秒数”或“保证速度”。更可靠的做法是对候选节点使用同一测试流程，并记录以下字段：
- 节点名称和所属订阅来源。
- 测试日期、时段、网络类型和客户端模式。
- HTTPS延迟是否成功，以及返回的毫秒数。
- 网页访问是否完成、文件下载是否成功。
- 多轮测试的成功次数、失败次数和结果波动。
- 是否满足你的实际需求，例如网页、视频、远程桌面或跨境办公。
最终选择时，先淘汰频繁超时或业务访问失败的节点，再在剩余节点中比较稳定性和实际吞吐；如果两个节点都能完成任务，优先选择波动较小、无需频繁手动切换的节点。这个判断只适用于本次测试条件，不能推断未来所有时段的表现。
测速会产生请求和下载流量。测试前确认测试地址可信、文件来源可靠，避免使用包含账号、Cookie或内部资料的页面进行公开记录；API Secret也应只保存在本机或受信任的管理环境中。
常见问题
Mihomo节点测速看延迟越低越好吗？
不一定。延迟只反映指定节点到指定测试地址的响应时间。应同时检查网页访问、固定文件下载和多轮成功率；低延迟但实际卡顿的节点，不应只因为数字小就优先选择。
为什么Mihomo测速显示超时，但节点偶尔还能打开网页？
可能是测试地址与实际网页路径不同、测试超时时间较短、节点临时拥塞，或测速请求被规则分流。先固定测试地址，检查日志和规则，再通过代理访问同一网页并多轮复测。
Mihomo的url-test能直接测出下载速度吗？
不能。url-test主要根据指定URL的健康检查结果和延迟进行自动选择，不等于大文件吞吐测试。要判断下载速度，应通过本地代理端口访问固定大小的测试文件。
Mihomo REST API测试需要什么条件？
需要内核正在运行、控制接口地址和端口正确，并使用配置中的 Secret 发送授权请求。单节点和策略组接口都需要指定测试URL与超时时间，节点名称含特殊字符时还要正确处理URL编码。
测速前需要关闭TUN或系统代理吗？
不必一概关闭，但要确认测试请求确实经过目标Mihomo节点。若规则把测试地址分到直连，或系统代理、TUN与其他客户端同时运行，结果可能不能代表目标节点，应先查看连接日志和路由结果。