如何记录一个节点连续7天的速度变化？

“这个节点晚上慢”是一个感觉，“这个节点在连续七天里，每天晚高峰的下载速度都比午间低三成”才是一个可以讨论的观察。把前者变成后者，需要的不是更好的工具，而是一份认真的记录。

先定计划

• 选一两个节点。节点太多会做不完，也容易半途而废。
• 选测试时间。完整做法是本站的五个窗口：早间 07:00–09:00、午间 12:00–14:00、晚间 18:00–20:00、晚高峰 20:00–23:00、深夜 00:00–02:00，七天共 35 次。如果觉得太多，至少做午间、晚高峰和深夜三个窗口，共 21 次。
• 固定具体时刻。例如每天 08:00、13:00、19:00、21:30、01:00，不要今天 20:05、明天 22:40 地随意变动。
• 覆盖周末。工作日和周末的用网习惯不同，七天里应该包含周六和周日。

每次测什么

每次测试做同样的几件事：空载延迟（每轮约 10 次属于快速检查，记录范围；要正式比较窗口之间的差别，按本站口径至少 30 次有效样本并注明样本数，见测试次数的口径）；一次网页测速，记录下载、上传以及下载和上传时的负载延迟；如果测速工具给出抖动和丢包，一并记录，测不出的写“未测得”。如果想观察视频播放，可以再加一次 YouTube 的详细统计信息，见YouTube Stats for nerds 教程。

记录表格

用电子表格，每次测试一行。建议的列如下，列名和本站的测试记录 CSV 保持一致，以后可以放在一起比较：

test_datetime,time_window,node_name,client,network_note,download_mbps,upload_mbps,idle_latency_ms,loaded_download_latency_ms,loaded_upload_latency_ms,jitter_ms,packet_loss_percent,notes

没有测到的单元格留空，不要填 0。时间用北京时间，精确到分钟。

保存证据

每次测试截一张图，让测速结果和系统时间出现在同一张图里。文件名用“日期-时刻-节点-项目”的格式，例如 20261028-2130-节点名-测速.png。截图前遮盖订阅链接、令牌、账号和其他个人信息，不要裁掉时间。证据比数字更重要：没有原图的记录，别人没法核验，本站也会把它标为“未核验”。

七天之后怎么整理

整理时可以对照分时段节点测试里的五个时间段划分，把每天的记录按时段归类。

1. 按窗口分组：把七天里同一个窗口的数据放在一起，而不是把所有数据混着取平均。
2. 每个窗口记录中位数和范围（最小值到最大值）。
3. 并排比较窗口：晚高峰的下载是否明显低于午间？延迟和抖动是否同步升高？
4. 同一窗口里先看不同日期之间的一致性：如果只有一天特别差，更可能是偶然，而不是规律。
5. 本站画趋势线的规则是同一节点、同一窗口至少三个不同日期，你也可以沿用这个标准。已有的记录和空窗口见分时段节点测试。

一个计算示例——教学示例（假设数据，仅用于教学）

假设某个节点七天里午间下载速度（Mbps）是 82、79、85、80、76、88、81，晚高峰是 55、60、52、58、63、49、57。排序后取中间一个：午间中位数 81，晚高峰中位数 57。晚高峰相对午间的变化是 (57 − 81) ÷ 81 ≈ −29.6%，大约低三成。再看范围：午间 76–88，晚高峰 49–63，两者没有重叠，说明这个差别不是某一天的偶然，更像是规律。如果两个范围大幅重叠，就不该下“晚高峰更慢”的结论。这组数字是教学示例，只用来说明算法，不对应任何真实机场、节点或线路。

常见偏差

• 测试时间每天漂移，导致窗口里混进别的时段。
• 其他设备在同一时间占用带宽。
• 客户端自动切换了节点，测的其实不是同一个。
• 中途换了测速服务器、客户端版本或测试地址。
• 只保留好看的结果，删掉了异常值。

一个具体的七天计划

以三窗口方案为例，每天在午间 13:00、晚高峰 21:30、深夜 01:00 各测一轮，连续七天。每轮包含约 10 次空载延迟（快速检查口径）、一次网页测速和一次国内对照；测完立刻填表、存截图，不要攒到第二天补。如果某个时刻因故错过，在表里写“缺测”并说明原因，而不是用相邻时刻的数据代替。如果这一周里发生了停电、路由器重启或客户端升级，也要在备注里写清楚，事后分析时才不会被它们误导。