PMTUD 与黑洞的产生
路径 MTU 发现（PMTUD）靠一个约定运转：路由器遇到「不分片」但超过下一跳 MTU 的包时，丢弃并回一个 ICMP 差错报文，告知发送方该用多小的 MTU。若路径上某个防火墙或安全设备丢弃了这类 ICMP 差错报文，发送方永远收不到通知，就会一直重发同样大的包，形成所谓黑洞。表现出来就是小包通畅、大包静默丢失。
典型现象
网页首页能打开但表单提交或文件上传卡死、SSH 登录成功但一执行大输出就僵住、数据库查询小结果正常而大结果超时——这些都是典型的 MTU 症状。判别方式很直接：同一目标用小包与大包分别测试，小包稳定、大包失败，且抓包能看到重传，就可以基本确认。
基本信息
| 适用平台 | Linux / Windows / 网络设备（跨平台通用问题） |
|---|---|
| 关键开关 | net.ipv4.tcp_mtu_probing（0 关闭，1 始终，2 仅黑洞时开启） |
| 常见诱因 | 隧道与 VPN 封装、GRE/IPsec、云网络覆盖层 |
| 根治手段 | 中间设备启用 MSS 钳制并正确回送 ICMP 差错 |
识别与缓解
识别与缓解
ping -M do -s 1472 10.0.0.5 # 大包失败，说明路径 MTU 不足
ping -c3 -s 100 10.0.0.5 # 小包正常，形成对照
sudo ip link set dev eth0 mtu 1400 # 临时缓解：把本机 MTU 下调
sysctl net.ipv4.tcp_mtu_probing # 查看黑洞探测开关当前值
sysctl -w net.ipv4.tcp_mtu_probing=2 # 临时开启：仅在疑似黑洞时探测
sudo tcpdump -nn -i eth0 'host 10.0.0.5 and tcp' -c 30 # 观察是否反复重传同一大包现象与对应判断
| 现象 | 可能原因 | 核对方式 |
|---|---|---|
| 能建连但传大文件失败 | 路径 MTU 小于本机 MTU | 禁用分片的大包测试 |
| 抓包看到反复重传同一个大包 | ICMP 差错被中间设备丢弃 | 两端同时抓包对照 |
| 隧道内业务卡顿 | 封装开销使有效 MTU 变小 | ping 定位隧道内可用包长 |
| 调小本机 MTU 后恢复 | 确认是 MTU 问题 | 把 MTU 改回复现对比 |
典型使用场景
- VPN 打通后内网应用偶发卡死：优先怀疑隧道封装导致的 MTU 不足
- 云上跨可用区访问异常：云网络覆盖层通常比物理链路 MTU 更小
- 容器跨节点通信异常：Overlay 网络封装带来额外的头部开销
- 安全设备改造后业务异常：新设备丢弃 ICMP 差错报文会直接造成黑洞
- 应用升级后出现上传超时：先排除 MTU，再查应用侧超时配置
缓解顺序建议是先在本机下调 MTU 验证结论，再在网关或防火墙上启用 MSS 钳制根治；只在本机降 MTU 无法解决其他主机的同类问题，也无法处理双向路径差异。
tcp_mtu_probing 只是本机侧的补救手段，无法修复中间设备丢弃 ICMP 差错这一根源；开启后传输层会尝试更小的包，代价是连接前期性能下降。