MTU 黑洞的典型症状
路径 MTU 是整条链路上最小的一跳决定的。当路径中某台设备不允许分片、又无法回送「需要分片」的 ICMP 差错时，超过该尺寸的大包会被静默丢弃：小包（ping、握手）都正常，一旦传输大文件或 TLS 握手携带大证书就卡住。表现为「能登录、能 ping 通，但页面打不开或传文件卡在某个百分比」。
基本信息
| 本质 | 路径 MTU 变小，且中间设备不回送 ICMP 类型 3 代码 4 |
|---|---|
| 常见诱因 | GRE/IPsec 隧道开销、PPPoE 的 1492、中间防火墙禁用 ICMP、云网络网关行为 |
| 本机缓解 | net.ipv4.tcp_mtu_probing=1 让内核自动降低 MSS 并探测 |
| 网关缓解 | iptables 的 TCPMSS --clamp-mss-to-pmtu，仅对 TCP 生效 |
分层排查
| 层面 | 可疑点 | 验证方式 |
|---|---|---|
| 隧道 | GRE/IPsec 外层开销压缩可用 MTU | 查两端 MTU 与 MSS 设置 |
| 接入 | PPPoE 场景实际为 1492 而非 1500 | 用大包 ping 逐步试探 |
| 中间防火墙 | 禁用 ICMP 导致 PMTUD 失效 | 放行差错类 ICMP 或做 MSS clamp |
| 云网络 | VPC 网关与负载均衡的分片行为 | 查云厂商文档或提工单确认 |
定位与缓解
定位与缓解
ping -M do -s 1400 -c 3 host # 禁分片发 1400 字节载荷，逐步逼近真实 MTU
mtr -rwz host # 结合丢包位置判断在哪一跳开始丢
tcpdump -nn -i eth0 'icmp and icmp[0] == 3 and icmp[1] == 4' # 观察「需要分片」差错
sysctl -w net.ipv4.tcp_mtu_probing=1 # 自动降低 MSS 并探测
# iptables 网关侧：仅对 TCP 握手做 MSS 收敛
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu典型使用场景
- VPN 隧道建成后网页打不开但 ping 正常，优先怀疑隧道开销导致 MTU 变小
- 云主机与本地机房互通时大文件传输中断，检查专线或隧道 MTU
- TLS 握手偶发失败：证书链较长时超过 MTU 且被静默丢弃
- 给网关加 MSS clamp 作为快速止血手段，再回头修正真实 PMTU
「能 ping 通但打不开网页」的经典三查顺序是：MTU 黑洞、DNS 解析、TLS 证书。先排除 MTU 往往能最快定位，因为症状与包大小高度相关。
MSS clamp 只是缓解：它只作用于 TCP，遇到 UDP 与 QUIC 流量仍需真实的 PMTUD 能力，根治要么放开 ICMP 差错报文，要么修好路径 MTU 配置。