节点测速怎么测才有用：别只看 Ping，按 4 层判断节点质量
简答：节点测速不要只执行一次 Ping。正确做法是先测节点入口是否能建立连接，再用客户端或带代理参数的 curl 验证经节点访问，最后在相同测速点连续观察延迟、丢包、抖动和下载速度；否则测到的可能只是本地直连网络。
定义：节点测速是对节点入口、经节点访问目标以及实际传输能力分别进行检测，用于区分入口响应、代理转发、应用层连通性和持续吞吐，而不是单看一个 Ping 数字。
先看 30 秒速查卡：你到底要测哪一层
测速显示 50ms 却打不开网页？先确认测到的是谁。Windows 的 ping、tracert 和不带代理参数的 curl 默认走本机网络路径，不会因为客户端开启了系统代理就自动变成“经节点测速”。
| 要回答的问题 | 建议方法 | 结果用途 |
|---|---|---|
| 节点服务器入口是否能连接 | Test-NetConnection 节点地址 -Port 节点端口 | 判断 TCP 入口是否能建立 |
| 经节点访问是否生效 | 客户端切换全局模式，查看出口 IP；或使用 curl -x | 确认测试流量真的经过节点 |
| 网页或目标服务能否访问 | curl -x 代理地址 -I https://目标域名 | 判断 HTTP/HTTPS 应用层连通性 |
| 实时体验是否稳定 | 连续观察 20 次延迟、丢包和波动 | 避免只看最低延迟 |
| 持续传输能有多快 | 固定同一测速点连续测试 3 次 | 判断视频、文件和同步场景 |
本文以 Windows 命令和常见桌面客户端为例；macOS 可使用终端中的 ping、traceroute、curl，iOS 和 Android 更适合使用客户端内置延迟测试、连接面板和实际网页或视频复测。不同客户端的菜单名称和本地端口以设置页显示为准。
本站是第三方使用指南站，不是任何客户端或节点服务的官方网站。提交节点链接前，请先确认工具是否会上传、解析或保存订阅信息。
节点测速的正确流程：先测入口，再测经节点效果
- 固定测试条件：暂停云盘同步、下载和视频播放，记录设备、网络类型、客户端、系统代理、TUN 和 DNS 状态。Wi-Fi、后台流量和测速服务器都会影响结果。
- 测节点入口：准备节点服务器地址和端口后，在 PowerShell 执行
Test-NetConnection node.example.com -Port 443。把域名和端口替换成节点实际信息，重点看TcpTestSucceeded。Microsoft 文档说明，该命令可用于 ICMP、TCP 端口和路由诊断，具体参数以当前 PowerShell 版本为准，可查看 Microsoft Learn 的 Test-NetConnection 文档。 - 不要把入口测试当成节点体验：
Test-NetConnection只说明本机到节点入口的 TCP 连接情况，不代表节点转发到目标网站后的延迟、丢包和下载速度。若节点协议不是 TCP，不能用 TCP 端口结果直接代表 UDP 或 QUIC 的应用质量。 - 验证经节点访问：如果客户端提供本地 HTTP 代理端口，例如
127.0.0.1:7890，可执行curl.exe -x http://127.0.0.1:7890 -I https://example.com。如果本地端口是 SOCKS5，可执行curl.exe -x socks5h://127.0.0.1:7891 -I https://example.com。curl 官方文档说明，-x或--proxy用于指定代理，socks5h会让主机名解析交给 SOCKS 代理处理，端口和代理类型需要与客户端设置一致，详见 curl 官方命令手册。 - 确认出口和命中节点：在客户端连接面板确认当前选中的节点和规则；临时切换到全局模式，再打开一个出口 IP 查询页面，记录显示的出口地区或地址。关闭客户端代理后重复一次，若两次出口结果一致，说明浏览器流量可能没有经过节点，需要检查系统代理、浏览器独立代理或规则模式。
- 做实际吞吐复测：保持同一节点、同一测速点和同一客户端状态，连续测速 3 次，记录下载、上传、延迟和测试服务器区域。M-Lab 的 NDT7 文档将下载、上传和延迟作为测量结果，但测试路径和服务器位置仍会影响读数，不能把某一次结果当成所有应用的长期速度，可参考 M-Lab NDT7 协议说明。
最小判断逻辑是：入口失败，先查节点地址、端口和本地网络；入口成功但经节点 HTTP 失败，查客户端代理端口、规则和 DNS；经节点可访问但速度低，再看丢包、抖动、时段和测速点。
TUN 与 fake-ip 开启时，为什么 Ping 结果可能失真
如果客户端启用了 TUN 和 fake-ip，不要直接对客户端解析出的地址执行 Ping。Mihomo DNS 文档示例中的 fake-ip 地址池为 198.18.0.1/16；域名可能被映射为这一段中的虚拟地址，相关配置可查看 Mihomo DNS 配置文档。
- 在命令行执行
nslookup example.com或Resolve-DnsName example.com。 - 如果返回地址落在
198.18.x.x，先记录当前 fake-ip 状态，不要把对该地址的 Ping 延迟当成真实节点延迟。 - 临时关闭 TUN 或将该域名加入客户端的 fake-ip 排除列表，再重新解析。
- 用客户端的延迟测试、带代理的
curl -x，以及实际网页访问复核。
出现接近 0ms 的结果时尤其要检查目标地址是否属于 fake-ip 地址池。假地址由本地内核或客户端接管时，Ping 可能只反映本地映射响应，并没有完成到目标服务或节点出口的真实往返。
Ping、节点入口、经节点访问和实际下载不是同一种测速
| 测速口径 | 实际测量对象 | 适合判断 | 不能直接推出什么 |
|---|---|---|---|
| 本地 Ping 目标域名 | 本机到目标地址的 ICMP 往返 | 本地直连延迟和粗略丢包 | 不能证明经过节点，也不能证明网页可用 |
| 节点入口测试 | 本机到节点服务器地址和端口 | 入口 TCP 是否可建立 | 不能代表节点转发后的下载速度 |
| 经节点 HTTP/HTTPS 测试 | 本机通过本地代理到目标网站 | 代理端口、规则和目标网站连通性 | 不能代表其他网站或其他协议 |
| 节点出口测试 | 经节点访问出口 IP 或地区查询服务 | 确认流量是否经过节点及出口变化 | 不能单独代表速度或稳定性 |
| 实际下载测速 | 经节点到具体测速服务器的持续传输 | 下载、上传和长连接表现 | 不能代表所有应用的速度 |
节点测速不等于本地宽带测速，也不等于套餐标称带宽。建议先关闭客户端代理，对同一测速点测一次本地基线，再开启节点、确认出口变化后测第二次。两次结果的差异只能说明在当前设备、网络、节点和测速服务器组合下的表现，不能直接推断其他时间或其他网站的结果。
如果使用浏览器测速，必须先在客户端连接面板确认浏览器流量命中了目标节点；如果系统代理未生效，测速站显示的仍可能是本地网络。浏览器开发者工具还可以查看 DNS、请求开始、响应开始和资源完成等时间点，但它记录的是网页资源加载过程，不是通用节点评分，相关定义可参考 MDN Resource Timing 文档。
延迟、丢包和抖动怎么计算与解读
不要只按最低 Ping 排序。最低值可能只是一次偶然响应，连续样本的平均值、最大值、丢包和波动更适合判断实际使用。
- 延迟：可用
ping -n 20 example.com取得 20 次样本。该命令测的是 ICMP 路径；如果目标限制 ICMP，结果可能无法代表网页连接。 - 丢包：记录超时次数并计算“超时次数 ÷ 总次数”。如果节点用于实时通信，持续丢包通常比单次高延迟更值得优先排查；但应结合 TCP/HTTP 和客户端实际连接复核。
- 抖动近似值：可用“最大延迟 − 最小延迟”作为快速波动范围；也可以计算相邻样本延迟差值的平均值。它们是简化指标，不等同于所有客户端或运营商的正式抖动算法。
- 速度：至少连续测 3 次，记录下载、上传、测试点和时间。M-Lab 文档说明 NDT7 会记录吞吐和延迟，但不同测速服务的连接数、服务器位置和实现可能不同。
按场景判断时，可以采用相对排序规则：游戏先剔除存在持续丢包或明显波动的节点，再比较延迟和抖动；视频先看持续下载和长时间缓冲，再看入口延迟；视频会议同时看上行、下行、双向延迟和波动；网页则重点看 HTTPS 建连、DNS 等待和偶发超时。这里是比较方法，不是固定数值承诺。
测试失败、Ping 不通或速度忽高忽低时怎么排查
- 所有节点都无法经节点访问：关闭 TUN 和系统代理后确认普通网站可访问，再检查客户端本地 HTTP/SOCKS 端口是否与
curl -x命令一致。 - 入口端口失败：确认节点地址、端口和协议字段；用
Test-NetConnection 节点地址 -Port 端口复核。不要把 Ping 不通直接等同于 TCP 端口不可用。 - 客户端有延迟，网页打不开：延迟测试可能只验证入口或探测接口。检查规则是否把目标域名分流为直连，查看客户端日志，再用带代理参数的
curl验证。 - Ping 显示近 0ms：检查是否开启 fake-ip，尤其看解析结果是否属于
198.18.0.0/16；关闭 TUN 或排除该域名后重测。 - 浏览器测速很快但视频卡：确认视频流量命中的节点，观察播放期间的长时间下载、缓冲和客户端日志；测速服务器与视频服务可能不是同一条路径。
- 结果忽高忽低：停止后台下载，固定测速点，连续记录 3 至 5 次，并分别比较直连、系统代理和 TUN 状态。Windows 网络排查还可以参考 Microsoft Learn 的丢包诊断文档。
不要把完整订阅链接、节点分享链接、认证参数或包含密钥的日志直接提交给在线测速工具。优先使用本机客户端、PowerShell 和带代理参数的 curl；必须使用在线工具时，先核实数据是否上传和保存，并对日志做脱敏。
按使用场景保存测速记录，而不是制作一次性总榜
建议为每个节点建立以下记录：
- 时间：
2026-11-13 20:30 - 设备与网络：
Windows / Wi-Fi 5GHz - 客户端状态：
系统代理开启，TUN 关闭，fake-ip 未启用 - 节点标识：
节点 A，不要粘贴完整订阅链接 - 入口结果：
节点地址:端口，TcpTestSucceeded - 经节点结果：
出口 IP 已变化，curl HTTPS 返回状态 - 延迟与丢包：
20 次样本，平均值、最大值、超时次数 - 抖动近似值：
最大值 − 最小值 - 吞吐：
同一测速点连续 3 次下载与上传 - 场景体验：
网页、视频、游戏或会议的具体表现
比较时先剔除入口无法建立、经节点 HTTP 失败或持续超时的结果，再按具体场景观察延迟、抖动、丢包和吞吐。不要把不同设备、不同测速点、不同协议和不同测试时段的数字混成一张长期排名。
常见问题
节点测速应该看 Ping 还是下载速度？
两者都要看，但测量对象不同。Ping 更适合观察 ICMP 往返延迟，下载速度反映持续传输能力；网页和会议还要看 HTTPS 建连、上行、丢包与抖动。更重要的是先确认测试流量是否真的经过节点。
为什么 Ping 很低，实际网页却打不开？
可能测的是本地直连、节点入口，或 fake-ip 本地映射，而不是经节点访问目标网站。请用客户端确认命中节点，再执行带代理参数的 curl，例如 curl.exe -x http://127.0.0.1:7890/ -I https://example.com/。
Ping 不通是不是节点不能用？
不一定。Ping 使用 ICMP，目标或中间设备可能不回应。可以用 Test-NetConnection 检查节点端口，再用客户端连接和带代理的 HTTPS 请求复核；TCP/HTTP 也失败时，才更接近连接层问题。
开启 TUN 后为什么会出现接近 0ms 的延迟？
如果 DNS 返回的是 fake-ip 地址，例如 Mihomo 文档示例中的 198.18.0.0/16，Ping 可能只测到本地虚拟映射。检查解析结果，临时关闭 TUN 或排除该域名后，再用客户端延迟和经代理 HTTP 请求复测。
节点测速需要测试几次？
相同设备、网络、客户端和测速点下建议连续测试至少 3 次，并在另一个时段复测。延迟和丢包可以采集 20 次样本；不要只记录最低值。
浏览器测速很快，为什么视频仍然卡？
浏览器测速服务器和视频服务可能走不同路径，且短时吞吐不能暴露间歇丢包、抖动或高峰时段拥塞。确认视频流量命中节点，并在播放期间观察长时间下载、缓冲和客户端日志。
在线节点测速会不会泄露订阅信息？
存在这种可能，取决于工具是否接收、解析和保存完整链接。不要直接提交带认证参数的订阅地址；优先使用本机客户端、PowerShell 或带代理的 curl，并对日志和分享链接做脱敏。
相关阅读
参考资料
- Test-NetConnection (NetTCPIP) - Microsoft Learn
- Diagnose Packet Loss - Microsoft Learn
- curl - How To Use - 官方命令手册（curl.se）
- Mihomo DNS Configuration - fake-ip 配置说明
- ndt7 Protocol - Network Diagnostic Tool（measurementlab.net）
- developer.mozilla.org