平均延迟看起来正常，通话或连续操作却一阵顺畅、一阵停顿，值得检查的是波动发生在哪里。抖动与丢包可以提供线索，但工具上的红色数字并不自动说明业务连接损坏。先保存卡顿时的任务和时间，再理解测量结果，才能避免被单次探测误导。
将平均值之外的变化记下来
抖动通常用于描述分组传递延迟的变化，具体算法要看工具说明。不同工具可能使用不同采样和统计方式，不能直接比较两个同名数字。平均值接近，也可能分别对应持续平稳和偶尔长时间等待这两种状态。
记录一次正常操作和一次异常操作的发生条件，标出停顿是否成串出现、是否与上传文件或切换房间同时发生。没有支持数据时，写“操作等待明显增加”即可，不需要自行估算毫秒数。真实任务的表现是这份记录的起点。
区分数据丢失与探测未回应
探测工具只能统计它发送的测试及收到的回应。对端不接受某类探测、对回应限频，或回程存在问题，都可能表现为没有回应。某个中间路由节点显示缺失，不能直接认定所有经过它的业务数据都被丢弃。
先观察最终目标和实际应用是否也在同一时段异常。如果只有路径中一行数字难看，而后续目标与任务正常，应保留这个差异，不急着向该节点归责。探测方法与业务传输方式不同，结果需要放回各自范围解释。
先观察本地负载和无线连接
检查自己是否同时执行云盘同步、系统更新或文件传输。暂停可以安全暂停的后台任务，保持目标和节点不变，再重复一次日常操作。若卡顿明显减少，说明负载与现象有关，但还不能仅凭这一轮判断具体设备或线路故障。
无线连接可以再对照同一位置的正常时段，或在允许条件下改用有线连接。每次只改变一个因素；同时移动位置、换节点又重启软件，就很难解释结果。共享网络中的其他人也可能正在传输，排查前先了解实际使用情况。
围绕短时间窗口做有限观察
- 确定一个可以重复、不会造成重要提交的操作。
- 固定设备、网络、出口与工具的探测方式。
- 记下卡顿开始与结束时间，并保存同一窗口的结果。
- 在没有卡顿时做一次同条件对照。
- 已有一致线索后停止重复，避免测试本身制造负载。
不要把长时间后台探测中的所有缺失相加，再称为某次应用的丢包率。它们可能跨越休眠、切网和目标维护。需要统计比例时，至少保留采样对象、数量、时间和工具方法，否则百分比缺少可解释的范围。
用任务结果判断下一步
若普通联网和代理任务一起波动，优先检查共同的接入环节。若普通访问正常，而某一出口对应的任务持续异常，可以把该出口列为进一步核查对象。若只有一项实时业务受影响，则继续查该业务的连接方式与支持说明。
例如，假设上传资料时网页操作频繁等待，暂停上传后恢复，这支持安排上传与交互任务的时间，并检查共享带宽；它并不直接证明机场在限速。把观察和原因推断分成两句话，能避免后续换一个环境就推翻整份记录。
提交能复现的问题，而非单张排名图
提供发生时间、接入方式、任务、出口以及正常与异常对照，说明工具显示的是哪一种探测。中间节点地址、设备标识和无关账号信息可先脱敏。没有抓包经验时，不必为了求助收集整段私人通信。
处理后重做原任务，确认卡顿是否减少，并恢复不必要的临时设置。一次改善是当前条件下的结果，不是长期稳定性证明。若证据仍不足，保留未知项交给负责对应环节的人继续检查。
继续阅读：延迟与实际速度的区别；家庭与移动网络对照。