先在容器内执行 ip route get 8.8.8.8 查看 DNS 请求实际出口网卡，若 dev 显示内网卡（如 eth1）而非外网卡（如 eth0），说明路由错位；再结合 ip rule show 和 ip route show table all 检查策略路由干扰，最后用 nslookup 和 tcpdump 验证请求与响应路径一致性。
确认 DNS 请求实际走哪个网卡
多网卡环境下，容器 dns 请求可能被系统路由策略导向错误接口，导致解析失败或超时。先在容器内执行 ip route get 8.8.8.8，看返回的 via 和 dev 字段——它显示 dns 查询（默认发往 udp 53）会经由哪块网卡发出。若结果中 dev 是内网卡（如 eth1）、而非连外网的那块（如 eth0），说明路由路径已错位。
检查宿主机路由表与策略路由
Docker 容器共享宿主机网络命名空间的部分路由逻辑，尤其在 host 模式或自定义网络使用 --network=host 时。运行 ip rule show 和 ip route show table all，重点找是否存在基于源地址或 fwmark 的策略路由规则，它们可能把来自容器 IP 段的 DNS 流量强制导向了某张内网卡。常见干扰项包括企业级网络管理工具、自定义 firewalld rich rules 或手动添加的 ip rule from 172.18.0.0/16 lookup 100。
验证 DNS 服务器可达性与响应路径一致性
即使 ping 通 DNS 地址，也不代表 DNS 查询能正常往返。在容器中分别执行：
- nslookup google.com 8.8.8.8 —— 直连指定 DNS，绕过 /etc/resolv.conf 链路
- nslookup google.com —— 走默认配置，观察是否超时或返回 SERVFAIL
- tcpdump -i any port 53 -c 4（需安装 tcpdump）—— 看 DNS 请求从哪块网卡发出、响应是否从同一网卡返回；若请求从 eth0 出、响应却从 eth1 进，说明存在 asymmetric routing，防火墙或中间设备常因此丢包
约束容器网络出口行为
避免依赖全局路由决策，主动限定 DNS 流量出口：
- 启动容器时加 --dns 8.8.8.8 --dns 1.1.1.1，跳过 Docker 内置的 127.0.0.11 转发器，减少一层转发不确定性
- 使用 --network=bridge 且不挂载 host 网络时，确保 docker0 网桥所在宿主机接口（通常是 docker0 对应的物理网卡）有正确默认路由；可临时删掉其他网卡的默认路由：ip route del default via x.x.x.x dev eth1
- 若必须用多网卡并行，可在宿主机为容器子网添加明确路由：ip route add 172.19.0.0/16 via dev eth0，保证容器回包路径可控
