MTU 黑洞的症状
MTU 问题的表现很好认：SSH 能登录、小请求正常，但稍大的响应就卡死或超时 —— 能协商、能握手，数据一多就断。常见诱因是隧道、VPN、PPPoE 把有效 MTU 压小，而路径上又有设备不回“需要分片”的 ICMP。定位方法是 ping -M do 二分探测可用载荷，再用 tracepath 看路径 MTU 在哪一跳变小。
基本信息
| 适用平台 | Linux（iputils 的 ping、traceroute 包提供的 tracepath） |
|---|---|
| 探测命令 | ping -M do -s N（-M do 表示禁止分片） |
| 排查工具 | tracepath、ip link、ip route get |
| 常见诱因 | VPN/隧道、PPPoE、VXLAN 等 overlay 网络 |
| 修正手段 | 接口 MTU、路由 MTU、网关 MSS 钳制 |
典型使用场景
- VPN 或隧道建好后大文件传输卡死
- 跨机房访问特定服务超时，小请求却正常
- PPPoE 拨号环境下访问部分站点异常
- 容器 overlay 网络里大包丢失
- 云上跨可用区出现“能连上但不能传数据”
探测与修正
探测与修正
ping -M do -s 1472 host && echo '1500 MTU 通' # 1472 加 28 字节头正好 1500
ping -M do -s 1400 host || echo '1400 都不通，继续往小试' # 二分逼近可用载荷
ping -M do -s 1372 host # 对应 1400 MTU 的载荷（1372 加 28）
tracepath -n host | tail -5 # 看路径 MTU 在哪一跳变小
ip link show eth0 | head -1 # 当前接口 MTU
ip route get host # 确认走哪条路由与出口接口
ip link set dev eth0 mtu 1400 # 临时修正：可能中断连接，谨慎
ip route add 10.20.0.0/16 via 10.0.0.1 mtu 1400 # 只对特定路由收紧 MTU现象与判断
| 现象 | 可能原因 | 下一步 |
|---|---|---|
| 小包通、大包卡 | MTU 不匹配且路径不回 ICMP | 用 ping -M do 二分确认可用载荷 |
| 1472 不通但 1400 通 | 有效 MTU 小于 1500（隧道或 PPPoE 常见） | 按探测结果调整接口或路由 MTU |
| 只有特定目标异常 | 目标路径中间存在更小的 MTU | 用 tracepath 看是哪一跳开始变化 |
| IPv6 环境更严重 | IPv6 中间路由器不分片 | 用 ping -6 -s 复验，并在两端或网关做 MSS 钳制 |
治本方案是让隧道或 VPN 两端 MTU 对齐，或者在网关做 MSS 钳制（iptables 的 TCPMSS 目标配合 --clamp-mss-to-pmtu），而不是逐台主机去调小 MTU。
直接改物理网卡 MTU 会影响该接口上的全部流量，改错可能当场断链：优先按路由或隧道粒度修正，远程操作前确认有带外通道。
把探测结果固定下来：测出可用的最大载荷后加 28 字节换算成 MTU，再决定是改接口还是只对特定路由收紧，并记入变更记录；更换网络设备或调整隧道后可以据此快速复核是否又变小了。
隧道类场景（VPN、GRE、VXLAN）两端都要对齐 MTU：只改一侧容易出现单向大包不通，表现为能建立连接但不能传数据，排查时很容易被误判成应用故障。