Roxi先决定你要测哪件事
| 目标 | 主要观察 | 常见误判 |
|---|---|---|
| 打开网页 | 首个响应、总耗时与错误 | 下载带宽高，网页一定快 |
| 视频和大文件 | 持续吞吐、重试和缓冲 | 节点列表延迟低，带宽就够 |
| 会议或实时语音 | 延迟、抖动与实际通话 | 只看下载速度 |
| 订阅和登录 | 能否完成指定请求 | 测速站能开，所有服务就正常 |
Mbps 是每秒百万比特，MB/s 是每秒百万字节，按十进制约相差 8 倍；还要扣除协议等开销。比如 80 Mbps 与约 10 MB/s 是单位换算示例，不是 Roxi 实测数据。TCP 端口延迟、HTTP 响应时间和游戏内延迟测的不是同一件事，不能放在一列直接排名。
先建立可比较的测试条件
- 固定设备、接入网络、客户端版本、路由模式与测试目标；暂停自己可控的大下载、备份和其他测速，记录是否使用蜂窝流量。
- 选择一个节点后，临时固定该策略组，避免自动选择或负载均衡在测试中换出口。测试结束恢复原设置。
- 使用客户端连接记录核对测速请求对应的出口和规则。浏览器扩展、分流和站点多域名请求可能让测速走了不同路径。
- 做直连基线时，明确关闭个人客户端接管，记录是否仍有路由器或企业网关代理。若直连目标不可达，就记为不可达，不写成“速度为零”。
公网测速会实际消耗下载和上传流量，也会看到出口 IP；打开某些测速页即开始传输。套餐有限或使用热点时先看其设置，控制测试次数，不在同一时间批量跑所有节点。
把吞吐与延迟记录在同一张表
Cloudflare 的测速说明区分吞吐、延迟和抖动。FAST.com 的“显示更多信息”提供上传以及空载、负载延迟：满载时延迟明显上升，可能解释“一下载就语音卡”，但不能单凭这个数确定是哪一段设备或线路拥塞。
| 轮次 | 接入网络 / 节点 | 同一目标的结果 | 备注 |
|---|---|---|---|
| 1 | 填写实际网络与节点 A | 下载、上传、延迟或任务耗时 | 时间、规则、出口是否一致 |
| 2 | 条件不变 | 填写实际测量值 | 有无后台流量或重试 |
| 3 | 条件不变 | 填写实际测量值 | 保留失败，不删除坏样本 |
三轮是一份便于复测的起点，不是精密统计。可报告中间值和最差一轮，并附上失败次数；不要只选最高跑分。对照节点 B 时沿用相同目标与测试方式，自动选出的测速服务器若变了，应记录变化，不能声称这是纯节点差异。
不跑大流量，也能测一次请求
下面在 Windows PowerShell 执行；macOS/Linux 把 curl.exe 换成 curl，把 NUL 换成 /dev/null。7890 要替换为本机实际 HTTP 或 mixed 端口。命令只下载 example.com 页面，衡量该次 HTTP 请求，不测带宽上限，也不修改系统配置。
curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 8 --max-time 20 -o NUL -sS -w "http=%{http_code} first=%{time_starttransfer}s total=%{time_total}s\n" https://example.comfirst 包含到首个字节为止的多项开销，total 是本次请求总耗时；HTTPS 经代理还包含代理交互和握手，不能把差值简单叫“节点 ping”。000 与超时应连同错误原文记录；403 等响应也不能当成一次成功的目标业务测试。
最后回到真实用途，并恢复设置
- 浏览用途测试一个新打开的实际页面；视频用途观察同一清晰度的短片；通话用途在同意的测试场景看连续体验。不要用真实付款来测连通。
- 晚高峰有问题时，在相近时段复测；家里 Wi-Fi 与蜂窝差异明显时再分别记录，不把不同条件的数值混在一起。
- 恢复原策略组和后台任务。选择能稳定完成用途的节点，留下备用，不凭一次峰值断言某个协议或地区永远最快。