升级Docker后容器网络故障需分层排查：一查IP连通性（ping 8.8.8.8），确认ip_forward和MASQUERADE规则；二查DNS解析（cat /etc/resolv.conf、nslookup），必要时--dns覆盖；三查服务端口（curl/nc），验证TCP可达；四对比bridge子网、cgroup版本及docker日志，重启容器生效新规则。
升级 Docker 后，容器网络行为可能因内核模块、iptables 规则变更或默认 bridge 配置调整而受影响。验证容器内部对外部网络的连通性，关键不是“重试一次 ping”，而是分层排查——从基础 IP 连通、DNS 解析、到目标服务端口可达，逐级确认是否真正可用。
一、快速验证基础 IP 连通性（排除 NAT 和路由问题）
直接测试能否到达公网 DNS 或网关 IP，绕过域名解析干扰：
- 运行临时容器执行 ping：
docker run --rm alpine ping -c 3 8.8.8.8
✅ 成功：说明容器有出向 IP 路由和 NAT 转发能力。
❌ 失败：检查宿主机ip_forward是否启用（cat /proc/sys/net/ipv4/ip_forward应为1），以及iptables -t nat -L POSTROUTING是否存在 MASQUERADE 规则。
二、验证 DNS 解析是否正常（常见升级后故障点）
Docker 24+ 对 /etc/resolv.conf 的默认行为更严格，尤其在使用 systemd-resolved 的系统上容易出错：
- 进入运行中容器检查 DNS 配置：
docker exec -it <容器名> cat /etc/resolv.conf
正常应含
nameserver 8.8.8.8或宿主机有效的 DNS 地址（如127.0.0.53）。若为空或指向127.0.0.11（Docker 内置 DNS）但解析失败，可临时覆盖：docker exec -it <容器名> nslookup google.com 8.8.8.8
✅ 成功：说明 DNS 服务可用；❌ 失败：需在
docker run时加--dns 8.8.8.8，或修改/etc/docker/daemon.json设置"dns": ["8.8.8.8"]并重启 Docker。
三、验证目标服务端口是否可达（真实业务场景）
仅 ping 通不代表应用能访问。用 telnet 或 curl 测试具体服务：
- 测试 HTTPS 站点（带证书校验）：
docker run --rm alpine sh -c "apk add --no-cache curl && curl -Is https://httpbin.org | head -1"
- 测试数据库端口（如 PostgreSQL 默认 5432）：
docker run --rm alpine nc -zv google.com 443
✅ 返回
succeeded表示 TCP 握手成功；❌ 则可能是防火墙拦截、代理配置缺失，或宿主机 iptables FORWARD 链被 DROP。
四、对比升级前后网络行为（定位变更影响）
如果升级前正常、升级后异常，重点查：
-
docker network inspect bridge中IPAM.Config.Subnet是否变化（避免与宿主机网段冲突） -
docker info | grep -i cgroup确认是否切换为 cgroup v2，某些旧内核需手动适配 - 查看 Docker 日志是否有
Failed to setup IP tables类警告：journalctl -u docker.service --since "1 hour ago" | grep -i "network\|iptables"
不复杂但容易忽略的是：Docker 升级后不会自动重启现有容器，新网络规则只对新建容器生效。老容器仍运行在旧网络栈上，建议升级后重启关键容器或重建网络。
