一条链路 MTU 降到 1400 引发的"间歇性 502"：用 3 条命令 20 分钟定位 MTU 黑洞

先说结论：网络里只要有任意一段链路的 MTU 比你端到端的包小，且中间设备又不做分片、又不回 ICMP Frag Needed，你看到的就不是"丢包"，而是"间歇性 502 / 连接正常但传输卡住"。这类问题最容易骗过 ping、骗过抓包的第一眼，也最容易把锅甩给应用。下面按"现象—原理—做法—坑—清单"五段写，全部基于我 15 年里处理过的真实案例，参数都是可直接复现的。

一、现象与影响

某电商网关集群（12 台 K8s node，10G 出口），2023 年一次上游专线割接后出现诡异故障：

• 网关到订单库的 HTTP 调用 QPS 稳定 1200，P50 延迟 8ms 正常；
• 但 P99 从 45ms 飙到 3100ms，且 502 比例 从 0.02% 涨到 1.8%，集中在 POST 带 JSON 的请求；
• GET 请求基本不受影响，丢包率 mtr 显示只有 0.3%，看起来"网络没问题"；
• 应用侧抓包能看到 SYN/SYN-ACK/ACK 三次握手完全正常，只有 data 段发出后没有 ACK，最终由 tcp_retrans 兜底，单次超时 2~3 秒后重传成功。

按经验，这个特征 90% 指向"大包黑洞"——某段链路 MTU 小于你的数据段大小，且 PMTUD 没兜住。

二、原理：为什么"ping 正常 + 小包正常 + 大包卡死"

1. TCP 的 MSS 由 SYN 阶段的 option 协商，一旦协商完成，本条连接不会再自动降 MSS。所以只要 SYN 阶段那条链路 MTU 是 1500，协商出的 MSS 就是 1460（1500 - 20 IP - 20 TCP）。
2. 中间设备如果 MTU < 1500 且 DF=1，正确行为是回 ICMP Type 3 Code 4（Frag Needed, Next-Hop MTU = X）。Linux 内核收到后，会把这条 socket 的 PMTU 缓存为 X，后续分段按 X 走。
3. 黑洞 = 中间设备静默丢包（不回 ICMP）。常见于：某些防火墙/安全组默认策略、某些云厂商 VPC 网关、某些 SD-WAN 隧道、老旧交换机开启"防 ICMP"策略。此时内核 PMTU 缓存不会更新，socket 一直发 1460 的段，一直丢，一直等 200ms / 400ms / 800ms ……的 RTO，最终由 tcp_retries2（默认 15，累积约 16 分钟）兜底超时。
4. 为什么 GET 没事、POST 有事：GET 的 body 通常是 0 字节，整条流可能就一个 60 字节的包；POST JSON 一次几百到几 KB，第一个数据段就超了降下来的 MTU。这就是"丢包率只有 0.3%"的真相——mtr 用的是 56 字节小包，永远不会撞上 MTU 边界。

一句话：PMTUD 依赖 ICMP，ICMP 被吃，PMTUD 就失效，TCP 退化成"盲重传"，表现就是 P99 抖动 + 间歇 502，而不是持续丢包。

三、具体做法（3 条命令，20 分钟定位）

Step 1：确认"小包通、大包卡"（1 分钟）

# 小包：正常
ping -c 5 -s 100 <对端IP>

# 大包 + 不分片：如果失败，说明中间 MTU 小于 1500
ping -c 5 -s 1472 -M do <对端IP>

# 二分定位真实 MTU（每次 -s 减半）
for s in 1472 1300 1200 1100 1000; do
  ping -c 3 -s $s -M do <对端IP> >/dev/null && echo "OK  MTU=$((s+28))" || echo "FAIL at -s=$s"
done

我们那次二分结果是 MTU=1400（-s=1372 OK，-s=1400 FAIL），和上游专线割接时新设备默认 1400 完全对上。

Step 2：确认 ICMP 是否被吃（2 分钟）

# 抓对端是否回了 Frag Needed
tcpdump -i eth0 -nn icmp and 'icmp[0]==3 and icmp[1]==4'
# 同时发大包
ping -s 1472 -M do <对端IP>
# 若 tcpdump 0 报文 → 中间设备静默丢，黑洞实锤

Step 3：三选一修复（按优先级）

• 首选：让网络侧把整条路径 MTU 拉齐到 1500，或至少把降 MTU 的设备改成"回 ICMP Frag Needed"。这是根治。
• 次选：在业务侧强制降 MSS，绕开 PMTUD：

  # 网关容器/主机上，对目标网段强制 MSS=1360（对应 MTU 1400）
  iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,ACK SYN,ACK \
    -m tcpmss --set-mss 1360
  

  注意：必须同时打 SYN 和 SYN-ACK 两条方向，只打一条会有一半连接没生效。
• 兜底：调小应用侧 socket 的 SO_SNDBUF / 让客户端走 HTTP/1.1 chunked，减小单段大小；不推荐，只是让症状不明显。

验证（5 分钟）：

# 1. 复现脚本：POST 一个 4KB JSON，看 P99 是否回到 <100ms
wrk -t4 -c50 -d60s -s post_4k.lua https://gw.internal/order
# 2. 看内核 PMTU 缓存是否还在 1460
ss -ti dst <对端IP> | grep -E 'pmtu|mss'
# 3. 15 分钟观察：502 比例应回到 <0.05%

我们那次：MSS clamp 到 1360 后，P99 从 3100ms 回落到 62ms，502 比例 1.8% → 0.03%，15 分钟内完成验证。

四、踩过的坑 & 反直觉之处

1. ping -s 1472 -M do 通了 ≠ MTU 没问题。ICMP 的包长计算和 IP 包不同，且有部分设备对 ICMP 有特殊放行。必须用 TCP 段验证：nc -v <IP> 443 然后发 2KB 数据。
2. MSS clamp 只打 SYN 方向，一半连接没生效。iptables 的 mangle 是双向独立的，我们第一次只加了 SYN 出方向，结果偶发复现，抓包才发现回程 SYN-ACK 的 MSS 还是 1460。两条都要打。
3. PMTUD 缓存是 per-route，不是 per-socket。一个 socket 触发过降 MTU 之后，同路由的其他 socket 会"继承"错误的低 PMTU，即使网络已经修好也不会自动恢复。必须 ip route change ... mtu 1500 或清路由表。
4. tcpdump 默认抓的是"发出前"，不是"对方收到后"。你以为的"对方没 ACK"，可能只是对方网卡收到但驱动层丢了（ring buffer 满）。排 MTU 问题先看对端 ethtool -S eth0 | grep drop，别一上来就怀疑路径。
5. K8s 场景下 MTU 是三层叠加：物理网卡 1500 → CNI（Calico/Flannel）隧道再减 50~68 → 容器 veth 默认 1500。任何一层不匹配都会黑洞。用 ip link show 逐跳看，别只看两端。
6. 别信"我们网络没问题"的第一反应。我 15 年里，"应用 bug / GC / 连接池"是被甩锅最多的三个，其中至少一半最后查下来是 MTU/MSS。P99 抖动 + 小包正常 + 大包卡，这个组合先查 MTU，再查别的。

五、结论与可复用清单

结论：MTU 黑洞是"低丢包率 + 高 P99 抖动 + 间歇 502"的经典根因之一，且几乎只在大 body 的写操作上暴露。PMTUD 依赖 ICMP，ICMP 被吃就失效，TCP 退化成盲重传。根治是拉齐 MTU，兜底是双向 MSS clamp，验证必须用 TCP 大包而非 ping。

排障清单（建议贴在团队 wiki）：

• [ ] 症状：P99 抖动 > 5×P50，502 集中在 POST/大 body
• [ ] ping -s 1472 -M do 是否 FAIL？FAIL 则二分找真实 MTU
• [ ] tcpdump icmp[0]==3 and icmp[1]==4 是否有回包？无回包 = 黑洞
• [ ] 中间设备（防火墙/SD-WAN/云 VPC）是否禁 ICMP？
• [ ] 修复：拉齐 MTU > 双向 MSS clamp > 应用侧拆包
• [ ] 验证：wrk 4KB POST P99 回到 <100ms，502 比例 <0.05%
• [ ] ss -ti 检查 PMTU 缓存，必要时 ip route change 清缓存
• [ ] K8s：ip link show 逐跳核对 物理/CNI/容器 三层 MTU
• [ ] 事后：把 ethtool -S | grep drop 纳入常规可观测面板

一句话带走：网络问题里，"丢包率不高但 P99 抖" 优先怀疑 MTU 黑洞，而不是应用。

本文所有命令与参数基于 Linux kernel 5.15 / iproute2 5.15.0 实测，iptables 规则在 x86_64 环境验证。