为什么宣传数字不能直接信
同一台设备、同一条线路，换一个时段再测，数字可能差出一倍。测速结果至少受五个变量影响：本地宽带的实际出口、测试时段是否拥塞、测速服务器放在哪里、代理协议与加密带来的额外开销、以及客户端的分流规则有没有真的把测速流量送进代理。
宣传页上的数字通常取自条件最好的一组：就近的测速节点、空闲的时段、多线程聚合出来的峰值。它回答的是「这条链路在理想条件下能跑多快」，而不是「晚上九点打开视频会不会转圈」。自己测速的价值，在于把真实的使用条件固定下来，观察不同时段、不同线路之间的差异。
测速前先清场：暂停系统更新、网盘同步、其它设备上的视频与下载。同一网络里只要有一台设备在跑大流量，测出来的数字就会偏低，而且偏低多少无法估算。
测速工具怎么选：三层搭配各管一段
没有哪个工具能一次回答所有问题。按「先拿基线、再定位问题、最后回到真实场景」的顺序排三层，日常判断基本够用。
第一层：网页测速，先拿一个快速基线
Speedtest by Ookla、Fast.com、Cloudflare Speedtest 都属于这一类，打开就能出下行、上行与延迟。用法上只有一个要点：手动选定测速节点，并且每一轮对照都用同一个节点。自动推荐会随网络状况更换服务器，数字前后就没有可比性。
第二层：命令行工具，定位问题出在哪一段
ping 与 mtr 负责延迟、抖动和逐跳丢包；iperf3 负责裸吞吐与长时间稳定性；curl 的 -w 参数能把 DNS 解析、TCP 连接、TLS 握手、首字节四个阶段的耗时分别打印出来——「网页打开慢」到底慢在哪一步，一测便知。
# 延迟与抖动：连续 20 次 ping，重点看最大值与最小值的差距
ping -c 20 example.com
# 逐跳丢包：定位问题出在本地网络、国际出口还是对端
mtr -rwzbc 50 example.com
# 分阶段耗时：解析、连接、握手、首字节各花了多久
curl -o /dev/null -s -w "dns=%{time_namelookup}s connect=%{time_connect}s tls=%{time_appconnect}s ttfb=%{time_starttransfer}s\n" https://example.com第三层：真实场景测速
从常用的大文件源下载一次，或者看一段视频并记录缓冲次数。这一类没有漂亮的数字，却最接近日常体感。判断视频会不会卡，单线程结果比多线程聚合值更有参考价值。
多线程测速会把多条连接的速度加在一起，显示的数字通常高于单个应用实际能拿到的带宽。网页、视频流与单个下载任务多数是单线程或有限多连接，两组数字要分开看、分开记。
| 工具 | 主要测什么 | 适合的场景 | 注意点 |
|---|---|---|---|
| Speedtest（Ookla） | 下行、上行、延迟 | 快速基线、换线路前后的对照 | 手动锁定同一个测速节点 |
| Fast.com | 下行带宽与延迟 | 判断流媒体方向的带宽 | 不测上行，抖动与丢包要另测 |
| Cloudflare Speedtest | 带宽、延迟、抖动 | 快速看抖动 | 节点由对方网络决定，不能自选 |
| ping / mtr | 延迟、抖动、逐跳丢包 | 定位链路哪一段出问题 | 需要目标地址，ICMP 可能被限速 |
| iperf3 | 裸吞吐、长时间稳定性 | 自建节点、持续打流 | 需要两端配合，门槛偏高 |
| curl -w | 解析、连接、握手、首字节耗时 | 查「打开网页慢」卡在哪一步 | 命令行输出，需要理解各阶段含义 |
时段怎么排：闲时与晚高峰对照
至少取两个时段：一个是本地网络的闲时（工作日上午或下午），一个是晚高峰（20:00 到 23:00）。同一个节点、同一个工具，每个时段连续测三次，间隔一分钟以上，取中位数而不是峰值。周末的晚高峰通常比工作日更拥堵，想看得更准，可以再补一轮周末对照。
跨国访问还要把对方的时区算进去：你这边是深夜，对端可能正处在业务高峰。线路类型的差异在这个环节最明显——直连与中转线路要经过公网国际出口，晚高峰的波动更大；IEPL 专线走独立通道，不挤公网出口，闲时与高峰的数字通常更接近。这一组对照，比任何单次成绩都更能说明线路质量。
测速网站的服务器大多接在 CDN 边缘。如果测速域名命中了直连规则，你测到的其实是本地宽带到 CDN 的速度，和代理线路没有关系。测速前先确认分流规则，或临时切到全局模式。
三项指标：延迟、抖动与丢包怎么读
带宽数字最显眼，但决定体感的往往是另外三项。三者要连起来看，单独一个数字说明不了问题。
延迟（RTT）：看差值，不看绝对值
单位是毫秒。跨境访问的延迟天然高于本地访问，所以比较的重点是两个差值：与直连基线的差值（代理与线路引入的额外开销）、晚高峰与闲时的差值（链路是否拥塞）。如果同一条线路在晚高峰延迟明显放大、抖动同步上升，基本可以判断它走的是共享出口。
抖动（jitter）：实时音视频的生死线
抖动是相邻两次延迟的差值，反映链路稳不稳。语音通话、视频会议、竞技类游戏对它最敏感：平均延迟再低，抖动一大照样断续、卡顿。命令行里连续 ping 二十次，看最大值与最小值的差距，比看平均值有用得多。
丢包（loss）：最容易被忽略，影响却最直接
哪怕只有百分之几的丢包，TCP 也会反复重传，体感就是网页转圈、进度条不动。基于 QUIC 的协议（Hysteria2、TUIC）在丢包链路上比基于 TCP 的协议（Shadowsocks、VMess、Trojan、VLESS）更抗损，代价是更吃带宽，并且要求 UDP 转发质量过关。
DNS 解析是另一个容易漏掉的环节：如果客户端的 DNS 请求没有跟着代理走，可能被本地解析器解析到一条绕远的入口，表现为连接建立慢、首字节慢，而带宽测试完全看不出问题。用 curl 打印各阶段耗时，time_namelookup 明显偏大就是信号。
| 指标 | 单位 | 怎么测 | 数值变大意味着什么 |
|---|---|---|---|
| 延迟 RTT | 毫秒 | ping、mtr、测速网站 | 链路变长或拥塞，交互变慢 |
| 抖动 jitter | 毫秒 | 连续 ping 的最大值与最小值之差 | 实时音视频断续、卡顿 |
| 丢包 loss | 百分比 | mtr 逐跳统计、ping 统计 | 重传增加，下载与网页明显变慢 |
| 下行 / 上行带宽 | Mbps | Speedtest、iperf3、大文件下载 | 决定大文件与视频清晰度的上限 |
| DNS 解析耗时 | 毫秒 | curl -w 的 time_namelookup | 解析绕路，首屏与连接建立变慢 |
一套可复现的测速流程
下面的顺序把变量一个个固定住，照着做一遍大约半小时，得到的结果可以直接横向比较。
- 固定变量。同一台设备、同一个测速节点、同一条线路、同一个协议。任何一项换了，对照都要重新开始。
- 先清场。关掉后台下载、系统更新、网盘同步；有条件用网线代替 Wi-Fi，用 Wi-Fi 就固定在同一位置。
- 测直连基线。关闭代理，记录下行、上行、延迟、抖动、丢包。没有基线的数字没有参照物。
- 测线路表现。开启代理，确认测速域名走代理（全局模式，或把测速域名加入代理规则），连续测三次，间隔一分钟以上，取中位数。
- 换时段重复。闲时一轮、晚高峰一轮，分别记录，重点看两轮的差距有多大。
- 换线路对照。同地区的直连、中转、IEPL 专线各测一轮，只换线路，其它条件全部不动。
- 记录归档。按日期、时段、线路、协议、下行、上行、RTT、抖动、丢包九列记成一张表，一周后再看趋势。
流程里最容易省掉的是第三步和第七步：没有基线，就判断不出代理与线路引入了多少开销；不记趋势，就只能凭一次结果下结论。
结果解读：常见的几个误判
数字测出来之后，怎么读同样关键。下面这些判断方式，要么让结果失去可比性，要么把不同层面的问题混在一起。
- ❌ 拿单次峰值当稳定值：凌晨测到的高点，不代表晚高峰还能维持。
- ❌ 没确认分流规则就下结论：测速域名走了直连，两组数字测的根本不是同一条路径。
- ❌ 只测下行不测上行：视频会议、云盘上传、远程桌面吃的是上行带宽。
- ❌ 把测速节点的延迟当成网页打开速度：解析、握手、首字节每一步都会叠加，带宽再高也救不回来。
- ✅ 固定变量、重复三次取中位数，再看晚高峰相对闲时的下降幅度——这是唯一能横向比较的读法。
- ✅ 记录一周的趋势：线路质量是一个分布，不是一次成绩。
测速解决的不是「哪家最快」，而是「我的网络里最慢的是哪一段」。固定变量、对照时段、重复测量这三件事做到，宣传数字值不值得信、这条线路晚高峰顶不顶得住，你自己就能给出答案。
如果一轮测下来，瓶颈稳定出现在晚高峰的国际出口，而不是本地宽带或测速节点，那就是线路类型的问题，换一条不挤公网出口的线路，比反复测同一组数字更有意义。VPNEQ 提供 100+ 国家与 210+ 线路，按地区分组、多线冗余，Windows、macOS、iOS、Android、Linux 都能用，不限台数同时在线，可以作为你对照表里的一条参照线路。