优化Docker容器MTU的核心是匹配路径最小MTU而非调大，需先通过ping -M do -s实证检测有效MTU，再针对Overlay、bridge或host等网络模式分别配置（如daemon.json设mtu=1450或network create --opt指定），最后验证容器内mtu值及跨主机大包连通性。
优化 Docker 容器 MTU 的核心不是“调大”，而是让容器网络层的 MTU 与整条传输路径中的最小 MTU 对齐，避免因包过大被静默丢弃或强制分片。跨主机通信（如 Overlay 网络、VXLAN、云平台虚拟网络）尤其容易因多层封装导致有效 MTU 下降，1500 往往不再适用。
先实证确认是否真为 MTU 问题
跳过检测直接改配置，可能白忙一场：
- 在容器内执行：
ping -M do -s 1472 8.8.8.8（1472 + 28 字节 IP+ICMP 头 = 1500）。无响应或提示 “Packet too big” 表明路径不支持标准 MTU - 逐步减小
-s值（如 1420 → 1372 → 1320），直到 ping 通，该值加 28 即为实际路径 MTU（例如 1420+28=1448 → 取整为 1450） - 查宿主机网卡：运行
ip link show eth0 | grep mtu，常见云环境（AWS/Aliyun/Tencent Cloud）返回 1450 或 1400 - 查 docker0 或 CNI 接口：如
ip link show docker0或ip link show cali+，对比是否明显大于宿主机值 - 看内核日志：
dmesg | grep "too long"，出现 “dropped packet, size 1514 > 1450” 是典型证据
针对 Docker Overlay 跨主机网络设 MTU
Overlay 网络（Swarm 或自定义 overlay）默认使用 VXLAN 封装，额外增加约 50 字节开销，推荐统一设为 1450：
- 创建 overlay 网络时显式指定：
docker network create -d overlay --opt com.docker.network.driver.overlay.mtu=1450 my-overlay - 若已存在 overlay 网络，需删除重建（overlay 网络 MTU 不支持热更新）
- Swarm 集群中，确保所有 manager 和 worker 节点的
/etc/docker/daemon.json也设{"mtu": 1450}，避免节点间错配
对自定义 bridge 或 host 模式做适配
非 overlay 场景同样需对齐路径瓶颈：
- 自定义 bridge 网络（适合单机多容器隔离）：
docker network create --driver bridge --opt com.docker.network.driver.mtu=1450 my-bridge - host 模式虽绕过 NAT，但容器直接继承宿主机网卡 MTU；若宿主机网卡 MTU 是 1400（如某些裸金属云），容器无需额外设置，但需确保上层应用不发超限包
- Macvlan 模式下，容器直连物理网络，MTU 应严格等于宿主机物理接口值（
ip link show eth0所示），不可高于它
验证与长期保障
改完不验证，等于没改：
- 新启动容器内执行：
ip link show eth0 | grep mtu，确认输出为设定值（如mtu 1450） - 跨主机互 ping 大包：
ping -M do -s 1422 <另一节点容器IP>（1422 + 28 = 1450），应稳定通达 - 业务验证：重点测试 TLS 握手、gRPC 流、大文件上传等易受 MTU 影响的场景
- 运维建议：将 MTU 设置写入基础设施即代码（如 Ansible playbook / Terraform module），避免节点间配置漂移
