docker容器网络丢包需沿数据路径逐层实证排查：容器协议栈→veth→宿主机网桥/cni→物理网卡→外部网络；重点验证mtu对齐、iptables/cni规则开销、dns延迟及控制面状态一致性，避免将服务误判为网络丢包。
分析 Docker 容器网络丢包，不能只看“ping 不通”或“curl 超时”，得顺着数据包实际路径一层层往下查：从容器内部协议栈 → veth 设备 → 宿主机网桥或 CNI 插件 → 物理网卡 → 外部网络。关键不是猜，而是用命令实证每一环是否正常。
先确认是不是真丢包，还是控制面误判
很多所谓“丢包”其实是服务状态不同步导致的假象：
- 进容器执行 ping -M do -s 1472 8.8.8.8：若不通，逐步减小
-s值（如 1420、1372），找到最大能通的载荷，加 28 得出真实路径 MTU（例如 1420+28=1448 → 实际 MTU≈1450） - 运行 dmesg | grep "too long"：出现 “dropped packet, size 1514 > 1450” 就是内核因超 MTU 主动丢弃，属真实网络层丢包
- 对比 docker inspect
中的 State.Status和 Swarm/K8s 控制平面显示的状态：若容器内ps aux显示进程正常，但平台标记为 failed，大概率是心跳超时引发的误重建，不是网络丢包
查宿主机与容器网络平面是否对齐
Docker 默认 bridge 模式下，docker0 网桥、物理网卡、overlay 封装层三者 MTU 必须一致，错配会在任意一层批量丢包：
- 查宿主机主网卡 MTU：ip link show eth0 | grep mtu
- 查 docker0 MTU：ip link show docker0 | grep mtu；若两者不等（如 eth0 是 1450，docker0 是 1500），就是错配起点
- 查路由表是否冲突：ip route | grep 172.17；若发现 172.17.0.0/16 与企业内网重叠，必须改 Docker 默认子网，例如在
/etc/docker/daemon.json加"bip": "192.168.100.1/24"
定位 iptables / CNI 插件带来的隐性开销
规则膨胀或策略模式不当会拖慢包转发，表现为延迟高、重传多、看似丢包：
- 统计 NAT 表规则数：sudo iptables -t nat -L -n | wc -l；若超过 500 条，iptables 匹配耗时显著上升
- Cilium 用户检查策略模式：cilium config view | grep PolicyEnforcement；启用
always-enforce会强制所有流量走 eBPF 连接跟踪，增加开销 - Flannel 或 Calico 用户，确认其配置中 MTU 是否与底层一致（如 Flannel 的
net-conf.json中mtu字段）
验证 DNS 与应用层行为是否放大故障感知
一次域名解析失败可能被误认为网络中断，而高频短连接重试又会触发 TCP 重传风暴：
- 容器内执行 nslookup httpbin.org，观察响应时间；若 >300ms，说明 DNS 成为瓶颈
- 修改
/etc/docker/daemon.json加入"dns": ["8.8.8.8", "1.1.1.1"]，重启 dockerd 后测试 - 微服务场景下，检查健康检查间隔是否过短（如默认 5 秒心跳）；边缘网络抖动易导致误判，建议延长至 15–30 秒并配合主动上报机制
