低延迟却很慢？Mihomo节点测速三步筛选法

更新于 2026-10-20 · transocks.cyou

简答：Mihomo节点选择慢，先确认你遇到的是测速慢、自动切换慢，还是网页和视频实际访问慢。最快的处理顺序是：在Clash Party中先批量测延迟，保留少量候选；再用小数据量比较下载速度；最后用自己的目标网页或视频复核。低延迟只代表测试请求响应较快，不等于持续下载一定快。

定义：Mihomo节点测速，是通过代理节点访问测试地址，分别比较连接延迟、下载吞吐和实际业务表现，再选择适合当前用途的节点。

先看速查卡：三步解决节点选择慢

Clash Party原名Mihomo Party，项目仓库和当前构建文件使用Clash Party名称；界面名称和菜单位置仍可能随版本变化，以下步骤请以当前版本界面为准。Clash Party项目仓库

如果只是节点列表测试耗时，不要一开始对全部节点做大文件测速。先用低成本的延迟测试缩小范围，再进行下载和业务复核，通常更容易定位问题。

准备：区分三种“选择慢”，再备份配置

修改前先导出或复制当前配置。订阅刷新可能重新生成配置，手动改动不一定长期保留；如果客户端提供覆写或Merge入口，应优先使用覆写方式，并保留原文件备份。

下面是适合作为起点的Mihomo代理组配置。interval单位是秒，tolerance单位是毫秒，timeout单位也是毫秒；lazy: true表示未选中当前策略组时不主动进行定时测试。Mihomo官方配置文档对这些字段有明确说明。Mihomo代理组字段文档

proxy-groups:
  - name: 自动选择
    type: url-test
    include-all: true
    url: https://cp.cloudflare.com/generate_204
    interval: 300
    timeout: 5000
    tolerance: 50
    lazy: true

• url：健康检查使用的地址，不等于完整下载测速地址。
• interval：自动重新测试的间隔，300表示约5分钟。
• timeout：健康检查超时时间，5000表示5000毫秒，即5秒。
• tolerance：延迟切换容差，50表示50毫秒；差距未达到该值时，自动组不必频繁换节点。
• lazy：是否只在策略组被使用时进行定时测试。

配置示例中，Mihomo的url-test会依据测试URL选择延迟较低的节点，并使用interval控制测试间隔；官方示例还列出了tolerance和lazy。Mihomo官方配置示例

第一阶段：在Clash Party中先测延迟

1. 打开Clash Party，确认核心已经运行，并进入“代理”或“连接”页面；不同版本可能使用不同中文名称，以当前版本显示为准。
2. 在代理组或节点列表中找到需要测试的策略组，点击该组的延迟测试、测速按钮或对应的刷新图标。
3. 等待测试完成后，按延迟从低到高查看结果；对明显超时、无结果或远高于其他节点的项目先跳过。
4. 如果节点很多，先按节点名称中的地区、线路标签或自定义关键词缩小范围，再重新执行延迟测试。
5. 首轮保留约3至8个候选，不要立刻对所有节点做下载测试。

Clash Party的发布记录显示，2.0.0版本曾优化大型订阅下代理组延迟测试的更新性能，并修复部分节点显示或测速问题；如果你使用较旧版本，可先在“关于”或版本信息中核对，再决定是否按官方发布页升级。Clash Party发布说明

如果你在设置中看到“延迟测试地址”或类似英文项delayTestUrl，可从应用设置中检查它；公开问题记录还说明，代理组配置中的测试地址可能优先于应用级地址。若界面没有这些输入项，不要自行猜测菜单，直接检查当前代理组配置中的url字段。Clash Party延迟测试地址说明

第二阶段：只对候选节点做下载测速

延迟测试回答的是“测试请求响应得快不快”，下载测速回答的是“持续传输能力如何”。两者不是同一个指标，所以低延迟节点仍可能出现下载慢、视频缓冲或文件传输不稳定的情况。

可选的命令行方法是使用mihomo-speedtest-rs。建议优先把Clash Party导出的本地配置文件交给工具，不要直接粘贴订阅地址；订阅链接通常包含访问凭据，命令历史、日志或分享记录都可能暴露它。工具文档说明，--config支持本地配置路径，--fast只做延迟测试，--server-url设置测速服务器，--download-size单位是MB，--timeout支持秒数写法，--concurrent控制单节点测试连接数，--max-concurrent控制同时测试的节点数，--json输出JSON结果。mihomo-speedtest-rs CLI文档

先用小流量起步：5个候选节点、每个下载10MB，理论下载数据约为50MB；实际流量还可能受到失败重试和协议开销影响。首轮不要直接使用100MB或更大的数据量。

mihomo-speedtest --config ./config.yaml --fast --max-latency 500ms --max-concurrent 2 --json

mihomo-speedtest --config ./config.yaml --server-url https://speed.cloudflare.com --download-size 10 --timeout 10s --concurrent 2 --max-concurrent 2 --json

这里的两条命令分别对应“先测延迟”和“再测下载”。工具版本可能变化，执行前可运行下面的帮助命令，确认本机实际支持的参数；如果帮助输出与文档不同，以当前程序帮助为准。

mihomo-speedtest --help

Windows用户可在PowerShell中进入保存程序和配置文件的目录后执行；macOS或Linux用户可在终端中进入对应目录执行。若系统提示没有执行权限，先按当前系统的文件权限机制处理，不要从不明来源下载替换程序。

第三阶段：用目标业务复核最终节点

下载测速后保留表现较好的2至3个节点，再用你实际要完成的任务复核。可以记录：目标网页是否首开成功、连续使用是否出现卡顿、同一个文件或媒体任务是否反复超时。只记录自己能直接观察到的结果，不要把没有测量工具支持的指标当成精确数字。

如果节点延迟低但下载慢，不要直接判定测试失效，先用同样的数据量复测；如果下载速度高但目标网页打开慢，则可能是测试地址与目标业务路径不同。最终可以保留多个用途不同的候选，而不是只保留一个最低延迟节点。

测速异常时按现象排查

如果问题集中在DNS、TUN模式或整体连接速度，不要继续反复下载测速；先确认本地配置和核心运行状态，再回到上述三阶段流程。

常见问题

Mihomo节点测速应该先测延迟还是下载速度？

先测延迟，再测下载速度。延迟测试适合从大量节点中快速缩小范围；下载测速更耗流量，适合只比较少量候选节点。

为什么最低延迟节点不一定最快？

延迟反映测试请求的响应时间，下载速度反映持续传输能力，两者的请求过程和服务器响应并不完全相同。因此最终应结合下载测试和目标业务复核。

interval和tolerance应该怎么设置？

interval控制自动重新测试的间隔，单位是秒；tolerance控制延迟差异达到多少毫秒时才更换节点。可以从interval 300、tolerance 50起步；如果自动切换频繁，适当提高tolerance或延长interval。

测速URL、timeout和并发数在哪里改？

代理组配置中可以写入url、timeout、interval、tolerance和lazy。Clash Party部分版本也提供应用级延迟测试地址设置，但公开说明显示代理组配置可能优先于应用级地址；如果当前界面没有对应输入框，应以配置文件字段为准，不要添加未确认的字段。

常见问题

Mihomo节点测速应该先测延迟还是下载速度？

先测延迟，再测下载速度。延迟测试适合从大量节点中快速缩小范围；下载测速更耗流量，适合只比较少量候选节点。

为什么最低延迟节点不一定最快？

延迟反映测试请求的响应时间，下载速度反映持续传输能力，两者的请求过程和服务器响应并不完全相同。因此最终应结合下载测试和目标业务复核。

interval和tolerance应该怎么设置？

interval控制自动重新测试的间隔，单位是秒；tolerance控制延迟差异达到多少毫秒时才更换节点。可以从interval 300、tolerance 50起步；如果自动切换频繁，适当提高tolerance或延长interval。

测速URL、timeout和并发数在哪里改？

代理组配置中可以写入url、timeout、interval、tolerance和lazy。Clash Party部分版本也提供应用级延迟测试地址设置，但公开说明显示代理组配置可能优先于应用级地址；如果当前界面没有对应输入框，应以配置文件字段为准，不要添加未确认的字段。

相关阅读

• Mihomo连接速度慢：DNS、节点与TUN模式排查

参考资料

1. Mihomo官方配置示例
2. Mihomo代理组字段文档
3. Clash Party项目仓库
4. Clash Party发布说明
5. Clash Party延迟测试地址说明
6. mihomo-speedtest-rs CLI文档