先对齐四个概念
- 带宽与吞吐量
- 带宽描述可用容量，吞吐量描述实际传输的速率。测速结果受目标、拥塞和设备条件影响，不等于所有应用都能达到同样速率。
- 延迟
- 通信所需的时间。常见的ping显示往返时间，与单向时延不是同一个量；远近、路径和排队都会影响结果。
- 抖动
- 延迟随时间的变化。平均值看起来不高，单次响应却忽快忽慢，也可能影响实时交流。
- 丢包
- 在特定测量中没有收到预期的数据包或响应。它需要结合测试方式解释，不能只看一个百分比。
先建立一组可比较的观察
固定同一台设备、同一位置和同一个目标，在几个时间段重复测试。记录使用Wi-Fi还是网线，测试时是否有下载、云盘同步或视频播放。后台流量会竞争容量，负载期间的延迟可能与空闲时明显不同。
在条件允许时，对比普通网络状态与安易加速器连接后的同一任务。只有目标、时段和负载尽量一致，差异才具有参考意义。一次结果变好或变差，都不足以代表长期表现；不要据此发布固定的客户端测速成绩。
用ping观察连续响应，但保留判断边界
Windows可以通过下面的命令发送一组有限次数的测试请求：
ping -n 20 www.microsoft.com观察每次响应、最小和最大往返时间及未收到响应的次数。目标或中间网络可能限制ICMP，因此超时并不一定等于普通网页访问也有丢包。相反，ping正常也不能证明所有应用协议都正常。这个命令提供的是测试线索，不是对服务质量的最终认证。
如果需要区分无线接入与上游网络，可以在知道本机默认网关的前提下对网关进行同样观察。不要把网上示例的私有地址当作你家的固定网关，也不要向不属于自己的设备开展高频测试。
按现象安排下一步
- 只有大文件传输变慢：优先检查后台流量、可用容量与下载目标。
- 实时语音卡顿但普通下载正常：更值得观察延迟变化与连续性。
- 同一Wi-Fi下多台设备都波动：对比无线信号、路由器负载和上游网络。
- 只有一个应用异常：核对该应用与目标服务，避免对整个网络下结论。
若主要表现为首次打开域名时等待，而连接建立后较稳定，可以结合DNS解析检查。如果异常紧随接入网络切换出现，先阅读Wi-Fi与移动网络切换，确认新网络已经稳定。
记录比反复测速更有用
留下日期时段、网络类型、测试目标、后台负载和应用现象。对外说明问题时，用“同一任务在什么条件下出现了什么变化”，比“网络太慢”更具体。连续观察后再决定下一项调整，每次只改一个条件，并保留可以恢复的原设置。