容器dns解析失败本质是/etc/resolv.conf未指向可用dns或解析路径被干扰，需按宿主机、docker守护进程、容器运行时三级配置优先级排查，先用cat和docker inspect确认来源，再依场景选--dns、daemon.json、bind挂载或compose配置修复。
容器内部 DNS 解析失败，本质是 /etc/resolv.conf 没有指向可用的 DNS 服务器，或解析路径被干扰。解决关键不是“换工具”，而是厘清配置优先级、选对生效层级——宿主机、Docker 守护进程、容器运行时三者之间存在明确覆盖关系。
确认当前 DNS 配置来源
先查清问题根源，避免盲目修改：
- 进入容器执行
cat /etc/resolv.conf：若看到nameserver 127.0.0.11，说明用了 Docker 内置 DNS 转发器（可能响应慢或不可靠） - 运行
docker inspect 容器名 | grep -A 5 "Dns\|NetworkMode"，查看实际生效的 DNS 设置和网络模式 - 检查宿主机
/etc/resolv.conf是否含127.0.0.1或::1——Docker 默认会过滤这类本地地址，导致无 DNS 可用
按场景选择修复方式
不同部署阶段适用不同方案，不建议统一硬编码：
-
单次调试或临时验证：启动时加
--dns 8.8.8.8 --dns 114.114.114.114，绕过内置转发器 -
多容器统一管理：修改
/etc/docker/daemon.json，加入{"dns": ["8.8.8.8", "1.1.1.1"]}，然后sudo systemctl restart docker -
必须复用宿主机 DNS（如内网 DNS）：用
--mount type=bind,source=/etc/resolv.conf,target=/etc/resolv.conf,readonly挂载，注意确保宿主机配置本身有效 -
Compose 环境：在
docker-compose.yml的服务下直接写dns和dns_search字段，比全局配置更灵活
验证与辅助诊断
改完别急着重启应用，先做最小化验证：
- 容器内运行
nslookup google.com和nslookup @8.8.8.8 google.com对比，判断是 DNS 服务器问题还是转发链路问题 - 装
bind-tools（Alpine 用apk add bind-tools，Ubuntu 用apt-get install dnsutils），用dig +trace看解析全过程 - 若仍失败，检查是否被 SELinux/AppArmor 或 iptables 拦截：
ausearch -m avc -ts today | grep dns或iptables -L -n -t nat | grep :53
避开常见陷阱
很多问题其实源于“以为生效了，其实没覆盖”：
- 在自定义网络（
docker network create）中，--dns参数无效，必须通过daemon.json或 compose 的dns字段设置 -
docker build阶段的RUN echo ... > /etc/resolv.conf在运行时会被 Docker 自动重写，不持久 - 使用
--network=host时，容器直接共享宿主机网络栈，/etc/resolv.conf是挂载的，但 DNS 查询走的是宿主机策略，需同步检查宿主机防火墙和代理设置
