NAT 场景的 MSS 与 MTU 注意点是什么
NAT 本身不改动报文大小，但 NAT 常与隧道、PPPoE 拨号叠加使用，这些封装都会额外占用字节，使实际可用载荷变小。此时若 TCP 协商的 MSS 仍按标准以太网 1500 计算，大报文就会在链路上被丢弃或分片，典型表现是「网页首屏能开、图片刷不出来」「小文件能传、大文件卡住」「SSH 能登录、操作几下就卡死」。
基本信息
| 触发场景 | IPsec 或 GRE 隧道、PPPoE 拨号与 NAT 叠加 |
|---|---|
| 典型表现 | 小包通、大包断，网页与上传异常，SSH 操作卡死 |
| 常用处理 | 在设备侧限制 TCP MSS 值，或调整接口 MTU |
| 协同要求 | 隧道两端与中间设备的 MTU 需匹配 |
| 验证方式 | 用不可分片的 ping 逐步试探最大可通过报文长度 |
典型使用场景
- PPPoE 拨号出口：实际 MTU 小于 1500，需要调整 MSS
- IPsec 或 GRE 隧道：封装开销导致路径 MTU 变小
- 业务反馈访问缓慢但连通正常，需判断是否为大包问题
- 更换出口设备后部分网站异常，怀疑与新链路 MTU 有关
- 隧道改造后复测：确认大包业务恢复正常
- 排查 SSH 登录后卡死：常见于 MSS 与路径 MTU 不匹配
验证方法
验证方法
# Linux：-M do 表示不可分片，逐步减小长度找到可通过的最大值
ping -M do -s 1400 目标地址
# Windows：-f 不分片，-l 指定数据长度
ping -f -l 1400 目标地址
# 找到临界值后据此设置设备侧 TCP MSS 限制
# 调整后复测：文件传输、视频与会话类业务都要验证排查要点
| 要点 | 说明 | 常见疏漏 |
|---|---|---|
| 路径 MTU | 整条路径上最小的 MTU 决定可用载荷 | 只调了 NAT 设备，忽略中间设备 |
| TCP MSS | 由设备在握手时改写，需两侧配合 | 只改一端，另一方向仍然过大 |
| ICMP 放行 | PMTUD 依赖 ICMP 差错报文 | 封禁 ICMP 后大包问题更明显 |
| 封装开销 | 隧道头占用字节 | 按 1500 估算导致设置偏大 |
只调 NAT 设备而不检查中间的 PPPoE 或隧道设备，问题仍会复现；路径上每一段都要确认 MTU 与 MSS 设置是否协调。
封禁 ICMP 会破坏路径 MTU 发现机制，隧道场景需放行必要的 ICMP 差错报文，否则大包问题会更难收敛。