Go DNS 解析慢时怎样区分网络和解析器

我排查 Go 服务的“请求偶尔很慢”时，最容易先盯住 TCP、TLS 或服务端处理时间，但如果目标还是主机名，DNS 解析可能已经占掉了大半等待时间。判断方法不是凭感觉切换一个 DNS，而是把主机名解析和拿到 IP 后的连接拆开计时。

最实用的结论是：LookupIPAddr 很慢、使用字面量 IP 建连很快，优先查解析器和 DNS 服务；解析很快、字面量 IP 建连也慢，问题才更像网络链路或服务端连接阶段。

不要把“Dial 连接慢”和“解析器先把地址解析出来慢”混成一个指标。先分段，再决定修正点。

先把一次慢请求拆成两个计时区间

下面的最小程序只做两件事：第一段调用 net.DefaultResolver.LookupIPAddr 测量解析；第二段取出返回的 IP，使用字面量地址调用 TCP 拨号。第二段不再带主机名，因此不会再次触发 DNS。

package main

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

func main() {
    ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second)
    defer cancel() // 无论成功或超时，都及时释放上下文资源

    host := "example.com"
    lookupStart := time.Now()
    addrs, err := net.DefaultResolver.LookupIPAddr(ctx, host)
    lookupCost := time.Since(lookupStart)
    if err != nil {
        // 解析失败时先保留错误和耗时，不要继续猜测 TCP 问题
        fmt.Printf("lookup cost=%s err=%v\\n", lookupCost, err)
        return
    }
    if len(addrs) == 0 {
        // 没有地址就没有可比较的后续连接阶段
        fmt.Println("lookup returned no address")
        return
    }

    target := net.JoinHostPort(addrs[0].IP.String(), "443")
    dialStart := time.Now()
    conn, err := (&net.Dialer{Timeout: 3 * time.Second}).DialContext(ctx, "tcp", target)
    dialCost := time.Since(dialStart)
    if err != nil {
        // 这里的失败发生在已经拿到 IP 之后，和 DNS 失败要分开记录
        fmt.Printf("lookup=%s dial=%s target=%s err=%v\\n", lookupCost, dialCost, target, err)
        return
    }
    defer conn.Close() // 只做诊断连接，完成计时后立即关闭
    fmt.Printf("lookup=%s dial=%s target=%s\\n", lookupCost, dialCost, target)
}

这段代码的输出不需要拿来和别人的毫秒数比较。重点看两个区间的相对关系：如果 lookup 明显偏大，而 dial 稳定，先查 DNS；反过来则继续看路由、防火墙、目标端口或服务端。

用 net.Resolver 复现并识别解析器路径

net.Resolver 不是一个简单的“DNS 地址字符串”。官方文档里，PreferGo 控制是否优先使用 Go 内置解析器；Dial 则只为 Go 内置解析器访问 DNS 服务时提供替代拨号函数。也就是说，修改 Dial 前要先确认当前请求确实走到了内置解析器。

resolver := &net.Resolver{
    PreferGo: true, // 将本次 Resolver 的选择限定为 Go 内置解析器
    Dial: func(ctx context.Context, network, address string) (net.Conn, error) {
        fmt.Printf("dns network=%s server=%s\\n", network, address)
        d := net.Dialer{Timeout: 800 * time.Millisecond}
        // address 应是 DNS 服务的字面量地址；这里仅记录并转发连接
        return d.DialContext(ctx, network, address)
    },
}

ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second)
defer cancel() // 解析完成或超时后结束本次诊断
ips, err := resolver.LookupIP(ctx, "ip4", "example.com")
if err != nil {
    // errors.Is 或 errors.As 可继续区分超时、DNS 错误等类型
    fmt.Printf("resolver lookup failed: %v\\n", err)
    return
}
fmt.Printf("resolved=%v\\n", ips)

如果这个 Dial 回调完全没有日志，不要马上判定 DNS 没有执行。可能是系统解析器路径、缓存、字面量地址或调用链根本没有使用这个 Resolver。排查时应把“是否调用了目标 Resolver”作为独立证据。

把证据对应到修正动作

我通常按下面的顺序处理，而不是一上来把超时时间调大：

LookupIP 的 network 参数可以明确选择 ip、ip4 或 ip6。这适合确认“只有 IPv6 查询慢”这类边界，但不应把它当成修复所有 DNS 延迟的开关。生产代码还要保留上下文超时，并记录可关联的目标主机、网络类型和错误。

几个容易误判的边界

第一，解析得到多个地址时，拿第一个 IP 做一次 TCP 连接只能说明一个候选地址的情况，不能代表完整的连接策略。第二，DNS 解析和 TLS 握手是不同阶段，本文的第二段只测 TCP 建连，不包含 TLS。第三，手工改 PreferGo 会改变解析器选择，属于诊断和有边界的配置，不应在没有对照数据时直接全局启用。

如果要观察更细的阶段，可以把 HTTP 客户端的 DNS、连接、TLS 和首字节事件分别接入 tracing；但第一步仍然是保留本文的两个最小计时区间，否则后面的细分数据很容易失去对照。

相关问题

为什么直接给 HTTP 客户端加大超时不能证明 DNS 已修好？

超时只是让请求等待更久，不能说明慢点消失。应分别记录解析和连接耗时，再决定调整解析器、DNS 服务或网络链路。

PreferGo 是否等于更快？

不等于。它只是改变 Resolver 的优先路径；不同系统、DNS 配置和网络环境下，快慢需要用同一主机和相同超时做对照。

参考资料

• https://pkg.go.dev/net#Resolver
• https://pkg.go.dev/net#Resolver.LookupIP
• https://go.dev/src/net/lookup.go