核心思路是让容器网络层MTU与路径最小MTU对齐以避免分片或丢包，需先实证检测（如ping -M do -s测试）、确认错配（对比宿主机、docker0 MTU及dmesg日志），再针对性修复：Docker默认网桥通过daemon.json设mtu=1450，自定义网络用--opt指定，K8s则依CNI文档配置。
核心思路是让容器网络层的 MTU 值与实际传输路径中的最小 MTU 对齐，避免因包过大被截断或丢弃。重点不在“调大”，而在“匹配”。
确认当前 MTU 是否真的不匹配
先别急着改配置，用实证判断问题是否存在：
- 在容器内执行：ping -M do -s 1472 8.8.8.8（1472 + 28 字节头 = 1500）。成功说明路径支持标准 MTU；失败则逐步减小 -s 值（如 1400、1300），直到能通，该值 + 28 就是当前有效 MTU
- 查宿主机网卡：运行 ip link show eth0 | grep mtu，记下数值（常见为 1500）
- 查 docker0 网桥：ip link show docker0 | grep mtu，若显示 1500 而宿主机是 1450（比如走 VXLAN 或某些云平台），就已存在错配
- 看内核日志：dmesg | grep "too long"，出现类似 “dropped packet, size 1514 > 1500” 是典型 MTU 超限丢包证据
针对 Docker 默认 bridge 网络的修复
这是最常见场景，适用于 docker run 或未指定网络的 compose 服务：
- 停止所有使用默认 bridge 的容器：docker stop $(docker ps -q)
- 删除并重建 docker0 网桥，指定目标 MTU：sudo ip link set docker0 down && sudo brctl delbr docker0 && dockerd --mtu=1450（需重启 dockerd）
- 更稳妥方式：修改 Docker daemon 配置文件 /etc/docker/daemon.json，加入：
{"mtu": 1450}，然后 sudo systemctl restart docker - 验证：ip link show docker0 应显示 mtu 1450，新启动的容器自动继承
对自定义网络或 Kubernetes 场景的适配
当使用 docker network create 或 K8s Pod 时，需在创建阶段显式注入 MTU：
- Docker 自定义网络：docker network create --opt com.docker.network.driver.mtu=1450 mynet，后续容器连接此网络即生效
- Kubernetes Deployment 中，在容器 spec 下添加：
securityContext:
capabilities:
add: ["NET_ADMIN"]
env:
- name: MTU
value: "1450"
（注意：部分 CNI 插件如 Calico 支持直接在 IPPool 中设 mtu，优先查文档） - Windows 容器同样适用，但需确保镜像基础层支持 ifconfig 或 PowerShell 网络配置能力
临时应急与验证方法
不重启服务也能快速验证效果：
- 进入容器手动调整：ip link set eth0 mtu 1450（需 root 权限，退出后失效）
- 测试大包传输是否恢复：用 curl -v --data-binary @largefile.zip http://target/api/upload 观察是否还中断
- 对比指标变化：重点关注 ss -i 输出中的 retrans、rto、qsize；或 cat /proc/net/snmp | grep Tcp 查重传数是否回落
- 持续观察丢包率：ip -s link show eth0 中 TX/RX dropped 计数应停止增长
