Linux 云服务器网络延迟和丢包怎么排查？ping、mtr 与连接状态判断

网络变慢时先确认业务是否真的受影响，再按本机、目标端口、路径和应用四层定位。单个中间跳点不回应 ICMP，不能直接证明业务流量在该处丢失。

先给结论

网络变慢时先确认业务是否真的受影响，再按本机、目标端口、路径和应用四层定位。单个中间跳点不回应 ICMP，不能直接证明业务流量在该处丢失。

先定义故障，而不是先跑工具

记录发生时间、源地址、目标域名或 IP、协议、端口、影响用户范围和正常基线。延迟升高、偶发超时、持续丢包和连接拒绝是不同现象，所需证据也不同。

测试必须从与真实用户相近的源端执行，并保留 UTC 时间。只在服务器本机访问 127.0.0.1 成功，不能证明公网链路正常；只从办公室测试失败，也不能证明源站故障。

第一层：排除服务器自身拥塞

先检查 CPU、负载、内存、磁盘等待和网卡错误。应用线程阻塞、软中断过高或 conntrack 紧张，都可能表现为网络慢。使用 ip -s link 查看丢包和错误计数，比较采样前后增量，不要只看累计值。

如果接口错误、drop 或队列丢弃持续增长，应先检查驱动、MTU、带宽、突发流量和宿主限制；本机资源正常后再向外追踪路径。

第二层：验证端到端与目标端口

ping 适合观察往返延迟和 ICMP 丢包，但很多设备会限制 ICMP。对真实服务还要使用 curl、nc 或应用客户端验证 TCP 建连、TLS 握手和首字节时间。

DNS、TCP、TLS 和应用处理应分开计时。域名访问慢而直接 IP 正常时优先检查解析；TCP 很快但首字节慢时更可能是应用、上游或数据库。

第三层：正确解释 mtr

mtr 将 traceroute 与连续探测结合。某个中间节点显示高丢包，而后续节点和最终目标恢复正常，通常表示该路由器降低了对探测报文的响应优先级，不代表转发流量同步丢失。

只有丢包从某一跳开始并持续影响后续跳点与最终目标，且多次、双向或不同源站测试能够复现，才更值得怀疑该段路径。非对称路由下，去程 mtr 不能完整解释回程。

第四层：检查连接与重传

用 ss -s 查看连接概况，用 ss -ti 观察具体 TCP 会话的重传、拥塞窗口和 RTT。大量 SYN-SENT 可能指向目标不可达或规则丢弃，大量 TIME-WAIT 不一定是故障，需结合连接速率和端口范围判断。

重传增加说明端到端交付存在问题，但不能单独定位在哪一跳。结合网卡统计、目标服务日志、负载均衡日志和客户端时间线，才能把网络、服务端与应用问题分开。

形成可交付的排障证据

报告至少包含测试时间、源与目标、协议端口、样本数量、ping/mtr 原始结果、应用请求耗时和服务器资源快照。跨运营商问题还应增加另一网络或地域的对照测试。

修复后用相同方法和相近时段复测。只有业务成功率、尾延迟和重传趋势同时恢复，才算完成验证；偶尔一次 ping 正常不能作为关闭故障的依据。

排查与验收表

操作边界

生产环境变更前必须记录资源 ID、时间窗口、影响范围和回退方法。命令示例需要按实际接口、区域和实例替换参数；涉及重启、迁移、网络规则或日志费用时，先在最小范围验证。

一组可复现的最小测试

先用 ping -c 20 目标域名 和 mtr -rwzc 50 目标域名 保存端到端与路径样本，再用 curl 的 time_namelookup、time_connect、time_appconnect、time_starttransfer 与 time_total 拆分 DNS、TCP、TLS 和首字节耗时。

同时执行 ss -s 查看连接概况，并用 ip -s link show dev 网卡名 比较测试前后的 drop/error 增量。域名和网卡名都是变量，必须替换；目标禁止 ICMP 时，ping/mtr 失败不能代替 TCP 与应用测试。

双向与多点对照

公网路由经常非对称。重要问题应从至少两个网络或地域测试，并在可控条件下从服务端反向验证。只有同一时间窗口、同一目标和同一协议的证据才能直接对照，跨天或跨高峰数据必须标注流量差异。

记录与复核要求

排查记录应包含准确时间、环境、资源或接口标识、执行命令、原始结果、采取的变更和变更后的独立验证。对比数据必须来自相同口径与相近负载；无法复现时应明确标记观察条件，而不是把暂时恢复写成根因已经确认。

任何涉及重启、迁移、规则、内核参数或日志保留的调整，都要先保存原值并准备回退路径。最终结论应能由另一名运维人员根据记录复核。

官方资料

• MTR 官方项目
• Linux ss(8) 手册
• Linux ip-link(8) 手册