Go DNS 查询在容器里超时如何区分网络和解析器

我在容器里遇到过一种很容易误判的故障：Go 服务访问域名超时，宿主机上却能正常解析。这个现象不能直接说明“DNS 挂了”。容器里的 /etc/resolv.conf、网络命名空间、Go 选择的解析器路径，以及 DNS 请求能否到达 nameserver，任何一层都可能单独出问题。

排查时先用容器内的 resolv.conf 确认解析入口，再用带自定义 Dial 的 net.Resolver 记录实际 DNS 服务地址；如果 DNS 已得到 IP，再单独测试到业务端口的连接。这样才能区分“解析器没拿到结果”和“解析成功但业务网络不通”。

先把“DNS 超时”拆成解析线和连接线

一个常见的错误判断是：域名访问超时，所以目标服务的 443 端口不通。实际上，HTTP 客户端通常先解析域名，拿到 IP 后才建立 TCP 连接。前一步没有返回地址时，后一步根本还没开始。

先看错误类型和发生位置。context deadline exceeded 表示调用方给出的时间预算耗尽；*net.DNSError 还能提供名称、服务器和超时属性。它们能帮助定位，但不会替你证明网络策略已经放行。

检查容器内的 resolv.conf 和解析器入口

进入同一个容器查看 /etc/resolv.conf，重点记录 nameserver、search、ndots、timeout 和 attempts。不要只在宿主机执行同名命令：容器运行时可能为每个网络命名空间生成不同的 nameserver。

Go 官方 net 文档说明，Unix 平台有纯 Go resolver 和 cgo resolver 两条路径；纯 Go resolver 会向 /etc/resolv.conf 列出的服务器直接发送 DNS 请求。可以用 GODEBUG=netdns=go+1 临时打印解析器决策，但这只适合诊断，不建议把调试变量永久写入生产环境。

用 net.Resolver 记录实际 DNS 服务地址

为了减少系统 resolver 差异，可以在诊断程序中明确偏好纯 Go resolver，并给它一个自定义 Dial。这个回调接收的地址应当是 DNS 服务器的字面 IP 和端口；它不是业务域名。下面的代码只负责观察和分类错误，示例中的输出是说明格式，不代表某个环境已经实际运行。

package main

import (
    "context"
    "errors"
    "fmt"
    "net"
    "time"
)

func lookup(ctx context.Context, resolver *net.Resolver, host string) error {
    // 记录解析耗时，并把 DNS 层的错误保留给调用方继续判断。
    started := time.Now()
    addrs, err := resolver.LookupHost(ctx, host)
    if err != nil {
        var dnsErr *net.DNSError
        if errors.As(err, &dnsErr) {
            fmt.Printf("dns name=%s server=%s timeout=%v err=%v\n", dnsErr.Name, dnsErr.Server, dnsErr.IsTimeout, dnsErr.Err)
        }
        return err
    }
    fmt.Printf("resolved host=%s addrs=%v cost=%s\n", host, addrs, time.Since(started))
    return nil
}

func main() {
    resolver := &net.Resolver{
        // 让本次诊断优先走 Go 内置 resolver，避免 cgo 路径混入变量。
        PreferGo: true,
        StrictErrors: true,
        Dial: func(ctx context.Context, network, address string) (net.Conn, error) {
            // address 是 DNS 服务端点；记录它可以判断 nameserver 是否真正可达。
            fmt.Printf("dns dial network=%s server=%s\n", network, address)
            dialer := net.Dialer{Timeout: 2 * time.Second}
            return dialer.DialContext(ctx, network, address)
        },
    }

    // 给一次解析设置独立预算，避免诊断程序无限等待。
    ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second)
    defer cancel()
    if err := lookup(ctx, resolver, "service.internal"); err != nil {
        if errors.Is(err, context.DeadlineExceeded) {
            fmt.Println("lookup deadline: inspect DNS path and network policy")
        }
    }
}

如果日志里连 dns dial 都没有，先确认当前 resolver 路径和配置；如果能记录到 nameserver，但连接阶段超时，优先查容器到该 IP 的 UDP/TCP 通路。StrictErrors 会让多子查询中的临时错误更严格地终止整体查询，适合诊断，不要不加评估地改变线上兼容行为。

结合错误类型和直连 IP 做最后一层判断

解析成功后，把域名结果暂存下来，用一个已知端口测试直连 IP；直连测试的目的只是把 DNS 从链路中拿掉，不是绕过服务鉴权或修改业务配置。若直连 IP 也超时，故障更靠近路由、出口、防火墙或 NetworkPolicy；若直连成功而域名调用失败，再回头检查多地址选择、代理、SNI 或业务客户端配置。

对于错误分类，可以先用 errors.As 取出 *net.DNSError，再用 errors.Is 判断上下文是否到期。不要只匹配错误字符串，因为包装层可能变化。若报的是 no such host，更像是响应明确表示名称不存在或搜索域组合失败；若是 i/o timeout，还要结合记录到的 nameserver 判断是请求未发出、无响应，还是重试预算用尽。

把修复动作落到容器配置，而不是只延长超时

确认根因后再修复：nameserver 错误就修运行时网络配置；DNS 服务器可达但搜索域导致查询变慢，就减少不必要的短名称和 search 依赖；解析成功而业务 IP 不通，就处理路由或策略。延长 context 只能改变症状出现的时间，不能修复错误的解析入口。

生产服务可以保留一条轻量启动诊断：输出解析器模式、目标名称、耗时和经过脱敏的 DNS 服务地址，不记录凭据和完整内部拓扑。这样下次出现“宿主机正常、容器超时”，值班人员能先判断是哪一层失效。

常见问题

为什么宿主机能解析，容器里的 Go 却超时？

两者可能使用不同的 resolv.conf、网络命名空间和 DNS 出口策略。先以容器内文件和自定义 Dial 日志为准。

GODEBUG=netdns=go+1 能修复 DNS 超时吗？

不能。它主要帮助观察 Go 选择了哪条 resolver 路径；真正修复仍要回到配置、nameserver 可达性和响应状态。

为什么解析出 IP 后 HTTP 仍然超时？

DNS 已经完成，问题转移到 TCP、代理、TLS、路由或服务端口。使用 IP 做对照测试，再看客户端是否依赖 Host、SNI 或代理。

我会把这类故障固定成“配置入口 → DNS 端点 → 解析响应 → 业务连接”四层记录。每一层都留下一个可观察证据，比把所有超时统一改成更长的等待时间更可靠。