容器网络超时核心在宿主机，需依次排查ipv4转发、dns配置、iptables nat规则及docker0网桥状态：先ping 8.8.8.8和nslookup验证基础连通性与dns，再查ip_forward值、resolv.conf内容、postrouting masquerade规则及docker0是否存在有效ip。
容器网络连接超时，核心问题不在容器内部，而在于宿主机的网络转发、DNS 解析、iptables 规则和 Docker 网络配置这四个关键环节。只要按顺序验证并修复，90% 的超时问题都能快速定位。
先确认容器基础连通性与 DNS 是否正常
进入容器后别急着 curl，先分层验证：
- 执行 ping -c 3 8.8.8.8：若失败，说明 IP 层不通，问题在 docker0 网桥、内核转发或物理网卡链路
- 执行 nslookup google.com 或 dig google.com +short：若超时或返回 NXDOMAIN，大概率是 DNS 配置错误
- 检查 /etc/resolv.conf：Docker 默认应写入 nameserver 127.0.0.11（内置 DNS）；若被覆盖为不可达地址（如公司内网 DNS），需通过 --dns 8.8.8.8 启动容器，或在 daemon.json 中全局配置
检查 docker0 网桥与 IPv4 转发是否启用
bridge 模式下，docker0 是所有容器出向流量的必经出口：
- 运行 ip addr show docker0：必须存在且有有效 IPv4 地址（如 172.17.0.1/16）；若无输出，说明网桥未初始化，可尝试 systemctl stop docker && iptables -t nat -F && systemctl start docker
- 运行 cat /proc/sys/net/ipv4/ip_forward：返回值必须为 1；临时开启用 sysctl -w net.ipv4.ip_forward=1，永久生效则追加到 /etc/sysctl.conf 并执行 sysctl -p
- 某些系统（如 CentOS + NetworkManager）还需确保出口网卡也开启转发：echo 1 > /proc/sys/net/ipv4/conf/eth0/forwarding
验证 iptables NAT 规则是否完整
Docker 依赖 SNAT 规则将容器源 IP 替换为宿主机 IP，否则外网无法回包：
- 运行 iptables -t nat -S POSTROUTING | grep docker：正常应看到类似 -A POSTROUTING -s 172.17.0.0/16 ! -o docker0 -j MASQUERADE
- 若缺失，手动补一条（替换 eth0 为你的实际出口网卡）：iptables -t nat -A POSTROUTING -s 172.17.0.0/16 -o eth0 -j MASQUERADE
- 使用 firewalld 的系统，需额外启用伪装：firewall-cmd --add-masquerade --permanent && firewall-cmd --reload
区分网络模式，缩小排查范围
不同模式下超时原因完全不同，不能一概而论：
- bridge 模式（默认）：重点查 docker0、iptables FORWARD 链、IP 转发；可临时设 iptables -P FORWARD ACCEPT 快速验证是否策略拦截
- host 模式：容器直接复用宿主机网络栈，此时超时等同于宿主机自身网络问题——直接在宿主机上复现请求即可定位（如代理设置、hosts 干扰、出向限速）
- 自定义 bridge 或 macvlan：检查子网是否与物理网段冲突、网关是否可达、ARP 表是否完整（ip neigh show）
