容器网络不通或丢包，须先区分“真丢包”与“假抖动”：用ping -M do -s 1472测MTU、dmesg查“too long”日志、docker inspect比对状态；再查IP转发、NAT规则、firewalld干扰；接着确认通信范围与DNS；最后用tcpdump抓包定位环节。
容器网络不通或丢包，不能一上来就改配置、重启服务。得先分清是“真丢包”还是“假抖动”，再按路径逐层验证——从容器内部、到宿主机网络栈、再到外部链路和平台控制面。
第一步：确认是不是真丢包
别急着调 MTU 或 sysctl，先用实证说话：
- 进容器执行 ping -M do -s 1472 8.8.8.8（1472 + 28 字节头 = 1500），能通说明路径支持标准 MTU；不通就逐步减小 -s 值（比如试 1420、1372），找到最大能通的载荷，加 28 得出实际路径 MTU（例如 1420+28=1448 → 取整为 1450）
- 查宿主机网卡 MTU：ip link show eth0 | grep mtu；查 docker0：ip link show docker0 | grep mtu；两者不一致就是错配起点
- 看内核日志：dmesg | grep "too long"。出现 “dropped packet, size 1514 > 1450” 这类提示，就是 MTU 超限丢包的铁证
- 对比容器状态：docker inspect <container> 查 State.Status，再和 Swarm Manager 或 Kubernetes 的任务状态比对。若容器内进程正常（ps aux 有服务）、但平台标记为 failed，大概率是心跳超时引发的误重建，不是真丢包
第二步：检查基础连通性与转发能力
很多“不通”其实卡在最底层：
- 确认宿主机 IP 转发已开启：cat /proc/sys/net/ipv4/ip_forward，输出应为 1；不是就临时打开：echo 1 > /proc/sys/net/ipv4/ip_forward，永久生效需写入 /etc/sysctl.conf
- 检查 NAT 规则是否缺失：iptables -t nat -L -n | grep MASQUERADE，应有类似 MASQUERADE all -- 172.17.0.0/16 0.0.0.0/0 的规则；没有说明 Docker 的 NAT 被清掉，重启 Docker 通常可恢复
- 警惕 firewalld 干扰（尤其 CentOS）：systemctl stop firewalld 临时关闭测试；若恢复，则需配置 docker zone 或切换为 iptables 管理
第三步：定位通信范围与命名空间问题
明确“不通”发生在哪一层，避免盲目排查：
- 同一台宿主机上容器互访：先确认是否在同一个网络：docker inspect 容器A --format '{{.NetworkSettings.Networks}}'；默认 bridge 网络不支持容器名解析，只能用 IP ping，需先查目标容器 IP：docker inspect 容器B --format '{{.NetworkSettings.IPAddress}}'
- 跨主机通信失败：重点查 overlay 网络状态，docker network inspect my-overlay 看是否所有节点都在线；Swarm 场景下运行 docker node ls，Kubernetes 下查 CNI 插件 Pod 状态（如 kubectl get pods -n kube-system | grep calico）
- DNS 解析失败：进容器执行 cat /etc/resolv.conf，检查 nameserver 是否指向有效地址（如 8.8.8.8 或集群 CoreDNS VIP）；若为 127.0.0.11 且服务异常，可能 dnsmasq 未启动，重启 Docker 或显式配置 DNS
第四步：用 tcpdump 抓包直击数据流
眼见为实，抓包能快速判断问题在哪个环节：
- 在容器内抓包（推荐）：docker exec -it <container> tcpdump -i eth0 -w /tmp/out.pcap host 10.0.0.1 and port 80
- 若无任何包发出：检查应用是否绑定正确端口（docker port <container>）、容器是否监听 0.0.0.0 而非 127.0.0.1
- 有 SYN 无 ACK：可能是目标服务未监听、防火墙拦截，或安全组未放行对应端口（如 Calico 默认用 9901，Flannel 用 8472 UDP）
- 能抓到包但应用无响应：问题大概率在应用层（如连接池耗尽、线程阻塞），而非网络本身
