Go DNS 解析在本机和容器里为什么不同

Go 程序在本机能解析域名，放进容器却出现 no such host、超时或解析到不同地址，通常不是 Go “随机换了 DNS”。更常见的原因是：容器拥有独立的网络命名空间和一份不同的 /etc/resolv.conf，而 Go 还可能根据系统配置选择纯 Go resolver 或 cgo resolver。

先把问题拆成三层：输入、解析器和网络出口

排查时可以把 DNS 看成三层。第一层是文件输入：/etc/hosts、/etc/resolv.conf 以及其中的 nameserver、search 和 options。第二层是 Go 的解析器选择：Unix 系统上，net 可能使用纯 Go resolver，也可能调用 cgo。第三层才是网络出口：容器能不能从自己的网络命名空间访问那个 nameserver。

因此，本机和容器的差异只要出现在任意一层，就可能得到不同结果。先判断是哪一层不同，修复会比直接设置一个环境变量稳得多。

为什么容器里的 nameserver 不能照搬本机回环地址

容器与宿主机不是同一个网络命名空间。Docker 文档说明，默认 bridge 网络会给容器复制一份 DNS 配置；自定义网络则通常使用 Docker 内置 DNS，并由它转发到宿主机配置的上游服务器。也就是说，宿主机上的 127.0.0.1、127.0.0.53 或某个本地缓存服务，在容器里仍然表示“容器自己”，不一定存在 DNS 服务。

可以先在两侧只看配置，不急着运行应用代码：

# 中文注释：先比较两侧的解析输入，重点看 nameserver 和 search
cat /etc/hosts
cat /etc/resolv.conf

# 中文注释：容器内查看同样的文件；alpine 只是示例镜像
docker run --rm alpine sh -c 'cat /etc/hosts; echo ---; cat /etc/resolv.conf'

如果宿主机显示本地回环 DNS，而容器显示不可达的同一地址，根因已经基本明确。若两侧配置不同但都可达，再继续判断 Go resolver 的选择和搜索域行为。

用 Go 的解析器信息缩小差异范围

Go 官方 net 文档说明，resolver 会综合系统文件和环境配置决定使用纯 Go 或 cgo 路径。GODEBUG=netdns=go+1、GODEBUG=netdns=cgo+1 可以临时打印选择信息；它们是诊断开关，不是“容器修复参数”。

package main

import (
    "context"
    "fmt"
    "net"
    "os"
)

func main() {
    // 中文注释：显式使用当前环境的默认解析器，便于对比宿主机与容器输出。
    resolver := net.DefaultResolver
    host := "internal.example"
    addrs, err := resolver.LookupHost(context.Background(), host)
    if err != nil {
        // 中文注释：保留原始错误，区分超时、无此主机和系统解析失败。
        fmt.Fprintf(os.Stderr, "lookup %s failed: %v\n", host, err)
        os.Exit(1)
    }
    fmt.Printf("%s => %v\n", host, addrs)
}

同一个二进制分别在宿主机和容器里运行时，把 GODEBUG=netdns=1 的诊断信息、resolv.conf 和错误类型放在一起比较。只看“能不能解析”不够，还要看是否走了不同的 nameserver、search 域或 hosts 条目。

把排查结果收敛成可复用的配置

修复顺序建议固定下来：先让容器获得可达的 DNS，再决定是否需要 Go resolver 级别的控制。Docker 场景可以通过运行参数或编排文件提供明确的 dns；不要把宿主机的回环地址原样写进容器配置。内部服务则优先使用容器网络中的服务名或完整域名，并确认 search 域符合预期。

只有在确实需要指定 DNS 出口时，才在代码里使用带 Dial 的 net.Resolver。下面的地址只适用于 Docker 自定义网络的容器示例，不能复制到宿主机：

resolver := &net.Resolver{
    PreferGo: true,
    // 中文注释：把查询发到容器网络中可达的 DNS，不使用宿主机回环地址。
    Dial: func(ctx context.Context, network, _ string) (net.Conn, error) {
        dialer := net.Dialer{Timeout: 2 * time.Second}
        return dialer.DialContext(ctx, network, "127.0.0.11:53")
    },
}

// 中文注释：生产代码还应处理超时，并根据部署环境注入 DNS 地址。
ips, err := resolver.LookupHost(ctx, "service.internal")

这个例子需要导入 context、net 和 time，并且 127.0.0.11 只代表特定 Docker 网络环境。更通用的做法是把 DNS 地址作为部署配置注入，代码只负责超时、错误和重试边界。

常见误区与速查表

不要把 GODEBUG=netdns=go 当成万能修复，也不要只在镜像构建阶段检查 DNS。最终检查应在与应用相同的网络模式、相同的运行时环境和相同的配置注入方式下完成。

相关问题

容器里能解析公网域名，为什么解析不了公司内网域名？

公网 DNS 可达不代表内网 DNS 可达。检查容器实际使用的 nameserver 是否包含能解析内部区域的服务器，并确认网络策略允许访问它。

设置 PreferGo 就能解决容器 DNS 吗？

不能。PreferGo 只影响 Go resolver 的偏好，不能让容器访问一个本来不可达的 DNS 地址；先修正网络出口和 resolv.conf。

为什么同一个域名在两边解析出不同 IP？

两侧可能使用了不同上游 DNS、search 域、hosts 条目或网络视图。把两侧输入文件、resolver 诊断信息和最终 nameserver 一起比较，才足以判断差异来源。

把问题按“输入配置—解析器—网络出口”三层拆开，通常就能解释本机与容器的不同结果，也能避免用一个临时环境变量掩盖真正的部署配置问题。