延迟数据说明：我们测什么、没测什么
官网上的每个延迟数字都能在这里找到来源、样本量和局限。数据不好看的地方，我们也一并写出来。
更新于 2026-10-20 · 闪电豹加速器
先分清三种"延迟"
同一个"延迟"，在不同场景下指的是完全不同的东西。把它们混在一起，是最常见的误导来源。
| 指标 | 测的是什么 | 数值范围 | 能否代表游戏体验 |
|---|---|---|---|
| 入口 ICMP 延迟 | 你的电脑 → 加速器入口网关 | 约 5-60ms | 只能说明入口质量 |
| 隧道 RTT | 你的电脑 → 韩国出口 → 探测机 | 约 60-120ms | 较接近，但不含游戏服 |
| 游戏内延迟 | 你的电脑 → 游戏服务器（完整链路） | 通常高于隧道 RTT | 是最终指标 |
我们公布前两种，第三种只能由你在游戏里看到。
数据一：真实用户入口延迟
客户端在加速过程中会定期向服务端上报当前线路的延迟，服务端按「用户-日」聚合。 下面是 2026-03-03 至 2026-10-20 的全部有效样本： 315 位用户、8,233 条。
需要区分两个口径：平台累计在线 8.5 万小时（其中加速 7.2 万小时，2026-03 至今）； 本页延迟样本只来自 315 位上报过延迟的用户。样本用户数不等于总用户数，也不代表活跃用户。
| 指标 | 数值 |
|---|---|
| 中位数（P50） | 33ms |
| P75 | 44ms |
| P90 | 49ms |
| P95 | 51ms |
| 超过 50ms 的样本占比 | 6.3% |
| 超过 80ms 的样本占比 | 0.5% |
| 近 30 天中位数 | 37ms |
按运营商拆分
| 运营商 | 样本数 | 中位数 | P90 |
|---|---|---|---|
| 电信 | 5,283 | 36ms | 49ms |
| 移动 | 1,566 | 24ms | 43ms |
| 联通 | 1,258 | 23ms | 39ms |
| 其他 / 未知 | 126 | 42ms | 50ms |
这组数据的局限
- 只覆盖运行客户端并成功上报的用户，不代表所有玩家；
- 每用户每天只保留一条，没有按小时拆分，无法单独给出晚高峰表现；
- 是用户到入口网关的 ICMP 延迟，不含隧道和游戏服务器；
- 电信样本占约 64%，移动/联通样本较少，分运营商结论的置信度不同；
- 客户端自报，未做第三方独立测量；极端值（如 500ms 以上）未剔除，会略微拉高均值，所以我们用中位数和 P90 而不是平均值。
数据二：成都电信单点隧道 RTT
这组数据来自一台成都电信网络的测试机：客户端经网关向韩国探测机连续发送 80 个 UDP 包，统计往返时间与丢包。
| 线路 | 隧道 RTT | 丢包（80 包） |
|---|---|---|
| 韩国首尔主网关 | 70-90ms | 80 包丢 1 |
| 上海电信 UDP 出口 | 约 60-87ms | 80 包丢 0 |
| 首尔备用网关 | 约 100-119ms | 80 包丢 6 |
这组数据的局限更明显
- 单城市、单运营商：只有成都电信，不能代表联通、移动或其他城市；
- 短时样本：每条线路 80 个包，只能说明测试那一刻的状态，不是长期统计；
- 不是游戏内延迟：终点是探测机，不是游戏服务器；
- 没有分时段：没有单独测晚高峰，不能据此推断高峰表现。
所以我们在首页把 70-90ms 标成"成都单点"，而不是"平均延迟"。你所在地区的结果可能更好，也可能更差。
我们没做的事
- 没有多城市 × 多运营商的完整测试矩阵；
- 没有 7×24 小时、按小时聚合的延迟监控；
- 没有第三方独立测评；
- 没有游戏内延迟的自动采集（游戏不提供接口）；
- 没有 P99 和长尾分析。
这些是后续要补的。在补齐之前，我们不会用"平均降低 XX%""稳定 0 丢包"这类无法验证的说法。
怎么自己测
隧道 RTT
- 在客户端选择一条线路，开始加速；
- 向韩国探测机连续发送 80 个 UDP 包，记录每个包的往返时间；
- 统计最小值、最大值、中位数和丢包数。
不要用 ping 或 TCP 建连时间来代替，原因见
为什么你测的延迟不准。
更新记录
- 2026-10-20：首次发布。样本截至 2026-10-20，共 8,233 条。
还是没解决？
在客户端内使用「问题反馈」上传日志，我们能看到具体链路和错误码；也可以先看
安装与启动故障排查。