核心是绕过Docker内置DNS劫持，使内网域名走真实解析路径；可通过验证服务名冲突、使用extra_hosts、指定上游DNS或启用host网络模式解决。

核心在于绕过 Docker 内置 DNS 的“自动劫持”，让内网域名走真实解析路径，而不是被错误映射到某个服务容器 IP 上。

确认是否是服务名冲突导致的 DNS 劫持

Docker Compose 会为每个 service 名（如 auth、mysql）自动注册内部 DNS 记录。如果你的内网域名恰好叫 auth.company.local，而 Compose 文件里又定义了 auth: 服务，Docker 就会把所有对 auth.company.local 的请求都指向该服务在 bridge 网络里的容器 IP，而非你期望的内网 DNS 服务器返回的真实地址。

验证方法：进容器执行

dig auth.company.local @127.0.0.11

如果返回的是 172.x.x.x 类似网段的 IP，且不是你内网 DNS 应该给的结果，基本就是这个原因。

用 extra_hosts 避开 DNS 解析链路

这是最直接、不依赖外部 DNS 服务的方案。它让容器跳过 DNS 查询，直接查 /etc/hosts 映射。

• 在 docker-compose.yml 中为对应服务添加：

extra_hosts:
- "auth.company.local:10.1.2.3"
- "api.internal:10.1.2.4"

注意：IP 必须是宿主机能访问到的内网真实地址，不能是容器 IP 或 127.0.0.1；该配置只对当前服务生效，不污染其他容器。

Docker Compose Optimizer

优化 Docker Compose 配置，适用于开发和生产环境——审计服务、网络、卷、健康检查和资源管理。

下载

指定上游 DNS 并禁用内置服务名解析

让容器完全不走 Docker 的 127.0.0.11，而是直连你的内网 DNS 服务器（比如 10.0.0.1），同时避免服务名干扰：

• 在服务配置中显式设置 dns 和 dns_search：

dns:
- 10.0.0.1
dns_search:
- company.local
- internal

这样容器会优先向 10.0.0.1 发起查询，且 auth 这类短名也会自动补全为 auth.company.local，减少歧义。

启用 host 网络模式（仅限开发/调试）

让容器共享宿主机网络命名空间，直接复用宿主机的 /etc/resolv.conf 和 hosts 映射：

network_mode: "host"

⚠️ 注意：这会失去网络隔离，生产环境禁用；且容器端口需避开宿主机已占用端口；适用于快速验证内网域名是否本机就能通。