在 Docker 环境中，如果容器能够正常解析域名、建立 TCP 连接，小数据包也可以传输，但访问 HTTPS 接口、上传文件或拉取镜像时频繁卡住，问题未必出在 DNS、防火墙或应用程序本身。此时应重点检查容器、Docker 网桥、宿主机出口以及 VPN、VLAN、隧道网络之间是否存在 MTU 不匹配。🔍
一、MTU 不匹配为什么会导致传输异常
MTU 是网络接口单次能够传输的最大数据包尺寸。Docker 的 bridge 网络通过软件网桥和 veth 设备连接容器，数据包离开宿主机之前，可能还要经过 NAT、VPN、VXLAN、GRE 或云平台的封装层。Docker 网桥的基本工作方式可参考 Docker Bridge 官方文档。
如果容器接口使用的 MTU 大于实际路径可承载的 MTU，大包就需要分片，或者依靠路径 MTU 发现机制进行调整。当数据包设置了禁止分片标志，而链路中的 ICMP“需要分片”消息又被安全设备过滤时，发送端无法获知正确的路径 MTU，最终可能形成 PMTU 黑洞。
这类问题通常具有明显特征：普通 ping 正常，小尺寸 HTTP 响应正常，但大文件传输停顿；SSH 能连接，执行大量输出或 SCP 时卡住；TLS 握手偶发超时；容器访问外部服务异常，而宿主机直接访问正常。⚠️
二、先确认容器与宿主机的 MTU
第一步是逐层查看接口配置，不要只检查 docker0。可在宿主机执行：
ip link show
ip link show docker0
docker network inspect bridge
然后进入发生故障的容器，查看容器内部接口：
docker exec <容器名> ip link show
docker exec <容器名> ip addr show eth0
重点记录物理网卡、bond、VLAN、VPN、docker0、用户自定义 bridge 以及容器 eth0 的 MTU。Linux 的 ip link 命令支持查看和设置网络设备 MTU，具体参数可参考 ip-link 手册。
需要注意，宿主机物理网卡显示 1500，并不代表到目标服务器的整条路径都支持 1500。若中间经过额外封装，真正可用的路径 MTU 往往会更小，因此还要进行端到端测试。
三、使用 ping 和 tracepath 定位临界值
在 Linux 中，可以利用禁止分片的 ping 逐步测试可通过的数据大小：
ping -M do -s 1472 <目标地址>
ping -M do -s 1400 <目标地址>
ping -M do -s 1300 <目标地址>
IPv4 ping 的数据长度之外还包含 IP 头和 ICMP 头，因此测试值不能直接等同于接口 MTU。实际排查时，应逐步增减数据长度，找出能够稳定通过的最大值，而不是直接套用某个固定数值。
还可以执行：
tracepath <目标地址>
docker exec <容器名> tracepath <目标地址>
tracepath 可探测到目标主机的网络路径，并在条件允许时显示路径 MTU；其原理和输出说明可查看 tracepath 手册。如果宿主机测试正常、容器测试异常，问题通常集中在 Docker 网桥、veth 或容器网络配置；如果两者都异常，则应继续检查宿主机出口、VPN、路由设备和云网络。
四、抓包确认是否出现 PMTU 黑洞
当 ping 结果不够明确时，可以在宿主机出口和 Docker 网桥同时抓包：
tcpdump -ni any 'icmp or tcp port 443'
tcpdump -ni docker0 host <目标地址>
观察是否存在 ICMP fragmentation needed 消息、TCP 大量重传、相同序列号反复发送，或者握手成功后数据阶段停顿。如果能够看到 ICMP 返回，但容器没有调整报文尺寸，应检查 NAT、策略路由和网络命名空间；如果完全看不到相关 ICMP，则要排查防火墙、云安全策略或中间设备是否错误过滤了必要的 ICMP 报文。
五、为 Docker 网络设置合适的 MTU
对于用户自定义 bridge 网络，可以在创建时指定 MTU：
docker network create --driver bridge --opt com.docker.network.driver.mtu=1400 app-net
创建后可通过以下方式核对：
docker network inspect app-net
docker run --rm --network app-net alpine ip link show eth0
如果需要调整默认 bridge 网络，可在宿主机的 Docker 守护进程配置中设置 mtu。配置文件通常为 /etc/docker/daemon.json，例如：
{
"mtu": 1400
}
修改前应先备份原配置并验证 JSON 格式，再重启 Docker 服务。重启 Docker 可能中断容器业务，生产环境应安排维护窗口。已有网络和容器未必会自动继承新值，通常需要重建对应网络并重新创建容器。
Docker Compose 场景
使用 Compose 时，可以在自定义网络的 driver_opts 中设置 com.docker.network.driver.mtu。修改后应重新创建网络，而不是只重启容器。若旧网络仍然存在，可先检查网络中是否还有其他容器，避免直接删除共享网络造成业务中断。🛠️
六、修复后的验证清单
- 确认宿主机出口、Docker 网桥和容器 eth0 的 MTU 符合预期。
- 从容器内部重新执行禁止分片的 ping 和 tracepath。
- 测试 HTTPS 请求、镜像拉取、文件上传和长连接，而不仅是普通 ping。
- 检查 tcpdump 中的 TCP 重传是否明显减少。
- 持续观察应用超时日志、网络错误率和传输吞吐量。
不要把临时执行 ip link set dev eth0 mtu 的结果当作永久修复，因为容器重启或重建后配置可能丢失。更稳妥的方法是在 Docker 网络或守护进程配置层统一处理，并将变更写入部署文档。
总结
Docker 容器网络的 MTU 故障，核心排查思路是从容器接口开始，沿着 veth、Docker 网桥、宿主机出口和中间隧道逐层核对，再使用禁止分片的 ping、tracepath 与 tcpdump 验证实际路径。✅ 当“小包正常、大包失败”这一特征出现时，应优先怀疑路径 MTU 和 ICMP 反馈链路。修复时不要盲目降低数值，而应以真实路径测试结果为依据，并通过重建网络、复测业务和持续观察重传情况形成完整闭环。
