Go httptrace DNSStart 没有回调时说明了什么

结论：httptrace.ClientTrace.DNSStart 没有回调，通常只能说明这次请求没有进入一次可被当前 trace 观察到的“主机名解析开始”路径。它不等于 DNS 服务异常，也不能单独证明发生了 DNS 缓存命中。最常见的原因是 Transport 直接复用了连接，其次是目标已经是字面量 IP，或者代理、自定义 DialContext 改变了解析位置。

把 DNSStart 看成“Go 的解析入口开始了”的信号，而不是“网络上一定发出了 DNS 报文”的信号。要判断请求走了哪条路，至少同时记录 GetConn、GotConn、ConnectStart、DNSDone 和最终错误。

本文只讨论 Transport、解析复用与回调条件。相关官方资料可直接查看：https://pkg.go.dev/net/http/httptrace、https://go.dev/src/net/http/transport.go。

先把 DNSStart 当作解析开始信号

官方定义是“DNS lookup begins”。也就是说，回调描述的是 Go 网络栈进入一次主机名解析的观察点，并不承诺底层一定访问了外部 DNS 服务器。系统 resolver、网络设备或代理的缓存，最多影响后续解析动作；只要当前请求确实调用了带 trace 的 Go 解析路径，DNSStart 仍可能出现。

还有一个容易忽略的条件：地址如果本来就是 IP，就没有必要做主机名解析。Go 的解析代码会先尝试把主机解析成字面量地址，成功后直接返回，因此不会先触发 DNSStart。下面的代码只注册观察点，不能把“没有日志”直接解释成 DNS 失败：

trace := &httptrace.ClientTrace{
	DNSStart: func(info httptrace.DNSStartInfo) {
		// 这里只表示解析入口开始，不代表已经发出 DNS 报文。
		log.Printf("dns start: %s", info.Host)
	},
	DNSDone: func(info httptrace.DNSDoneInfo) {
		// DNSDone 要结合 Err 和 Addrs 判断解析结果。
		log.Printf("dns done: addrs=%v err=%v", info.Addrs, info.Err)
	},
}

req, err := http.NewRequest(http.MethodGet, targetURL, nil)
if err != nil {
	return err
}
ctx := httptrace.WithClientTrace(req.Context(), trace)
req = req.WithContext(ctx)

resp, err := http.DefaultClient.Do(req)
if err != nil {
	return err
}
defer resp.Body.Close() // 及时释放响应体，避免影响后续连接复用。

Transport 先拿现成连接时为什么没有 DNSStart

这是最应该先排查的情况。Transport 获取连接时，会先看是否有符合目标主机的空闲连接；如果可以直接交付一个 persistConn，请求就不需要重新拨号，自然也不会经过“地址解析”这一段。HTTP/2 的一条连接还可以被多个请求复用，因此“本次请求没有 DNSStart”并不表示“这个客户端从未解析过该主机”。

因此，诊断时先补上 GotConn。它比单独看 DNSStart 更能回答“当前请求有没有拿到旧连接”：

trace := &httptrace.ClientTrace{
	GetConn: func(hostPort string) {
		// GetConn 表示 Transport 正在为目标寻找连接。
		log.Printf("get conn: %s", hostPort)
	},
	GotConn: func(info httptrace.GotConnInfo) {
		// Reused 和 WasIdle 能区分复用连接与新建连接的倾向。
		log.Printf("got conn: reused=%t wasIdle=%t", info.Reused, info.WasIdle)
	},
	ConnectStart: func(network, addr string) {
		// 该回调只在新连接拨号阶段提供额外线索。
		log.Printf("connect start: %s %s", network, addr)
	},
}

req = req.WithContext(httptrace.WithClientTrace(req.Context(), trace))
resp, err := client.Do(req)
if err != nil {
	return err
}
defer resp.Body.Close() // 读完或关闭响应体后，连接才有机会回到池中。

如果 GotConnInfo.Reused 为真，DNSStart 缺失通常是符合预期的。若 Reused 为假但仍没有 DNSStart，再继续看目标地址、代理和拨号器；不要把“没有 DNSStart”直接归因于 DNS 缓存。

名字解析不一定由当前请求触发

第二种模式是：请求确实需要连接，但解析工作不在这次 trace 能看到的 Go resolver 路径里。可以按下面几类区分。

• 字面量 IP：URL 的主机部分已经是 IPv4 或 IPv6 地址，解析器可以直接得到地址，DNSStart 不会出现。
• 代理路径：客户端可能只解析代理主机，目标站点的主机名交给代理处理。此时观察 origin 主机是否触发 DNSStart，结论要结合代理配置。
• 自定义 DialContext：如果自定义拨号器调用的是另一套 resolver，或者用没有携带请求 context 的方式拨号，httptrace 不一定能收到解析回调。
• 并发解析合并：同一 resolver 对相同主机的并发查找可以合并等待。这个机制说明多个请求共享一次进行中的查找，但它不是 Transport 的持久 DNS TTL 缓存。

如果确实需要自定义拨号，优先把请求 context 原样交给 net.Dialer.DialContext，让标准网络栈仍有机会传递 trace：

dialer := &net.Dialer{Timeout: 5 * time.Second}
transport := &http.Transport{
	DialContext: func(ctx context.Context, network, addr string) (net.Conn, error) {
		// 委托标准 Dialer，并保留请求 context 中的网络 trace。
		return dialer.DialContext(ctx, network, addr)
	},
}
client := &http.Client{Transport: transport}

反过来，如果代码自己把 addr 拆成 IP，再调用一个全新的 context.Background() 去拨号，那么 DNSStart 不回调也可能只是观察链路被切断。这里的重点不是强行让回调出现，而是明确自定义拨号器把哪些步骤移出了标准路径。

把“没有回调”当成架构信号，而不是故障结论

一个常见反例是把 DNSStart 计数器当成 DNS 请求总量。这样做会把连接复用、HTTP/2 多路复用、字面量 IP、代理解析和自定义 resolver 都误判成“DNS 指标丢失”。更稳妥的记录方式是把事件分成三层：

判断顺序可以收敛成四句话：

1. 先看 GotConn.Reused；复用连接时没有 DNSStart 很正常。
2. 再看 URL 主机是否为字面量 IP，以及是否配置了代理。
3. 如果发生了新拨号，再检查 DialContext 是否委托标准 net.Dialer。
4. 最后把 DNSDone.Err、请求错误和连接事件放在同一条记录里，不用单个回调下结论。

常见追问

DNSStart 没有回调，能说明 DNS 被缓存了吗？

不能。它只能说明当前 trace 没有观察到新的主机名解析开始。缓存可能存在于系统、代理或自定义组件，但连接复用和字面量 IP 同样会产生相同现象。

DNSDone 有回调但 DNSStart 没有，应该怎么处理？

先检查 trace 是否在请求发出前正确放入 context，并确认是否混用了多个 trace。标准路径通常成对提供开始和结束信息；如果只看到结束信息，应把它当作 trace 组装或自定义 resolver 的线索继续排查。

怎样监控真正的 DNS 网络请求量？

不要只依赖 httptrace。它适合观察 HTTP 客户端路径；真正的 DNS 报文量还需要在 resolver、代理或系统网络层采集，并与 Transport 的连接复用指标分开统计。