Linux TCP已连接但大响应卡住：PMTU黑洞与MSS排查指南
先固定一条可重现连接，记录源/目的地址、端口、地址族、接口、路由与封装。两端同时抓包，确认握手成功后是否有接近 MSS 的数据段反复重传、接收端是否根本看不到，以及途中是否返回 IPv4 Fragmentation Needed 或 IPv6 Packet Too Big。用禁止分片并逐步调整 payload 的探测估算路径 MTU，注意 ICMP、IP、UDP/TCP 和隧道头开销。修复应优先允许必要 ICMP、纠正接口/隧道 MTU或在正确边界 clamp TCP MSS；Linux PMTU 黑洞探测只能作为经过验证的补充，不能替代网络修复。
本文目录（29 节）
直接答案
先固定一条可重现连接，记录源/目的地址、端口、地址族、接口、路由与封装。两端同时抓包，确认握手成功后是否有接近 MSS 的数据段反复重传、接收端是否根本看不到，以及途中是否返回 IPv4 Fragmentation Needed 或 IPv6 Packet Too Big。用禁止分片并逐步调整 payload 的探测估算路径 MTU，注意 ICMP、IP、UDP/TCP 和隧道头开销。修复应优先允许必要 ICMP、纠正接口/隧道 MTU或在正确边界 clamp TCP MSS；Linux PMTU 黑洞探测只能作为经过验证的补充，不能替代网络修复。
一、先确认症状符合MTU边界
典型特征是 TCP Established、小 payload 成功、大 payload 停滞，且问题与方向、地址族、VPN/隧道或特定网络相关。等待后可能超时，也可能因重传和更小段偶尔恢复。
如果连 SYN 都失败，优先查路由、防火墙和监听；如果所有大小都快速 reset，优先查应用或策略。不要把所有“卡住”都归因于 MTU。
二、记录完整五元组和网络路径
保存源 IP/port、目标 IP/port、TCP/IPv4/IPv6、出接口、VRF/network namespace 与策略路由。负载均衡和 ECMP 可能让不同连接走不同路径，重跑一次命令并不能证明路径相同。
同时记录代理、NAT、VPN、GRE、VXLAN、WireGuard、IPsec、PPPoE 等封装。每层都会减少可用 payload。
三、理解MTU、PMTU与MSS
接口 MTU 是单条链路可承载的 IP 包上限；Path MTU 是端到端路径中最小 MTU；TCP MSS 是一个段中 TCP payload 的上限，通常根据本地接口 MTU和 IP/TCP 基本头计算。
MSS 不是完整包大小。TCP options、IPv4/IPv6 头和隧道封装都会占空间。简单把 MTU 值写成 MSS 会产生新的碎片或低效小包。
四、为什么握手成功但数据失败
SYN 通常很小，可以穿过低 MTU 路径；握手协商的 MSS 又只反映端点认知，不一定知道中途隧道的更低 MTU。开始传输较大 TLS 证书、HTTP header 或正文后，包才超过瓶颈。
因此端口测试、telnet 或只发几个字节的 curl 并不足以验收。必须测试跨越故障阈值的数据大小。
五、IPv4 PMTUD如何工作
传统 IPv4 PMTUD 通常发送设置 Don't Fragment 的包。中间路由器若无法转发，应返回 ICMP Destination Unreachable / Fragmentation Needed，发送端据此降低估计 PMTU。
如果 ICMP 被丢弃，发送端不知道应减小包，继续重传相同大小，形成黑洞。修复不能仅在终端允许 echo reply，PMTUD 需要的是特定错误报文。
六、IPv6依赖Packet Too Big
IPv6 路由器不会替端点分片。包超过下一链路 MTU 时，应返回 ICMPv6 Packet Too Big，发送端调整包大小。粗暴屏蔽 ICMPv6 会破坏邻居发现和 PMTU 等基础功能。
IPv4 正常而 IPv6 卡住时，分别抓包和查路由。不要通过全局关闭 IPv6 当作长期修复。
七、抓取发送端证据
在发送端记录握手 MSS、首个大段、序列号、重传时间、包长、DF 状态和 ICMP 错误。注意抓包工具在开启 TSO/GSO/GRO 时可能显示超大“虚拟包”，它们不一定是线上的真实帧。
可在正确接口抓取，并结合网卡 offload 设置或对端抓包解释。不要看到一个 64KB 抓包条目就断定网络发送了巨帧。
八、抓取接收端做差分
同一时间在接收端抓包，按序列号比较。发送端反复发送但接收端完全看不到，丢包在路径中；接收端收到并 ACK，而发送端看不到 ACK，则反向路径或 ACK 被丢；应用收到数据却不处理则不是 PMTU。
两端时钟应同步，并记录 NAT 后地址。否则同一连接难以关联。
九、寻找ICMP错误
过滤 IPv4 fragmentation needed 与 IPv6 packet too big，查看其中引用的原始包头、报告 MTU 和来源设备。验证 ICMP 引用的五元组确实属于目标连接。
没有看到 ICMP 不等于没有 MTU 问题，可能正是错误被中间层丢弃。需要在防火墙前后或隧道两端继续缩小边界。
十、使用禁止分片探测
从真实源网络向真实目的发送带 DF/等价控制的探测，逐步改变 payload，找到最大成功值。计算时加入 ICMP 与 IP 头；不同工具参数对“包大小”的定义不同，应阅读其说明。
很多设备不回应 echo，但业务 TCP 正常。因此 probe 是辅助证据，必须与真实连接抓包结合，不能把无 ping 回应直接当路径失败。
十一、检查方向不对称
请求很小、响应很大时，只在服务器到客户端方向触发问题；上传则可能相反。互联网、VPN 和多 WAN 的往返路径也可能不同。
分别从两端进行大小探测并抓包。只修一个入口接口 MTU 可能无法解决反向链路。
十二、隧道封装开销
GRE、VXLAN、WireGuard、IPsec、PPPoE 和云网络封装都会增加外层头。内层 1500 字节包经过外层封装后可能超过物理链路 MTU。嵌套隧道会进一步减少空间。
按实际加密、地址族和选项计算开销，并从隧道接口与物理接口验证。不要照搬某个固定“推荐 MTU”到所有环境。
十三、云负载均衡与容器网络
Pod veth、CNI overlay、节点隧道、云 VPC、负载均衡和出口 NAT 形成多层路径。Pod 内 eth0 1500 不代表底层可承载带封装的 1500。
在 Pod、节点内层、隧道外层和目标侧分层抓包。确认 CNI 配置的 MTU 与集群现有节点一致，滚动升级时避免新旧节点不一致。
十四、MSS协商只发生在SYN
TCP MSS option 通常在 SYN/SYN-ACK 中交换，限制对方发送段的 payload。修改 MSS clamp 只影响新建连接，现有连接不会重新协商。
验证配置后必须建立新连接，并清楚是哪个方向的 SYN 被修改。不要以旧长连接结果判断规则无效。
十五、何时使用MSS Clamp
在无法控制中间路径或隧道边界时，按 Path MTU clamp MSS 可避免 TCP 发送过大段。规则应放在正确转发路径、仅针对必要流量和地址族，并考虑 TCP options/封装。
MSS clamp 只帮助 TCP，不解决 UDP、QUIC、ICMP 或其他 IP 流量。它是边界缓解，不是完整 PMTU 修复。
十六、允许必要ICMP
防火墙应允许与已建立流量相关的 fragmentation needed 和 packet too big，并验证状态追踪不会误丢。ICMP rate limit 可以降低滥用风险，但不能完全阻断 PMTU 信号。
对 ICMP 引用包和报告 MTU 做合理验证。安全策略应依据协议需求设计，而不是“所有 ICMP 都危险”。
十七、Linux tcp_mtu_probing
Linux 提供 tcp_mtu_probing 等设置用于在检测到黑洞时尝试更小 MSS。不同取值决定何时启用，相关基础 MSS 参数也会影响行为。
修改前记录内核版本、network namespace 和当前 sysctl。全局启用会影响所有 TCP，必须在测试节点验证性能与兼容性，并准备回滚。
十八、缓存的PMTU状态
Linux 路由和 destination 状态可能缓存 PMTU 估计。网络路径变化后，旧状态可短时间影响行为；反复修改配置而复用同一连接会混淆结果。
使用新连接并查看当前路由/传输指标。不要无差别清空所有路由状态影响其他业务。
十九、区分PMTU黑洞与拥塞丢包
MTU 黑洞通常在特定包长上稳定复现，大段重传而小段成功；拥塞丢包更随负载与队列变化，也可能影响小包。比较不同大小、时段和路径。
读取 TCP 重传、RTT、拥塞窗口和接口 drop。不要仅凭“有重传”断定 MTU。
二十、区分Zero Window与应用停读
接收端通告 TCP Zero Window 时，发送端停发是流量控制，说明接收应用没有及时读取或缓冲区已满，并非路径 MTU。抓包可看到窗口大小和 probe。
此时应查应用阻塞、GC、磁盘或 downstream，而不是修改接口 MTU。
二十一、TLS为什么容易暴露问题
ClientHello 可能较小，而服务器证书链和握手消息较大，故表现为 TCP connect 成功但 TLS timeout。缩短证书链可能偶然缓解，却不应替代网络修复。
分别测试纯 TCP、小 HTTP 与完整 TLS，并在失败方向核对段长，避免误判证书验证错误。
二十二、UDP与QUIC的差异
UDP 没有 TCP MSS 协商，QUIC 在 UDP 上自行处理传输与 PMTU。TCP MSS clamp 不会修复 QUIC；过大的 UDP 数据报仍依赖路径和协议自身策略。
验证 HTTP/3 与 HTTP/2 时分别记录传输。禁用 QUIC 可作对照，但长期应修复 ICMP/PMTU 或正确配置应用包长。
二十三、安全变更步骤
先保存抓包和接口/隧道配置；定位最小 MTU 跳；优先恢复 ICMP；再校正隧道 MTU；无法控制路径时精确 clamp MSS；建立新连接复测；分批恢复流量；观察重传与延迟。
不要同时降低所有接口 MTU 和修改防火墙。一次改变一个有证据的边界，才能确认根因并避免吞吐回退。
二十四、常见错误
常见误区包括：ping 小包成功就排除 MTU；把 MSS 当完整包长；只抓一端；忽略 TSO/GSO 抓包假象；只允许 ICMP echo；IPv4 正常就忽略 IPv6；用 MSS clamp 解决 UDP；修改规则后复用旧连接；全局把 MTU 降到 1200；将 Zero Window 或拥塞重传误判为 PMTU。
另一个错误是只在终端网络验证，而应用实际位于容器、VRF 或 VPN 中。测试必须来自相同网络上下文。
二十五、修复后的验收清单
确认握手和 MSS 可解释；最大成功探测大小符合路径设计；必要 ICMP 能双向到达；隧道内外 MTU 协调；大 TCP、TLS、上传和下载均通过；IPv4/IPv6 分别验证；UDP/QUIC 不依赖 TCP 缓解；重传率恢复；无异常碎片；新连接使用预期 MSS；修改未降低无关业务吞吐。
最后在不同包长、两个方向和至少一个真实高延迟路径执行回归，确保不是本地网络偶然成功。
FAQ
1. ping通为什么网页仍卡住？
默认 ping 包很小，能穿过低 MTU 路径。网页 TLS/HTTP 数据段更大，可能触发被丢弃且无 ICMP 返回的黑洞。
2. 把服务器MTU改成1400一定能解决吗？
不一定，且会影响所有流量。应先测量真实 Path MTU 和封装开销，优先修复 ICMP或正确设置隧道边界。
3. MSS Clamp应该设多少？
取决于路径 MTU、IPv4/IPv6、TCP options 和隧道开销，没有通用数值。应在真实路径测量并验证新连接。
4. tcp_mtu_probing能替代网络修复吗？
不能。它可让 Linux TCP 在部分黑洞场景自救，但不解决 UDP/QUIC，也可能掩盖防火墙或隧道配置错误。
5. 为什么只有上传失败而下载正常？
路径与数据大小具有方向性。上传方向可能经过不同链路或发送大包，而下载方向 MSS/路径正常，需要分别抓包和探测。
总结
TCP Established 后大数据卡住，是 PMTU 黑洞的典型但非唯一表现。可靠排查应从同一五元组两端抓包，验证大段重传、ICMP Fragmentation Needed/Packet Too Big、实际 Path MTU、MSS 和隧道开销，并排除拥塞与 Zero Window。优先恢复必要 ICMP和正确 MTU，必要时在边界精确 clamp MSS，再用新连接覆盖 TCP、TLS、IPv4/IPv6 与 UDP/QUIC 做回归。