Linux中MTU不匹配导致分片丢失的关键是路径某段MTU小于端系统设置，且DF置位+ICMP被过滤使PMTUD失效，表现为大包丢弃、TCP重传升高、小包正常但大文件卡顿；需检查网卡MTU、PMTUD开关、MSS协商，并用ping -M do测试路径MTU，抓包验证ICMP黑洞，结合dmesg和网卡统计定位问题。
Linux 系统中排查 MTU 不匹配引发的分片丢失，关键在于确认“路径中某段链路 MTU 小于端系统设置”，且因 DF 位置位 + ICMP 不可达报文被过滤，导致 PMTUD 失效。这类问题不会让网络彻底中断，而是表现为大包丢弃、TCP 重传率升高、小包正常但大文件卡顿等“亚健康”状态。
看网卡 MTU 和系统是否禁用 PMTUD
先确认本地接口 MTU 值和内核是否允许路径 MTU 发现：
- 查当前网卡 MTU：
ip link show eth0 | grep mtu（常见值应为 1500；PPPoE 环境下应为 1492） - 检查 PMTUD 是否被全局关闭：
cat /proc/sys/net/ipv4/ip_no_pmtu_disc，返回 1 表示禁用——这是典型隐患，需改为 0：echo 0 > /proc/sys/net/ipv4/ip_no_pmtu_disc - 确认 TCP 连接是否协商了合理 MSS：抓包时观察 SYN/SYN-ACK 中的 MSS 选项，若仍为 1460 但路径 MTU 实际是 1492，则 MSS 应为 1452（1492 − 40），不匹配即埋下分片风险
用 ping 测出实际路径 MTU
ICMP 探测是最直接有效的方式，核心是带 -M do（禁止分片）并逐步调整负载大小：
- 从 1472 字节开始测试：
ping -M do -s 1472 8.8.8.8（1472 + 8 字节 ICMP 头 + 20 字节 IP 头 = 1500 总长） - 若不通，按 8 字节步长递减（1464 → 1456 → 1448…），直到首次通；首个成功值 + 28 即为路径 MTU（例如 1448 成功 → 路径 MTU = 1448 + 28 = 1476）
- 对比结果：若测得路径 MTU 小于本地网卡 MTU（如测出 1476，但 eth0 是 1500），说明中间存在瓶颈链路（如 PPPoE、VLAN、隧道）
抓包验证分片失败与 ICMP 黑洞
用 tcpdump 或 Wireshark 观察关键报文，定位是否发生静默丢包：
- 捕获 ICMP 不可达报文：
tcpdump -i any 'icmp[icmptype] == 3 and icmp[icmpcode] == 4'，若完全收不到，说明中间设备（如家用路由器、云防火墙）过滤了 Type 3 Code 4，PMTUD 断裂 - 观察 TCP 重传与 RST：
tcpdump -i any 'tcp[tcpflags] & (tcp-rst|tcp-syn)'，大量重传后突现 RST，常是 DF 包被丢、应用层超时触发连接重置 - 检查内核日志是否有明确提示：
dmesg | grep -i "too long\|frag\|mtu"，如出现dropped packet, size 1514 > 1500，就是 MTU 超限的铁证
结合网卡统计与错误日志交叉印证
系统级指标能反映丢包发生在哪一环：
- 查网卡收发详情：
ip -s link show eth0，重点关注 TX errors / dropped，若tx_dropped持续增长，且dmesg显示包尺寸超限，基本锁定 MTU 问题 - 用 ethtool 检查硬件级丢包：
ethtool -S eth0 | grep -i drop，排除驱动或物理层干扰 - 确认无 iptables/nftables 或 tc 规则干扰：
iptables -L -v -n、tc qdisc show dev eth0，避免误判为 MTU 问题
