客户端速度慢时，应区分延迟高、吞吐量低、网页首屏慢和实时应用卡顿。先建立直连或其他出口的同条件对照，再检查节点负载、目标限速、网络丢包和设备资源；一次测速不能说明长期质量，也不能直接证明协议优劣。
先定义你测的是什么
延迟是一次交互所需时间，吞吐量是单位时间传输的数据量，网页首屏还受 DNS、握手和多个资源请求影响。客户端的节点延迟列表不等于下载速度排行，视频卡顿也可能涉及缓存策略和目标平台。
记录客户端与核心版本、网络、时间、节点、模式及目标。路由器场景还需记录 CPU、内存和固件；不要仅留下一个 Mbps 数字。
建立最小对照
- 暂停系统更新、云盘同步和其他设备的大流量任务。
- 在同一设备与网络上，比较可以合法直连的测试目标和代理路径。
- 使用固定节点，保持测试目标一致，重复少量测试并记录范围。
- 再换一个节点，或只改变网络为手机热点，观察差异。
- 检查测试消耗及节点倍率，避免长时间自动测速耗尽套餐。
这些测试应在明确时间窗口完成。跨地区、跨运营商或跨日期的结果不能直接当成同条件排名。
常见瓶颈在哪里
晚间才慢可能涉及本地网络或服务端负载；单个网站慢可能是目标限速或出口路由；所有任务都慢且设备 CPU 很高，则需要检查核心、TUN 和设备能力。Wi-Fi 信号、信道拥堵和弱移动信号也会影响结果。
多个地区标签可能共享入口，所以换标签不一定改变瓶颈。自动策略组可能在测试期间切换节点，应固定出口再对照。
协议和配置的影响
UDP 不畅会影响基于 QUIC 的方案。高丢包下不同协议和拥塞控制可能表现不同，但带宽参数越大并不必然越快。DNS、规则和外部配置资源也可能影响首次访问。
MTU 问题有时表现为部分请求停顿，尤其在多层隧道中。没有对应症状或日志时，不要随机套用网上的固定 MTU 数值；先保留当前设置与回退方法。
给服务商的有效记录
提供测试时间、网络、节点、目标及多次结果范围，说明宽带和热点对照情况。不同测试工具应标出单位，Mbps 与 MB/s 不能直接比较。不要将一次大文件下载宣传为普遍带宽保证。