路径 MTU 黑洞
路径 MTU 黑洞的典型症状是「一半能用」：TCP 握手正常、小请求正常，一旦下载或上传大量数据就卡住或超时。原因是路径上某台设备丢弃了大包，又拦截了本该回送的 ICMP 需分片消息，发送方始终不知道要缩小报文，只能反复重传同样大小的包。
基本信息
| 适用平台 | 跨设备、跨隧道的 TCP 传输，主流操作系统均可能受影响 |
|---|---|
| 典型症状 | 握手与小包正常，大包卡住或超时 |
| 验证手段 | Linux 上用 ping -M do 逐级缩小包长测试 |
| 抓包口径 | 比较接近路径 MTU 的包与短包的成功率 |
典型使用场景
- 现象归类：把「小包正常、大包不通」快速关联到 MTU 问题
- 路径测量：用禁止分片的 ping 逐步找到能通过的最大长度
- 抓包验证：统计不同长度报文的成功率与重传情况
- 隧道场景优先排查：封装开销让有效 MTU 比标称值更小
- 验证修复：调整之后确认大包能稳定通过
验证思路
验证思路
ping -M do -s 1472 10.0.0.9 # 1472 加 28 字节头等于 1500，禁止分片
ping -M do -s 1400 10.0.0.9 # 逐步缩小直到能通，即得路径 MTU 的估计
# 抓包侧统计不同包长的成功率
tshark -r a.pcap -Y 'tcp.len > 0' -T fields -e frame.len | sort -n | uniq -c | tail症状与归属
| 症状 | 指向 | 验证方法 |
|---|---|---|
| 握手正常但大响应超时 | 路径 MTU 黑洞 | 用禁止分片的 ping 缩包测试 |
| TLS 握手能过、应用数据卡 | 数据超过路径 MTU | 看首个大包之后的重传 |
| 间歇性超时 | 存在多条路径且 MTU 不同 | 按源目分别统计成功率 |
| 只有隧道内业务受影响 | 封装开销吃掉了 MTU | 对比隧道内外的包长 |
修复方向通常有两类：放行路径上必要的 ICMP 差错报文，让 PMTUD 正常工作；或在两端与中间设备上调整 MSS，让发送方从一开始就不发超过路径容量的报文。
修改 ICMP 策略影响面大，应先在测试环境验证。生产环境更稳妥的起步方式是调整受影响链路两端的 MSS 与 MTU，再评估是否需要动策略。
QUIC 等较新的传输协议具备不依赖 ICMP 的路径探测能力，所以同一条链路上可能出现 TCP 有黑洞而 QUIC 正常的情况，症状不一致时先确认协议。