MTU 问题在 TCP 层的症状
MTU 不匹配时的典型表现是「一半能用」：小包正常，下载或上传大量数据时挂起直至超时；加密握手能顺利完成，但应用数据一发送就卡住。这是排障中容易被误判为「服务不稳定」的一类问题，用包长分布可以快速证伪或证实。
基本信息
| 适用平台 | 跨设备、跨隧道的 TCP 传输，Linux 与 Windows 均受影响 |
|---|---|
| 典型症状 | 小包正常，大包挂起直至超时 |
| 验证手段 | 统计不同包长的成功率与是否收到确认 |
| 高发场景 | 隧道、点对点拨号、虚拟专用网络 |
典型使用场景
- 现象归类：把「部分能用」快速关联到 MTU 问题
- 快速证伪：用包长分布在一分钟内排除或确认方向
- 优先排查链路：隧道与拨号链路中有效 MTU 更小
- 评估缓解手段：调整最大报文段长度是常见做法
- 验证修复：调整后确认大包能稳定通过且不再超时
统计与验证
统计与验证
tshark -r a.pcap -Y 'tcp.len > 0' -T fields -e frame.len | sort -n | uniq -c | tail
# 观察接近链路 MTU 的包长是否全部没有后续确认
# 结合路径测试：ping -M do -s 1472 目标地址证据对照
| 证据 | 指向 | 下一步 |
|---|---|---|
| 小包成功率接近百分之百 | 与 MTU 相关 | 测量路径 MTU |
| 接近上限的包全部无确认 | 大概率超过路径容量 | 缩包测试确认 |
| 握手正常但数据传输挂起 | 应用数据超过路径 MTU | 检查最大报文段与 MTU 设置 |
| 所有包长都正常 | 与 MTU 无关 | 转向其他方向排查 |
应用层面的「偶发超时」很容易被误判为服务不稳定。把包长与成功率放在一起看，往往能在一分钟内看出明显的长度阈值，这就是最直接的证据。
调整最大报文段长度是常见的缓解手段，但必须配在真正处理报文的那台设备上。配错位置看起来改了配置，实际上完全没有生效。
隧道、点对点拨号与虚拟专用网络场景下 MTU 变小的概率最高，优先在这些链路上排查，能节省大量时间。