Network Speed Test 怎么测才准确？节点测速与连接排查指南
简答：想马上测速，可先打开 Cloudflare Speed Test 或 FAST.com；如果要判断某个客户端节点是否真的生效，应固定测速服务器，分别测试直连与客户端连接，并确认测速流量命中目标节点，而不是只看客户端里的 URL Test 延迟。
定义：Network speed test 是对当前设备到指定测速服务器之间的下载、上传、延迟、抖动和丢包进行测量，用来判断网络吞吐与连接稳定性。
一、先用可访问的测速工具开始测试
如果你的目标是马上完成 network speed test，可以先使用下面两个浏览器工具：
- Cloudflare Speed Test：打开 Cloudflare 网络测速。页面可显示下载、上传、延迟、抖动、丢包，以及空闲和负载状态下的延迟。Cloudflare 说明其测试运行在自己的网络中，结果主要反映设备到当前测试节点的表现。
- FAST.com：打开 FAST.com 网络测速。它通过 Netflix 服务器进行下载和上传测试，并可展开查看上传速度、空闲延迟与负载延迟。
测速前先确认测试会消耗流量。Cloudflare 页面提示，一次测试最多可能消耗约 200 MB；移动网络或流量有限时，不要连续反复运行大规模测速。测速工具的服务器、连接数和计算方法不同，所以不同平台的结果不应直接当作同一组数据排名。
最简单的首次测试顺序是：关闭无关下载和云同步，打开 Cloudflare Speed Test，记录下载、上传、延迟、抖动、丢包和服务器位置；再用 FAST.com 复测，并记录空闲延迟与负载延迟。查看 Cloudflare Speed Test 的测量说明；查看 FAST.com 的结果说明
二、准确测速的标准步骤
- 固定设备和接入方式。使用同一台 Windows、macOS、iOS 或 Android 设备。记录当前使用的是网线、Wi-Fi 还是移动网络；如果测试 Wi-Fi，尽量固定位置和频段。
- 暂停后台流量。暂时停止系统更新、云盘同步、文件下载、在线视频和其他会占用上行或下行带宽的任务。否则测速结果反映的是“共享带宽后的剩余速度”。
- 先测本地基础网络。关闭客户端或保持直连状态，用 Cloudflare 和 FAST.com 各测试一次，记录时间、测速工具和结果。此组结果用于判断本地网络基线。
- 保持同一个测速服务器或同一工具。比较节点时，优先使用同一个测速工具；如果工具允许选择服务器，尽量让不同节点使用相同或相近的服务器。测速服务器不同，网络路径也会不同。
- 重复测试而不是只看最高值。在相近时间连续测试 2 至 3 次，记录结果范围。重点观察是否持续稳定，而不是挑选一次最高下载速度。
- 分别观察空闲和负载状态。如果下载开始后延迟明显升高，说明网络在高负载时的交互质量可能变差。远程桌面、语音、视频会议和在线协作通常不能只看峰值下载速度。
- 记录实际业务表现。同时记下网页打开、文件上传、远程办公、视频会议或连接中断等现象。测速数据只能说明到测试目标的表现，不能保证所有业务目标都相同。
建议使用下面的记录格式：时间｜设备｜接入方式｜客户端状态｜测速工具｜服务器位置｜下载｜上传｜延迟｜抖动｜丢包｜实际问题。有了完整记录，后续才容易区分本地网络、客户端规则和目标节点路径的问题。
三、使用客户端测速时，先确认流量真的经过目标节点
本站是第三方使用指南站，不是「Bocchi Network」官方。使用 Clash Verge Rev、Mihomo、sing-box 或 v2rayN 测试节点时，最常见的误判是：客户端看起来已经连接，但浏览器测速域名实际上被规则分流为直连，测到的只是本地网络。
- 先选定一个目标节点。不要在测速过程中同时开启自动选择、负载均衡或多个策略组切换，否则无法判断结果对应哪条路径。
- 测试前暂时切换到全局模式。在 Clash Verge Rev 等客户端中，全局模式的含义是将流量交给代理节点处理；规则模式则会根据规则决定直连或代理。界面名称可能因版本不同而变化，选择前以客户端当前显示为准。Clash Verge Rev 的界面配置中明确区分了规则、全局和直连模式。查看 Clash Verge Rev 的模式说明
- 如果使用 TUN，确认 TUN 已启用且没有排除浏览器流量。TUN、系统代理、规则模式和 DNS 设置是不同层面的配置；开启 TUN 不代表每个目标都会自动走同一个节点。先确认客户端状态正常，再进行测速。
- 打开测速页面并核对出口信息。Cloudflare 测速页面会显示当前连接使用的 IP、网络或 ASN 等信息。对比直连和客户端连接时，至少要确认出口信息发生了符合预期的变化；如果出口信息没有变化，先不要把测速结果归因于目标节点。
- 再切回规则模式复测。如果全局模式和规则模式的结果差异很大，说明测速域名可能命中了不同的路由。此时查看客户端连接记录或规则命中情况，确认测速域名是代理还是直连。
- 一次只改变一个变量。不要同时修改 DNS、MTU、TUN、节点和规则。建议按“直连基线 → 全局模式 → 规则模式 → TUN 模式”的顺序逐项测试。
v2rayN 的说明也区分了系统代理和核心路由：系统代理负责把部分应用交给本地代理入口，核心路由再依据规则决定出站方向。因此，浏览器能打开页面，并不能单独证明测速流量经过了目标节点。查看 v2rayN 系统代理与路由说明
如果你无法确认客户端是否接管浏览器流量，优先用浏览器测速页面显示的出口信息、客户端连接日志和模式状态三项交叉核对，不要只看客户端托盘图标或流量曲线。
四、客户端延迟测试不等于真实网速
客户端中的 URL Test、延迟测试或节点测速，通常用于比较一次或多次 HTTP 请求的响应时间。它适合初步判断“哪个节点更快响应”，但不等于下载速度，也不能完整反映上传速度、持续吞吐、负载延迟、抖动和丢包。
| 测试方式 | 主要反映 | 不能直接说明 |
|---|---|---|
| 客户端 URL Test 或延迟测试 | 某个 URL 或探测目标的响应时间 | 持续下载速度、上传能力和完整业务稳定性 |
| Cloudflare Speed Test | 下载、上传、延迟、抖动、丢包及负载状态 | 所有网站或所有办公系统的实际速度 |
| FAST.com | 基于 Netflix 测试服务器的下载、上传和延迟表现 | 其他地区、其他运营商或其他应用的路径质量 |
| ping 或其他探测命令 | ICMP 回显的往返时间和回复情况 | 代理协议上的 TCP 或 UDP 吞吐表现 |
例如，节点 A 的 URL Test 延迟可能低于节点 B，但节点 A 在持续下载时出现高负载延迟或丢包；这时 A 不一定更适合远程办公。相反，某节点的单次延迟稍高，但吞吐和稳定性更好，也可能更适合文件传输或视频会议。
因此，节点选择建议分两步：先用客户端延迟测试剔除明显无响应的节点，再使用同一个浏览器测速工具对候选节点进行真实吞吐测试。两类结果应分别记录，不能把客户端显示的毫秒数直接当成宽带速度。
五、如何实测丢包、抖动和路径稳定性
浏览器测速页面不一定都提供可重复的丢包明细。需要进一步排查时，可以使用系统命令进行基础 ICMP 测试，再结合浏览器测速结果判断。Windows 的 ping 命令支持指定发送次数，并会显示往返时间和统计结果。查看 Microsoft 的 ping 命令说明
Windows
打开“命令提示符”，执行：
ping /n 100 example.com
将 example.com 替换为你要测试的域名或目标地址。测试结束后记录发送、接收、丢失数量以及最小、最大和平均延迟。若希望减少域名解析因素，也可以先解析出目标 IP，再对 IP 进行测试。
macOS 或 Linux
打开终端，执行：
ping -c 100 example.com
同样记录丢包比例和延迟波动。若需要观察多跳路径，可使用系统已有的路由诊断工具，或在确认来源可信的前提下使用 WinMTR、MTR 等工具；不要把某一跳不响应直接认定为最终目标丢包，因为中间设备可能只是限制 ICMP 响应。
重要限制：ping 测到的是 ICMP 表现。经代理或 TUN 后，ICMP 可能直连、被客户端特殊处理，或根本不支持通过当前协议转发。v2rayN 的界面说明也指出，TUN 下的 ICMP 路由策略与核心类型有关，不能简单用 ping 结果代表所有 TCP、UDP 或浏览器流量。查看 v2rayN TUN 与 ICMP 路由说明
因此，判断节点是否适合实际使用时，应同时看三类证据：浏览器测速的吞吐和负载延迟、ping 的基础稳定性、以及实际应用是否出现卡顿或重连。ping 不通不一定表示浏览器连接不可用；浏览器测速正常，也不代表所有实时业务都没有丢包。
六、测速结果异常时的排查顺序
| 现象 | 优先排查 | 下一步 |
|---|---|---|
| 直连和所有节点都慢 | Wi-Fi、网线、路由器、后台流量、设备负载 | 暂停同步和下载后复测，再比较有线与无线 |
| 只有一个节点慢 | 该节点配置、目标路径或临时拥塞 | 固定测速工具，换两个时间段复测 |
| 客户端延迟低但下载慢 | URL Test 与真实吞吐的差异 | 用 Cloudflare 或 FAST.com 做持续下载测试 |
| 下载速度高但会议卡顿 | 抖动、丢包、负载延迟 | 测试空闲与负载延迟，再做 ping 记录 |
| 规则模式慢、全局模式正常 | 测速域名被直连或命中不同规则 | 查看规则命中和出口 IP，再决定是否调整规则 |
| 测速失败但网页能打开 | 测速服务器、浏览器、DNS 或客户端分流 | 更换另一个测速工具，并核对客户端连接日志 |
排查 DNS、MTU 或 TUN 时，建议不要一次修改多项配置。先保存当前配置，再只改变一个设置并重复同一组测速。若修改后结果变化，要保留修改前后的时间、模式、节点和测速数据，方便恢复或继续定位。
七、适合保存的节点测速记录表
比较不同节点时，可以复制下面字段：
- 基础条件：日期和时间、设备系统、网线或 Wi-Fi、网络运营商或接入方式。
- 客户端条件：客户端名称、规则或全局模式、是否启用 TUN、目标节点、DNS 设置是否改变。
- 测速条件：工具名称、测速服务器或服务器位置、是否暂停后台流量。
- 结果：下载、上传、空闲延迟、负载延迟、抖动、丢包、出口 IP 或 ASN 是否符合预期。
- 实际体验：网页响应、文件上传、远程桌面、视频会议、连接中断和重连次数。
最终选择节点时，不建议只按下载速度排序。对跨境办公或长期连接，稳定性、负载延迟、丢包和实际业务表现通常比一次峰值速度更有参考价值；但具体取舍仍取决于你的目标地区、应用类型和可接受等待时间。
常见问题
Network speed test 现在可以直接用什么工具？
可以先打开 Cloudflare Speed Test 或 FAST.com。前者可查看下载、上传、延迟、抖动、丢包和负载状态，后者可查看基于 Netflix 服务器的下载、上传及空闲或负载延迟。比较节点时应固定使用同一个工具。
为什么客户端显示延迟很低，但实际下载仍然很慢？
客户端 URL Test 或延迟测试主要反映探测请求的响应时间，不等于持续下载速度，也不反映上传、抖动、丢包和负载延迟。应在同一客户端状态下使用浏览器测速工具复测真实吞吐。
如何确认测速流量真的经过目标节点？
先固定目标节点，暂时切换到全局模式或确认规则命中代理，再打开测速页面，核对页面显示的出口 IP、网络或 ASN，并查看客户端连接记录。之后切回规则模式复测，比较两组结果。
规则模式下测速结果为什么可能只是本地网络？
规则模式会根据规则决定直连或代理，测速域名可能被分流为直连。此时浏览器虽然测速成功，但测到的是本地网络到测速服务器的路径，而不是目标节点路径。
Windows 怎么测试 100 次延迟和丢包？
打开命令提示符，执行 <code>ping /n 100 example.com</code>，将域名替换为目标域名或地址。结束后记录发送、接收、丢失数量以及最小、最大和平均延迟。
macOS 或 Linux 怎么测试 100 次？
打开终端，执行 <code>ping -c 100 example.com</code>。需要注意，ping 测的是 ICMP，不一定等于浏览器使用的 TCP 或客户端实际代理流量；因此应结合浏览器测速和实际业务表现判断。
ping 不通是不是说明节点一定失效？
不一定。ICMP 可能被目标服务器、网络设备或客户端的 TUN 路由策略限制。ping 不通时，应改用浏览器测速、连接日志和实际业务访问进行交叉验证。