mtr可精准定位丢包跳数：执行mtr -n -r -c 20 目标地址，关键看Loss%列突增位置；若某跳Loss%显著升高而前后跳为0%，则问题锁定在该节点或其上游链路。
用 mtr 定位丢包发生在哪一跳
丢包必须用 mtr 查，ping 只能告诉你“整条链路丢了几个”，但完全看不出在哪丢。比如 ping -c 10 14.215.177.39 显示 30% 丢包，你根本不知道是本地网关、机房交换机还是云厂商 LB 丢的。
mtr -n -r -c 20 14.215.177.39 是最小可靠组合：
- -n 跳过 DNS 解析，避免卡在无反向解析的中间节点
- -r 禁用交互模式，直接输出统计，防止误操作干扰判断
- 关键看每行的 Loss% 列：如果第 4 跳突然升到 65%，而前后跳都是 0%，问题就锁定在该设备或其上游链路
- 注意区分“高延迟”和“真丢包”：Avg=15ms, Wrst=850ms, StDev=210ms 是抖动信号，Loss%=30% 才是丢包证据
查网卡驱动层是否静默丢包
很多丢包根本没进协议栈，tcpdump 抓不到，但 ethtool 和 /proc/net/dev 会暴露痕迹。重点盯三类计数器：
-
rx_over_errors持续上涨 → Ring Buffer 溢出，典型表现是ethtool -S eth0 | grep rx_over返回非零值 -
rx_dropped上涨 → NAPI 调度慢或中断风暴，常见于高吞吐 + 单 vCPU 场景（尤其虚拟机） -
rx_missed_errors在 virtio 网卡中升高 → vCPU 处理不过来，不是网线问题
验证命令：
- cat /proc/net/dev 看 Rx-OVR（Ring Buffer 溢出）和 Rx-DRP（进缓冲区后丢）列
- ethtool eth0 确认 Link detected: yes、Speed 和 Duplex 是否协商正常
- 物理链路异常时，rx_errors 也会同步上升，比如光模块老化或双工不匹配
检查 tc/qdisc 是否人为丢包
tc 配置的丢包完全不会体现在 /proc/net/dev 或 netstat -i 中，是最隐蔽的“伪丢包”来源。运行：
tc qdisc show dev eth0 —— 如果输出含 netem 或 loss 5%，立刻确认是否误配tc -s qdisc show dev eth0 —— 带 -s 才能看到真实丢包数，例如 dropped 42
常见陷阱：
- 容器网络（如 Calico/Cilium）可能在 host interface 上挂 tc 规则，别只查容器内网卡
- tc qdisc add dev eth0 root netem loss 10% 会让所有出向包无差别丢 10%，且对应用层完全透明
用 tcpdump 确认包是否进入协议栈
抓包位置决定你能排除哪段链路，三处必须试：
-
tcpdump -i eth0 -n -t -S port 8080：网卡入口。若这里没抓到 SYN，说明丢包在物理链路或上游设备（比如防火墙拦截、交换机 ACL） -
tcpdump -i lo -n -t -S port 8080：本地回环。若这里能抓到请求但服务没响应，问题在应用层或 socket 接收队列满（ss -i查rwnd和rcv_ssthresh） -
tcpdump -i any -n -t -S 'tcp[tcpflags] & (tcp-syn|tcp-ack) != 0'：全接口抓关键标志位，避免漏掉重传或 RST
注意：
- 开启网卡 offload（TSO/GSO/LRO）时，tcpdump 可能看到“巨帧”，需先 ethtool -K eth0 gso off tso off 再抓
- iptables 的 DROP 规则不记日志时，包静默消失；conntrack 表满（conntrack -S 显示 insert_failed 持续增长）也会导致新连接 SYN 包被丢，现象和网络中断一模一样
真正难的不是找到某个丢包点，而是区分“真丢包”和“机制行为”——比如 conntrack 满、tc netem 限流、iptables 静默丢弃，这些都不会触发传统链路层错误计数，但表现和物理丢包完全一致。
