路由策略配置错误会导致容器无法访问外部网络、跨容器通信中断或宿主机与容器互访失败，本质是数据包未按预期路径转发，常见于iptables规则冲突、自定义网桥路由缺失或容器默认网关配置异常，需分层验证：先通宿主机网关、再查出网能力、最后测服务可达性。

路由策略配置错误会导致容器无法访问外部网络、跨容器通信中断，或宿主机与容器互访失败。问题本质是数据包在 Linux 网络栈中未按预期路径转发，常见于 iptables 规则冲突、自定义网桥路由缺失、或容器默认网关配置异常。解决关键在于分层验证：先确认容器能否通宿主机网关，再查能否出网，最后看服务间是否可达。

确认容器默认网关和路由表

容器启动后会自动配置默认路由，但若使用自定义子网或手动指定 --ip，可能遗漏网关设置。

• 进入容器执行 ip route show，检查是否存在类似 default via 172.18.0.1 dev eth0 的条目（网关地址需匹配所在网络的 Gateway 字段）
• 用 docker network inspect your-network-name 查看该网络的 IPAM.Config.Gateway 值，确保与容器内路由一致
• 若缺失默认路由，可在启动时显式指定：--ip 172.18.0.10 --gateway 172.18.0.1

检查 iptables NAT 和 FORWARD 链规则

Docker 依赖 iptables 实现 SNAT（出向）和 DNAT（入向），若规则被清空、屏蔽或顺序错乱，路由即失效。

Docker Image Puller

使用 Python 脚本下载 Docker 镜像并打包为 tar 文件。用户说“下载镜像”“拉取镜像”“pull xxx”“帮我下载 nginx 镜像”等时触发。支持 SOCKS5 代理直连（推荐）和国内镜像站加速两种模式。

下载

• 运行 sudo iptables -t nat -L -n | grep MASQUERADE，确认存在类似 MASQUERADE all -- 172.18.0.0/16 0.0.0.0/0 的规则（对应你的自定义网段）
• 执行 sudo iptables -L FORWARD -n，检查是否有 ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED 及允许 bridge 子网互访的规则
• 若规则缺失，重启 Docker 服务通常可自动重建；若被第三方工具覆盖，需手动添加或调整防火墙策略

验证跨网络路由与多网卡场景

当容器加入多个网络（如同时连 bridge 和 overlay），或宿主机有多个物理网卡时，Linux 内核可能选择错误出口接口。

• 在容器内执行 ip rule show 和 ip route show table local，排查是否存在非默认路由策略干扰
• 若宿主机有双网卡（如 eth0 上网、eth1 内网），确保 docker0 或自定义网桥绑定到正确网卡对应子网
• 必要时在 daemon.json 中配置 "bip": "172.18.0.1/16" 固定网桥地址，并避免与宿主机其他子网重叠

调试 DNS 与应用层路由依赖

看似路由问题，实则常因 DNS 解析失败导致连接超时，尤其在使用服务名调用时易被误判为路由不通。

• 在容器内运行 nslookup mysql（假设服务名为 mysql），确认能否解析出 IP；若失败，优先检查 DNS 配置而非路由
• 临时绕过 DNS 测试真实路由：curl -v http://172.18.0.3:3306（用实际 IP 替换），若成功说明是 DNS 问题，不是路由策略错误
• 对 PHP 应用特别注意：cURL 默认启用 DNS 缓存，可加 CURLOPT_DNS_CACHE_TIMEOUT => 0 避免旧缓存干扰诊断