ping 有丢包：从本机到对端，逐跳把责任划清

「网络不稳定」是最难扯皮的问题。运维说网络没问题，开发说接口超时，最后往往不了了之。

把丢包量化到跳，责任就清楚了：本机网卡错误计数、中间某跳丢包、对端入口丢包，处理方完全不同。

先说结论

用 mtr 定位到跳，用 tcpdump 确认方向，用网卡计数排除硬件。

• mtr -rwzbc 100 目标 看逐跳丢包
• 注意中间跳的 ICMP 限速会造成假丢包
• tcpdump 两端同时抓，看重传与 RST
• ethtool -S 看 rx/tx 错误与丢包计数
• 排查 MTU 与云厂商限速

先把问题说清楚

很多中间路由对 ICMP 限速，mtr 显示 30% 丢包但业务正常。判断依据是「最后一跳是否丢包」以及 TCP 重传率。

MTU 不匹配的典型表现是：小包正常，大包卡住（TCP 三次握手成功但传数据超时）。

具体怎么做

按顺序执行，每步都验证完再进下一步：

• mtr -rwzbc 100 目标地址，重点看最后两跳
• 本机 ethtool -S eth0 | grep -i -E 'err|drop' 看硬件计数
• 两端同时 tcpdump -i any -nn host 对端，比对是否有去无回
• ss -ti 看 TCP 重传与 rtt，判断是丢包还是延迟
• 测 MTU：ping -M do -s 1472 目标，逐步减小找上限

参数与成本对照

把关键数值摊开，方便判断该选哪条路：

几个容易踩的坑

下面这些是最常见的错误做法：

• 只看 ping 丢包就断定线路故障
• 在虚拟机上测丢包，忽略宿主机网络
• 忽略 MTU：表现为「握手成功但传不了数据」
• 用无线网络做基准测试：波动大，结论不可靠

最后补两句

丢包排查的产出应该是一句话：「丢在从 A 到 B 的第 N 跳」。有了这句，责任方和下一步都很清楚。

工具是手段，理解机制才是能力。命令记不住没关系，知道「该看什么」就够了。