容器可以正常启动，却在访问域名时长时间等待，最终出现“解析超时”或“无法解析主机名”，这是 Docker 运维中较常见的网络故障之一。🔍 排查时不要急着更换公共 DNS，应先区分基础网络、DNS 转发、容器配置和防火墙策略，避免临时修改掩盖真正原因。
一、先理解 Docker 的 DNS 解析路径
容器的 DNS 行为与网络模式有关。使用默认 bridge 网络时，容器通常根据 Docker 生成的 /etc/resolv.conf 访问外部名称服务器；连接到用户自定义网络后，容器一般通过 Docker 内置 DNS 完成容器名称发现，并由其转发外部域名查询。Docker 官方也建议在自定义网络中使用容器名通信，而不是依赖可能变化的容器 IP，具体可参考 Docker 网络文档。
因此，容器中出现 nameserver 127.0.0.11 不一定是异常，它通常代表 Docker 内置 DNS。真正需要关注的是查询能否被顺利转发到上游名称服务器，以及上游 DNS 是否允许来自 Docker 网桥或宿主机的请求。
二、确认是 DNS 故障还是整体断网
首先进入故障容器，分别测试 IP 连通性和域名解析。可依次执行以下命令：
docker exec -it 容器名 sh
cat /etc/resolv.conf
ping -c 2 1.1.1.1
nslookup example.com
getent hosts example.com
如果 IP 地址能够访问，但域名无法解析，问题大概率位于 DNS 环节；如果 IP 同样不可达，应优先检查容器路由、网桥、NAT、宿主机转发和安全策略。需要注意，部分环境会禁用 ICMP，因此 ping 失败不能单独证明网络中断，还可以使用 curl、nc 或应用实际使用的 TCP 端口交叉验证。
对比宿主机与容器配置
在宿主机执行 cat /etc/resolv.conf，再与容器内文件比较。如果宿主机能解析、容器不能解析，应查看容器中的 nameserver 是否为不可达地址、旧地址或仅在宿主机网络命名空间有效的本地监听地址。使用 systemd-resolved 的系统还可执行 resolvectl status，核对真实上游 DNS、接口绑定关系和搜索域。
三、逐项检查常见超时原因
- 上游 DNS 不可达：企业内网 DNS 可能只允许指定网段访问，而 Docker 网桥流量被防火墙拒绝。
- VPN 改写路由：连接或断开 VPN 后，宿主机 DNS、路由表和访问控制发生变化，但已有容器仍保留旧配置。
- 防火墙拦截：UDP 53 或 TCP 53 被 nftables、iptables、安全软件或云端访问控制规则阻断。
- 搜索域配置不当：过多的 search 域或较大的 ndots 值可能产生多次无效查询，使应用表现为间歇性超时。
- 网络模式理解错误：默认 bridge、自定义网络、host 和 none 模式的隔离程度不同，不能直接套用同一排查结论。
还应检查 Docker 日志和网络详情，例如执行 journalctl -u docker、docker inspect 容器名、docker network inspect 网络名。如果仅某个容器异常，应比较它与正常容器的网络、DNS 参数、镜像基础系统和启动时间。
四、按作用范围配置自定义名称服务器
临时验证：仅为单个容器指定 DNS
为了快速验证上游名称服务器是否可用，可以启动测试容器：
docker run --rm --dns 10.0.0.53 --dns 10.0.0.54 alpine nslookup example.com
其中地址应替换为组织批准且能从宿主机和 Docker 网络访问的 DNS。✅ 若测试成功，说明问题多半与原容器继承或生成的 DNS 配置有关。不要在不了解合规要求时直接使用公共 DNS，因为内部域名可能无法解析，查询也可能绕过企业安全策略。
Compose 服务级配置
使用 Compose 时，可在对应服务下设置名称服务器。修改后通常需要重新创建容器，而不是只在容器内部编辑 resolv.conf：
services:
app:
image: your-image
dns:
- 10.0.0.53
- 10.0.0.54
Compose 会为项目创建网络，并支持通过服务名发现同一网络中的服务，相关机制可查看 Compose 网络说明。
全局配置 Docker 守护进程
如果所有新建容器都需要统一 DNS，可编辑宿主机的 /etc/docker/daemon.json：
{
"dns": ["10.0.0.53", "10.0.0.54"]
}
修改前应先备份原文件，并使用 dockerd --validate --config-file=/etc/docker/daemon.json 检查语法。随后重启 Docker 服务，再重新创建测试容器。⚠️ 重启 Docker 可能影响运行中的业务，生产环境应安排维护窗口并确认容器的自动恢复策略。
五、验证修复并防止问题复发
- 检查新容器的 /etc/resolv.conf，确认配置符合预期。
- 分别测试内部域名、外部域名和容器服务名，避免只验证单一场景。
- 连续执行多次查询，观察是否仍有间歇性超时。
- 记录 DNS 地址来源、适用网络、变更时间和回滚方法。
- 监控解析延迟、失败率及 Docker 服务日志，及时发现 VPN、DHCP 或网络策略变更。
总结
Docker 容器 DNS 超时应遵循“先分层、后修改”的原则：先验证 IP 连通性，再检查容器 resolv.conf、Docker 网络模式、宿主机上游 DNS和端口策略，最后根据影响范围选择 --dns、Compose 配置或 daemon.json。🛠️ 自定义名称服务器不是越多越好，关键是地址可达、策略合规、内部域名可解析，并在变更后通过新建容器和多场景查询完成验证。
