测速延迟很低就可信吗？先认清测试对象，再核对丢包与样本

节点旁边显示 20 ms，打开网页却要等很久，未必是两项结果互相矛盾。它们可能测量不同目标、不同协议，或者走了不同路径。星航指南建议先把“这个数字代表什么”写清楚，再谈是否可信。

一、延迟：同样写 ms，也可能不是同一指标

Windows 的 ping 使用 ICMP 回显并显示往返时间，可查 Microsoft 的 ping 说明。客户端里的 TCP 建连耗时、HTTP 请求耗时则是其他测量过程；要看工具定义，不能仅凭“延迟”两个字合并排名。

常见结果	可以先检查什么	不能直接推出什么
节点入口响应很快	本机到入口的探测方法	出口到所有网站都很快
浏览器测速响应很快	浏览器访问的目标与连接路径	游戏、其他应用也走同样路径
ping 返回很快	ICMP 目标及本机路由	代理中的 HTTP 请求一定快

只设置系统 HTTP 代理时，不能默认命令行 ICMP 也经过代理；启用其他网络接管模式时，仍需看实际规则。可对照客户端连接记录，确认测速任务是否经过选定节点。无法确认路径，就注明这一限制。

还要分清空闲与有负载的延迟。Cloudflare 的官方方法说明把网络空闲和传输中的往返测量分开，见测速方法介绍。不要用一份报告的空闲延迟，对比另一份的上传负载延迟。

二、丢包：先分清“没回应”和“功能没测成”

例如发送 200 个探测包，有 2 个在设定等待时间内没有回应，本轮未回应比例就是 1%。这只是这批探测的结果，不能直接称为所有业务流量的丢包率。

如果目标不回应 ICMP，或者工具的丢包测试未建立成功，应记录“此方法无法判断”，而不是“线路 100% 丢包”或“零丢包”。可以换用目标支持的检测方式，并结合实际网页或应用任务复查。

三、测试时段：把不同时候的低延迟分开存

保留完整日期、时区、开始结束时间，至少补一次你真正使用网络的窗口。若白天结果与晚上差异明显，分别写出，不要只留下更低的数字。

对比两个节点时，尽量在同一窗口交替测试，保持目标和方法一致。不要先把一个节点测完半小时，再把另一个节点的结果当作严格的同时对照。

四、样本：一次绿灯，只是一次观察

新手可先安排同一窗口 3 轮，每轮使用相同的低频探测设置；以后在另一时段和另一日期复查。3 轮是起步安排，不是认证可信度的门槛。失败轮次也留下，并记录错误提示。

延迟统计若只包括成功返回的请求，应同时标出成功数与超时数。不能删掉超时后，仅凭剩余请求的低平均延迟宣布稳定。样本数量本身也是报告的重要信息，参见 RFC 6703 第 8 节。

留下这张记录表，再解释数字

项目	自己填写
日期、时区、时间范围	待填
设备、网络、工具版本	待填
目标、探测方法、是否确认经过节点	待填
空闲或负载状态	待填
发送、回应、超时数量与等待时间	待填
延迟统计、轮次、实际任务结果	待填

可接受的结论是“在这些条件和时段下，几轮表现较接近”；超出记录覆盖的设备、网站和日期，继续保留未知。本文没有对具体线路进行实测，资料核对于 2026 年 10 月 25 日。