晚高峰测速结果可信吗？把延迟、丢包和跨时段样本放在一起看

一份报告写着“晚高峰稳定”，却只有一张截图，应该先找测试时间与轮次。可信度来自证据覆盖了多少实际使用条件，而不只来自那一轮的峰值速度。

本站已有晚间测试记录教程；这次专门讨论：哪些材料足以支持结论，哪些信息缺失时应保留判断。

一、测试时段：没有适用于所有人的固定高峰

把自己的常用时间作为重点。例如白天选一个窗口，晚上在北京时间 20:00—23:00 内选一个窗口，并在其他日期复查。这只是安排示例，各地区、线路和用户群的忙闲时间可能不同。

必须写实际测试日期与时区，不能用文章发布日期代替。不同日期的数据按行保存，再比较白天和晚间；不要把所有结果合成一个没有时段标签的“平均表现”。

同一个节点名称不足以保证测试可比。还应固定测速目标、工具、探测方法和 IP 版本，记录是否确认经过选定节点。目标变化或自动切换，应单列结果。

空闲时的延迟与上传、下载进行中的延迟分别记录。FAST.com 的官方说明也区分 unloaded 与 loaded 两类延迟。两种状态可以帮助观察不同问题，但不能互换着比较。

典型延迟与慢响应都要看。工具若提供 P95，它大致描述较慢一端的延迟水平；同时注明统计是否只包含成功响应、采用什么计算方法。若没有此数据，就不自行填入。

假设某晚三轮各发送 100 个探测包，未回应数分别为 0、0、9。这是虚构示例：合起来是 9/300＝3%，但只写总比例，会遗漏异常集中发生在第三轮这一事实。

保留每轮的发送数、未回应数、超时设置和时间范围。如果丢包功能没运行成功，填“未测得”。如果只测试 HTTP 请求成功率，则单独命名为请求失败率；不能与探测包丢失比例混写。

可从两个日期、白天与常用晚间各一个窗口、每窗口 3 轮开始。每轮采用相同的低频探测设置并记下发包数。这个安排是家庭比较的起点，不是证明“长期稳定”的标准样本量。

轮次应在测试前安排，失败后可以补测，但失败记录仍保留。持续探测中的相邻样本可能受同一阵拥堵影响；不能只凭发包数量巨大，就宣称观察覆盖充分。RFC 6703也把测试流特征与样本数量列为报告的重要内容。

补充自己的视频、通话或网页任务时，也保留成功和失败次数。下载跑分与任务体验是两类证据，互相补充才有用。

执行时可配合本站晚高峰测试记录表。本文没有实测具体服务，演示数字不构成线路评级；资料核对于 2026 年 10 月 25 日。