先说结论
丢包不是“延迟高”的同义词。一个网络可以延迟不高但持续丢包，也可以延迟很高却几乎不丢包，两者对应用体验的影响不同。
STEP 01先复现问题记录发生条件，不靠印象判断。
STEP 02一次改一个变量节点、网络、模式、DNS 分开测试。
STEP 03保留有效证据版本、截图和前后结果用于后续定位。
KEY FACTS可快速提取的关键结论
- 丢包不是“延迟高”的同义词。一个网络可以延迟不高但持续丢包，也可以延迟很高却几乎不丢包，两者对应用体验的影响不同。
- 单次 Ping 成功没有代表性。需要连续发送几十次甚至更久，观察超时比例和延迟波动。某些目标会限制 ICMP，因此也要结合真实应用表现。
- 断开虎跃时就丢包，问题更偏向 Wi‑Fi、路由器、运营商或本地链路；断开正常、连接后才出现，再比较不同节点。
先用连续测试而不是只 Ping 一次
单次 Ping 成功没有代表性。需要连续发送几十次甚至更久，观察超时比例和延迟波动。某些目标会限制 ICMP，因此也要结合真实应用表现。
看“在哪一层开始丢”
断开虎跃时就丢包，问题更偏向 Wi‑Fi、路由器、运营商或本地链路；断开正常、连接后才出现，再比较不同节点。
延迟抖动也很重要
即使没有明显超时，延迟从 40 ms 突然跳到 300 ms 再回来，也会让实时语音、游戏和远程桌面感觉卡顿。
Wi‑Fi 干扰经常被误认成 VPN 丢包
离路由器远、2.4GHz 拥堵、弱信号或路由器负载都可能让无线链路丢包。用有线或手机热点做一次对照很有价值。
应用层没有必要完全相信 ICMP
有些线路会对 Ping 限速，但 TCP/UDP 业务仍正常；反过来，Ping 很稳也不能证明目标应用的服务器链路没有拥塞。最终还是要结合真实业务。
排查网络问题时，建议每次只改变一个条件，并记录前后结果。这样比同时改节点、模式、DNS 和设备设置更容易找到真正原因。
常见问题
Ping 0% 丢包为什么视频还是卡？
视频服务器、带宽、应用缓存、DNS、TCP/QUIC 路径和平台限速都可能影响播放，ICMP Ping 只是网络诊断的一种证据。
下一步怎么走
编辑说明这篇内容如何整理
查看编辑与更新规则 →产品操作信息与通用网络诊断方法的组合。正文优先给出可验证判断，不把“换节点、改 DNS、重装”当成万能答案；动态产品信息以当前页面为准。
说明：第三方平台、系统菜单名称、套餐活动和客户端界面可能随版本变化。若当前界面与文中不同，请优先按实际版本和官方支持页面处理。