先确认测量目标，不设通用及格线
快节奏联机游戏通常更希望到实际游戏服务器的往返时间低而稳定。下表是便于比较游戏结果的编辑性经验参考，不是官方标准，也不保证某款游戏的体验。
| 显示的往返时间 | 实用解读 |
|---|---|
| 低于50 ms | 可作为快节奏交互的低延迟目标。 |
| 50–100 ms | 可能可以正常游玩，仍需看游戏和稳定性。 |
| 100–150 ms | 在快节奏游戏中可能更容易察觉延迟。 |
| 高于150 ms | 快速操作往往不够跟手，但不能据此认定连接故障。 |
不要把这张表当作视频通话或流媒体的通用要求。通话还受到抖动、丢包和应用缓冲影响；提前缓冲的视频更依赖可用吞吐量与稳定性。一次浏览器结果无法保证实际体验。
Ping、延迟与稳定性
传统 ping 命令使用ICMP回显请求和回复。往返时间RTT包含去程与回程；不能可靠地把RTT除以二当作单程延迟，因为两边的路径和排队情况可能不同。Mbps衡量传输容量，与ms衡量的延迟不是同一指标。
延迟变化通常称为抖动，丢包则是另一个网络指标。记录数字时要一起记下目标和方法，不同工具不一定计算同一种统计量。
IPdidi浏览器测试实际测什么
延迟测试先做2次预热，再向为本站提供服务的Cloudflare节点上的 /ping.txt 做40次HTTP测量。它不发送ICMP包，也不是到游戏服务器的测量。
实现通常使用 requestStart 到 responseStart 的间隔，即HTTP请求到响应开始的时间，其中可能包含服务端处理。没有可用的资源计时时，改用包含读取响应在内的fetch总耗时。这些结果有参考价值，但不能保证是纯网络RTT。
页面的抖动是相邻成功样本差值绝对值的平均值。超时或HTTP失败计为失败样本，不是IP数据包丢失率的测量。用途评级是本站经验规则，不是应用服务商认证。本说明依据源码核对，不代表做过实际网络或设备测试。
做出可比较的记录
- 记下目标、工具、时间、Wi-Fi或网线、VPN状态、平均值、波动与失败次数。
- 网络空闲时重复测量，再在正常下载或上传时比较，保持目标和方法不变。
- 条件允许时比较网线与Wi-Fi，帮助判断无线因素，但不保证数值一定下降。
- 查看游戏自己的网络显示或通话应用诊断。到一个节点的结果良好，不能排除其他场景里的本地、线路、服务端或应用问题。
若要比较ICMP，可在终端运行 ping example.com，持续运行时用Ctrl+C停止。目标可能过滤回显请求；没有回复本身不证明服务宕机。
每次改一项，再测量
- 暂停大文件下载、备份，检查负载下排队是否有关。
- Wi-Fi可比较位置、较少拥挤的频段或信道；隔墙、远距离下5 GHz不一定更好。
- 用同一种实际活动比较合适区服及VPN开关。VPN或更快套餐都不保证更低延迟。
- 路由器若支持队列管理，按厂商官方说明配置；它可以帮助控制排队，不能消除传输距离。
- 问题持续时，向支持人员提供目标、时段和空闲/负载对比，不只提供一次最低值。
每项变化前后都使用同一个测试。不要只根据两个不同目标的差值判断原因。
常见问题
100 ms一定很差吗？
不一定。用途、目标、协议和稳定性都重要，应把它作为待分析的测量，而非通用及格线。
HTTP失败就是丢包吗？
不是。请求失败可能有多种原因，本测试不能确定网络层丢包率。
为什么游戏显示不同？
目标、流量和处理过程不同。应比较游戏自身诊断，不应简单相减两个不相关测量。
来源与范围
本文解释指标和对比流程，不声称已经定位你的连接故障，也不声称测试过特定设备。
来源核对日期: 2026-11-05.