network speed test 节点测速怎么做？客户端显示 50ms 仍然很慢时这样测
简答：先确认测速是否真的经过节点：Ping 通常测不到代理链路，客户端延迟测试只代表指定探测地址，真实比较应固定节点后用 curl 代理参数或浏览器请求复测，再结合首字节、下载速度、丢包和多时段波动判断。
定义：节点测速是让同一设备在切换不同网络节点后，向相同目标地址发起延迟、连接、HTTP 请求或持续下载测试，用于比较实际访问表现。
先试这一步：确认测试是否真的经过节点
如果客户端里显示某个节点延迟很低，但网页打开或文件下载仍然很慢，第一步不是继续比较数字，而是确认测试流量有没有经过该节点。本文是第三方使用指南站，与 Clash Verge Rev 项目及其开发者无隶属关系；软件界面名称、默认端口和测试地址可能随版本或配置变化，应以当前客户端显示为准。
| 测速方式 | 是否经过所选节点 | 主要测量对象 | 适合用途 |
|---|---|---|---|
系统 ping | 通常不经过 HTTP/SOCKS 代理；TUN 场景还可能受虚拟网卡与 DNS 配置影响 | ICMP 往返响应 | 只做基础连通性线索，不用于直接排名代理节点 |
| 客户端内置延迟测试 | 通常由客户端内核经节点请求指定 URL；具体测试地址以客户端配置为准 | 探测 URL 的请求延迟 | 快速初筛节点，但不能代表所有网站和下载速度 |
curl.exe -x 或 --socks5-hostname | 是，前提是填写正确的本地代理端口 | DNS、TCP、首字节、完整传输时间和平均下载速度 | 复测某个真实目标，比较节点实际访问表现 |
| 浏览器测速站或业务页面 | 取决于浏览器是否使用系统代理、TUN 或手动代理 | 页面、资源或下载文件的实际体验 | 验证最终使用场景，但受测速站和浏览器环境影响 |
Mihomo 文档把 port、socks-port、mixed-port 与 TUN 分开定义；混合端口可同时接受 HTTP(S) 和 SOCKS5 请求，实际端口仍应以客户端设置页或配置文件为准，参考 Mihomo 代理端口文档 和 Mihomo 入站配置文档。
以 Clash Verge Rev 为例：先做客户端内置延迟初筛
- 更新配置并确认节点已加载。在 Clash Verge Rev 中先确认订阅或配置已成功更新，再进入代理或代理组页面。不要把尚未完成加载、名称重复或显示异常的节点直接拿来比较。
- 选择同一个代理组进行测试。点击代理组或节点区域中的延迟测试按钮；不同版本的按钮图标和文字可能不同。官方项目的公开 Issue 中可见“测试延迟”和“全部延迟测试”等操作描述，具体入口以当前版本界面为准，参考 Clash Verge Rev 延迟测试 Issue。
- 记录测试地址和结果。内置测试的数值通常只对应某个探测 URL，不等于访问所有网站的延迟。项目发布说明曾记录网站测试使用真实 TLS 握手延迟，但不同版本的默认地址和实现可能变化，不能把某个版本的默认行为套用到所有版本，参考 Clash Verge Rev 官方 Releases。
- 只把内置延迟当作初筛。可以先排除持续超时、明显波动或无法完成探测的节点，再对剩余节点做代理 curl 或浏览器复测。若一个节点内置测试显示超时，但真实网页可打开，不要立即判定节点不可用；官方 Issue 曾记录过延迟测试超时而实际连接正常的情况，需继续做实际目标测试，参考 Clash Verge Rev Provider 节点延迟测试 Issue。
重要区别：ICMP 通常不会被 HTTP 或 SOCKS 代理转发，所以系统 ping 测到的是本机到目标地址的 ICMP 路径，不是“经所选节点访问目标网站”的完整结果。启用 TUN 后，系统流量会被虚拟网卡接管，DNS、路由和 fake-IP 配置还可能改变观测结果；因此不要用一个看似很低的 Ping 数字替代真实代理请求。
用 curl 让请求真正经过节点：Windows 命令可直接复制
在 Windows PowerShell 5.1 中，curl 可能是 Invoke-WebRequest 的别名，参数并不等同于原生 curl。请明确使用 curl.exe；Microsoft 文档也说明，Windows PowerShell 5.1 可通过显式调用 curl.exe 避免别名冲突，参考 Microsoft Learn：Windows 中的 curl。
HTTP 代理端口示例：把 127.0.0.1:7890 替换为客户端当前显示的 HTTP 或 mixed 代理端口，把 https://example.com/test.bin 替换为你有权限测试的 HTTPS 文件地址：
curl.exe -x http://127.0.0.1:7890 -o NUL -s -w 'dns=%{time_namelookup} connect=%{time_connect} start=%{time_starttransfer} total=%{time_total} speed=%{speed_download}\n' https://example.com/test.bin
SOCKS5 代理端口示例：把端口替换为客户端显示的 SOCKS5 端口。--socks5-hostname 会让代理解析目标主机名，适合需要确认 DNS 也由代理侧处理的测试：
curl.exe --socks5-hostname 127.0.0.1:7891 -o NUL -s -w 'dns=%{time_namelookup} connect=%{time_connect} start=%{time_starttransfer} total=%{time_total} speed=%{speed_download}\n' https://example.com/test.bin
curl 官方文档说明，-x 或 --proxy 用于指定代理，--socks5-hostname 用于指定 SOCKS5 代理并由代理解析主机名；time_connect、time_starttransfer、time_total 和 speed_download 分别用于观察连接、首字节、总耗时和平均下载速度，参考 curl 官方命令文档。
判定标准：命令能完成且返回 HTTP 状态，说明该代理端口至少完成了这次请求；start 较大时，重点排查 DNS、TCP、TLS 或目标服务处理时间；speed 波动明显时，应在相同文件和相同时间条件下重复测试。命令成功不代表所有网站都正常，仍要结合实际业务地址复测。
完整下载与 Range 分段测速不是一回事
如果目标是比较持续下载能力，应使用足够大的静态文件做完整下载，让传输时间足以覆盖连接建立后的稳定阶段。此时不需要先检查 Accept-Ranges，也不应把是否支持 Range 当成完整下载测速的前提。
只有在你要做多线程、断点续传或分段读取时，才需要单独检查 Range。可以运行：
curl.exe -x http://127.0.0.1:7890 -I https://example.com/test.bin
把示例域名和路径替换为实际测试文件后，查看响应头是否出现 Accept-Ranges: bytes。如果进一步发送范围请求，服务器通常会用 206 Partial Content 表示返回部分内容；返回 200 可能意味着没有按范围响应，不能把它当成分段测速结果。参考 MDN：HTTP Range 请求 和 MDN：206 Partial Content。
因此，节点带宽比较建议分成两条记录：一条是完整下载的平均速度，另一条是可选的 Range 或分段测试结果。两者测试目的不同，不能混在同一列，也不能用小文件的瞬时峰值代表持续带宽。
浏览器和多时段复测：把节点数字换成真实体验
- 固定测试条件。关闭云盘同步、系统更新、视频播放和其他大流量任务；固定设备、网络连接方式、浏览器、目标 URL 和文件大小。每次只切换一个节点。
- 确认浏览器确实走代理。如果只开启了客户端但没有系统代理、TUN 或浏览器代理规则，浏览器可能仍然直连。可先访问一个你有权限查看的业务页面，再对照客户端连接日志确认请求是否进入代理。
- 同一节点连续测试。每个节点至少记录多次结果，不要只保留最高速度。把平均值、中位数、最大延迟和异常次数分开记录。
- 覆盖不同时间段。至少选择白天和业务高峰时段复测；如果目标是办公、会议或文件传输，应在接近实际使用的时间测试。本文不把某个固定时段或单次结果写成通用排名。
- 比较真实业务目标。网页打开慢，重点看首字节和页面资源；文件传输慢，重点看完整下载平均速度；远程办公或实时交互，重点看延迟波动、丢包和连接是否反复重建。
如果测试的是网站而不是单纯节点，响应头还要区分 CDN 命中与回源。可用下面的命令查看响应头：
curl.exe -x http://127.0.0.1:7890 -I https://example.com/test.bin
检查是否出现 CF-Cache-Status、Age、X-Cache 等字段。Cloudflare 文档说明，CF-Cache-Status 用于表示缓存处理结果，Age 表示对象在缓存中的时间；这些字段只在响应确实提供时才有解释意义，缺少某个字段不能单独证明一定回源，参考 Cloudflare：缓存响应 和 MDN：Age 响应头。
可复制的记录模板与简单评分方法
建议把每个节点单独记录，避免只写“快”或“慢”。下面的模板可以复制到表格中使用：
| 节点 | 时间 | 测试地址 | 代理端口 | 客户端延迟 | 丢包 | HTTP 首字节 | 完整下载 | 异常备注 |
|---|---|---|---|---|---|---|---|---|
| 节点 A | ____ | ____ | ____ | ____ ms | ____ % | ____ ms | ____ Mbps | ____ |
| 节点 B | ____ | ____ | ____ | ____ ms | ____ % | ____ ms | ____ Mbps | ____ |
| 节点 C | ____ | ____ | ____ | ____ ms | ____ % | ____ ms | ____ Mbps | ____ |
如果需要做简单评分，不要把所有业务都套用同一权重。可以先把各项换算成相对分数，再按用途加权：网页和接口访问可提高首字节与连接成功率权重；文件传输可提高完整下载速度权重；远程办公或实时交互可提高延迟波动、丢包和连续连接稳定性权重。没有统一业务目标时，建议只做并列对比，不强行生成总分。
一个实用的淘汰顺序是：先排除无法完成代理请求、频繁超时或丢包明显的节点；再比较同一目标的 HTTP 首字节；最后比较多次完整下载的中位数和波动。延迟最低但首字节慢、下载波动大的节点，不应仅凭 Ping 或客户端单次延迟确定为首选。
测速异常时的排查顺序
- curl 返回连接失败：先确认客户端正在运行，再核对 HTTP、SOCKS5 或 mixed 端口类型。端口写错、客户端未监听或只开启 TUN 而未提供可用代理端口，都会导致命令失败。
- Ping 很低但 curl 很慢：不要继续看 Ping，改查代理请求的
time_connect、time_starttransfer和time_total。这说明 ICMP 线索与实际应用请求不是同一条测量链路。 - 客户端延迟全部超时：换用客户端提供的全部测试，再用固定节点的 curl 请求验证真实目标。官方项目 Issue 记录过测试超时但实际访问正常的情况，因此“超时”应先作为测试结果异常处理，而不是直接等同于节点不可用，参考 相关官方 Issue。
- TUN 模式结果异常：暂时关闭 TUN，仅用系统代理或显式代理端口复测，再分别比较结果。TUN 会接管系统流量，DNS、路由和 fake-IP 设置可能改变测试路径；Mihomo 的 TUN 与 DNS 配置说明可参考 Mihomo 配置示例。
- 下载速度忽高忽低：检查后台流量、目标文件大小、服务器限速和缓存状态，并在相同目标、相同端口、相同节点下重复测试。不要用一次峰值替代多次平均或中位数。
- PowerShell 报参数错误：确认使用的是
curl.exe而不是curl；如果仍有问题，运行curl.exe --version检查是否能调用原生 curl，再逐步减少参数定位问题。
最终选择应回答“这个节点在我的目标、设备、时间和业务下是否稳定”，而不是回答“哪个数字最低”。测速条件没有固定，结果就只能作为当时参考，不能写成全天性能保证。
常见问题
network speed test 节点测速只测 Ping 可以吗？
不建议。Ping 通常不经过 HTTP 或 SOCKS 代理，只能提供 ICMP 路径线索；应固定一个节点，再用客户端延迟测试、curl 代理请求或浏览器实际访问复测。
为什么客户端显示 50ms，网页打开却很慢？
客户端延迟测试通常只请求指定探测地址，网页还会受到 DNS、TLS、服务器处理、CDN 命中、页面资源数量和节点负载影响。应查看 HTTP 首字节和完整页面或文件请求结果。
TUN 模式下可以直接 Ping 节点吗？
不建议把 TUN 下的 Ping 当成节点延迟。TUN 会接管系统流量，虚拟网卡、DNS 和 fake-IP 配置可能改变观测路径；更可靠的做法是用客户端内置测试或显式指定本地代理端口的 curl。
Windows PowerShell 为什么 curl 命令报错？
Windows PowerShell 5.1 中，curl 可能是 Invoke-WebRequest 的别名。请使用 curl.exe，并把示例中的代理地址、端口和测试文件替换成实际值。
测速文件必须支持 Range 吗？
不必须。比较持续下载速度时，应使用足够大的文件做完整下载；只有做多线程、断点续传或分段读取时，才需要检查 Accept-Ranges 和 206 Partial Content。
怎样判断节点是真快还是只是某次结果好？
固定目标地址、文件、设备和代理端口，在至少两个时间段重复测试，记录首字节、完整下载、丢包和异常次数，再比较中位数与波动。单次最高速度只能代表当时结果。