Go httptrace 怎样判断 DNS 查询是否发生

我第一次用 Go 排查 HTTP 请求变慢时，最先想到的是“是不是 DNS 慢了”。但把 httptrace.ClientTrace 接上以后，最容易误判的情况反而是：日志里根本没有 DNSStart 和 DNSDone。这不一定表示 DNS 出错，也可能表示 Transport 直接拿到了已经建立的连接。

判断一次请求是否发生 DNS 查询，先看是否进入 DNSStart/DNSDone，再用 GotConnInfo.Reused 判断是否走了复用连接路径。没有 DNS 回调时，不能单独把它当成故障。

官方地址：https://pkg.go.dev/net/http/httptrace

回调顺序就是一条请求时间线

httptrace 给 HTTP 客户端请求提供阶段回调。和本文问题最相关的有三组：DNSStart/DNSDone 观察 DNS 查询开始和结束，ConnectStart/ConnectDone 观察新连接建立，GotConn 说明 Transport 已经拿到连接。它们是观察点，不是完整的请求耗时统计器。

因此，最小判断逻辑可以写成：出现 DNSStart 说明本次请求进入了 DNS 阶段；出现 DNSDone 说明该阶段返回了结果或错误；如果两者都没有出现，则继续看 GotConn 的 Reused 字段。

把 DNS 回调接到请求上下文

下面的例子只记录判断所需的事件。回调可能在不同 goroutine 中触发，所以共享状态要加锁；请求也要有超时，避免排查代码本身一直等待。

package main

import (
    "context"
    "fmt"
    "net/http"
    "net/http/httptrace"
    "sync"
    "time"
)

func requestWithTrace(parent context.Context, client *http.Client, url string) error {
    ctx, cancel := context.WithTimeout(parent, 8*time.Second)
    defer cancel() // 请求结束后释放计时器，避免短请求留下定时器

    var mu sync.Mutex
    dnsStarted := false
    trace := &httptrace.ClientTrace{
        DNSStart: func(info httptrace.DNSStartInfo) {
            mu.Lock()
            dnsStarted = true
            mu.Unlock()
            fmt.Printf("DNS start: host=%s\\n", info.Host)
        },
        DNSDone: func(info httptrace.DNSDoneInfo) {
            // Err 表示 DNS 阶段错误，Coalesced 表示结果是否被并发请求共享。
            fmt.Printf("DNS done: addrs=%d err=%v coalesced=%v\\n", len(info.Addrs), info.Err, info.Coalesced)
        },
        GotConn: func(info httptrace.GotConnInfo) {
            // Reused=true 时优先解释为连接复用，不要期待必然出现 DNS 回调。
            fmt.Printf("got conn: reused=%v idle=%v\\n", info.Reused, info.WasIdle)
        },
    }

    req, err := http.NewRequestWithContext(httptrace.WithClientTrace(ctx, trace), http.MethodGet, url, nil)
    if err != nil {
        return fmt.Errorf("create request: %w", err)
    }
    resp, err := client.Do(req)
    if err != nil {
        return fmt.Errorf("send request: %w", err)
    }
    defer resp.Body.Close() // 及时归还可复用的连接资源

    mu.Lock()
    fmt.Printf("dns callback observed=%v status=%s\\n", dnsStarted, resp.Status)
    mu.Unlock()
    return nil
}

这里的 dnsStarted 只回答“有没有进入 DNSStart”，不是回答“DNS 是否命中缓存”。如果要判断 DNS 阶段是否报错，应读取 DNSDoneInfo.Err；如果要解释为什么没有回调，则把 GotConnInfo.Reused 一起记录。

没有 DNS 回调不等于请求失败

第一次请求通常可能经历解析和建连，回调链更接近 DNSStart → DNSDone → ConnectStart → ConnectDone → GotConn。当 Transport 取到空闲连接时，请求可以直接进入 GotConn，这条路径没有新的 DNS 查询，因此没有 DNS 回调是合理现象。

判断时可以按下面的组合看：

我会特别保留的三个边界

第一，ClientTrace 的回调可能并发触发，日志收集器不能假定所有事件都在同一个 goroutine 中。第二，GotConnInfo.Conn 由 Transport 管理，业务代码只读取状态，不自行关闭它。第三，响应体仍然要关闭；复用连接的判断依赖正确的响应生命周期，不能把 httptrace 当成连接池管理器。

如果使用自定义 RoundTripper 或代理，先确认请求上下文确实带上了 httptrace.WithClientTrace，再判断回调路径。重定向、重试和并发 DNS 合并也会让日志看起来不像一条简单直线，最好给每个请求设置自己的 request ID。

最小排查清单

1. 确认 ClientTrace 通过 WithClientTrace 放进了实际发送的请求上下文。
2. 同时记录 DNSStart、DNSDone.Err 和 GotConn.Reused，不要只记录一个布尔值。
3. 没有 DNS 回调时，先区分复用连接、代理、自定义 Dial 和请求重试。
4. 给请求设置超时，并在收到响应后关闭 Response.Body。

相关问题

为什么第二次请求看不到 DNSStart？ 常见原因是 Transport 复用了已有连接；先查看 GotConn.Reused。

DNSDone 的 Err 为空就代表网络一定正常吗？ 不代表。它只说明 DNS 阶段没有返回错误，后续连接、TLS、写请求或读取响应仍可能失败。

httptrace 能替代完整链路追踪吗？ 不能。它适合观察单次 HTTP round trip 的客户端阶段，完整跨服务链路仍需要独立的 tracing 方案。