容器里的 DNS：为什么宿主机正常，应用却解析失败

> 日期说明：归档日期为历史整理日期，不代表原始首发时间；本文于 2026-11-02 核对并修订。命令示例需按实际环境替换占位符。


同一台服务器上，宿主机能访问网站，容器里的程序却提示域名解析失败，并不矛盾。容器有自己的文件系统与网络配置，需要独立确认解析链路。

## 从 resolv.conf 开始

先看宿主机的 `/etc/resolv.conf`，再运行 `docker exec 容器名 cat /etc/resolv.conf`。这里的 nameserver 指定解析服务器。如果文件没有有效解析器，不同语言运行时可能使用不同的默认行为。

<!-- more -->

## localhost 的含义取决于网络模式

桥接网络里的 127.0.0.1 指向容器自身。把宿主机的本地 DNS 地址照搬进去，经常会失败。host 网络共享宿主机网络空间，但仍要检查容器内的解析配置文件是否有效。

## 分清 DNS 与 HTTPS 故障

“lookup failed”通常发生在建立连接之前；“certificate verify failed”发生在 TLS 校验阶段；“connection refused”则表示连接目标没有接受请求。把这些错误混为一谈，会导致改错配置。

## 先验证，再持久化

可以先在容器内做解析与 HTTPS 请求测试。确认可用后，把 DNS 配置写入 Compose，例如：

```yaml
services:
  app:
    image: your-image:tag
    dns:
      - 1.1.1.1
      - 8.8.8.8
```

这只是格式示例。实际应优先使用所在云平台或网络中可达、可信的解析器；公共 DNS 不一定能解析私有域名。

## 变更后再做一次完整请求

解析出地址只是第一步，还应确认 TCP、TLS 与应用响应。临时修改容器文件容易在重建后丢失，最终配置应放回部署文件，并保留变更记录。


## 操作参考与适用边界

### 比较宿主机和容器解析配置

```sh
cat /etc/resolv.conf
docker exec CONTAINER cat /etc/resolv.conf
docker inspect CONTAINER --format '{{json .HostConfig.Dns}}'
```

Docker 自定义网络可能使用内置 DNS 地址，不能看到本地地址就认定故障。应从容器内实际解析域名，并结合网络模式判断。

### 如何判断结果

操作后应将实际结果与文中目标对照；命令成功退出只能证明该步骤完成，不能替代业务层验证。记录异常信息时，保留时间、软件版本与相关上下文，方便后续复查。

## 参考资料

- [官方文档与规范](https://docs.docker.com/engine/network/)（本次整理参考，页面内容可能随版本更新）
- [继续阅读本站归档](/archives/)