容器dns解析失败本质是域名到ip转换链路中断，需先执行cat /etc/resolv.conf、ping -c 2 8.8.8.8、nslookup google.com 8.8.8.8三步定位，再按场景选择docker run --dns、修改daemon.json或挂载resolv.conf等修复方式。
容器里执行 ping google.com 报 unknown host，或 curl 提示 could not resolve host，这类报错几乎不涉及网络连通性本身，而是 dns 解析链路中断。关键不是“连不上”，而是“找不到地址”。修复重点在于让容器拿到可用、可信、不被过滤的 dns 服务器地址。
常见报错现象与对应根因
以下报错不是孤立错误码，而是 DNS 配置异常在不同命令下的外在表现：
- ping: unknown host xxx：/etc/resolv.conf 中无有效 nameserver，或所有 nameserver 均不可达（如只写了 127.0.0.1 且宿主机未运行本地 DNS 服务）
- curl: (6) Could not resolve host: xxx：解析超时，常见于 nameserver 存在但响应慢或被防火墙拦截（尤其 UDP 53 端口）
- nslookup google.com 会卡住或返回 timeout：上游 DNS 服务无响应，或容器内 resolv.conf 被静默覆盖为仅含 127.0.0.11 但 Docker 内置 DNS 服务异常
- nslookup google.com 8.8.8.8 正常，但不带 IP 就失败：说明容器自身 DNS 配置失效，但外部 DNS 可用——问题锁定在 /etc/resolv.conf 内容或继承逻辑
三步快速验证与定位
无需重启服务，进容器执行三行命令即可判断问题层级：
- 查看当前 DNS 配置：
cat /etc/resolv.conf—— 若为空、只有 127.0.0.11、或含 127.0.0.1/::1 且宿主机没跑 dnsmasq/systemd-resolved，则大概率是配置源头问题 - 测试基础连通性：
ping -c 2 8.8.8.8—— 成功说明网络层通，失败则先查路由、iptables、NAT - 绕过本地配置直连 DNS：
nslookup google.com 8.8.8.8—— 成功说明 DNS 服务可用，只需修正 resolv.conf；失败则检查宿主机防火墙或上游 DNS 可达性
按场景选择最简修复方式
不追求“一劳永逸”，而是匹配当前环境快速见效：
-
单次调试或开发机临时解决：启动时指定 DNS，例如
docker run --dns 8.8.8.8 --dns 1.1.1.1 alpine ping -c 3 google.com -
所有容器统一生效（推荐生产环境）：编辑
/etc/docker/daemon.json，加入{"dns": ["8.8.8.8", "1.1.1.1"]}，然后sudo systemctl restart docker -
宿主机 DNS 可靠且需完全一致（如内网域名）：挂载只读 resolv.conf，
docker run -v /etc/resolv.conf:/etc/resolv.conf:ro alpine cat /etc/resolv.conf -
使用自定义网络且需固定 DNS：创建网络时指定，
docker network create --dns 10.0.0.2 mynet，后续容器加入该网络即自动继承
特别注意两个易忽略细节
很多修复失败，是因为踩中了这两个默认行为：
- Docker 在桥接网络（bridge）下，会自动过滤掉宿主机 resolv.conf 中的 127.0.0.1 和 ::1，即使你挂载了文件，它也可能被覆盖。若必须保留本地 DNS（如 systemd-resolved），需在 daemon.json 中显式配置
"dns"并配合"dns-opt": ["ndots:2"] - host 网络模式下，/etc/resolv.conf 是 bind mount，不是拷贝，修改宿主机该文件会实时影响所有 host 模式容器，但也意味着容器无法独立配置 DNS
