路由策略配置错误会导致容器无法访问外部网络、跨容器通信中断或宿主机与容器互访失败，本质是数据包未按预期路径转发，常见于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（入向），若规则被清空、屏蔽或顺序错乱，路由即失效。
- 运行 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 避免旧缓存干扰诊断
