Cloud Servers出现“访问慢”时，最常见的误判是看到某一跳丢包就认定线路故障。很多中间节点会限制 ICMP 响应，但仍能正常转发业务流量。排查时要把路径工具的结果与 TCP、HTTP 和应用日志结合起来，判断端到端是否真的受影响。

先确认故障范围

分别从受影响客户端、同运营商测试点和服务器反向测试，记录发生时间、目标端口、DNS 解析结果和业务 URL。Linux 可以使用 mtr、tracepath 和 curl，Windows 可以使用 tracert、pathping 和 PowerShell 测试 TCP 连接。不同来源的结果有助于区分本地、跨网和服务器侧问题。

正确阅读 MTR 结果

重点观察最终目标的丢包和延迟，而不是单个中间跳。若某一跳显示丢包但后续节点恢复正常，通常不能单独作为故障证据；若从某一跳开始到目标持续丢包或延迟升高，才值得结合时间段和多次样本进一步定位。

提交工单时提供可复现材料

把测试时间、源 IP、目标 IP、命令参数、连续样本、业务端口和影响范围整理成一份记录。部署在IDCY Global的Cloud Servers发生异常时，还可以补充服务器监控、Nginx 状态码和Bandwidth图，帮助Network团队快速判断是线路还是应用瓶颈。

资料参考：Cloudflare：Traceroute 原理。本文为原创排障流程整理。