net.Resolver 自定义 DNS 后查询仍走系统配置的原因

给 net.Resolver 设置了自定义 Dial，查询结果却仍然来自系统 DNS，通常不是 DNS 地址拼错，而是这次查询没有进入 Go 内置解析器。Resolver.Dial 只为 Go resolver 建立 DNS 的 UDP/TCP 连接；如果当前平台或环境选择了 cgo/系统解析路径，这个回调就不会参与查询。

解决办法是把边界一次说清：使用同一个 Resolver 发起查询或交给实际的 net.Dialer，设置 PreferGo: true，并在回调中连接字面 IP 和端口。这样既能避开系统解析器选择造成的落差，也能保留请求上下文和连接资源的正确生命周期。

自定义 DNS 不生效时，先确认解析路径，再检查 Dial 参数。PreferGo: true 只影响这个 Resolver；回调地址应是 DNS 服务器的字面 IP:端口，不能再写一个需要解析的主机名。

Resolver.Dial 为什么会被系统配置绕开

Go 的 net 包在 Unix 上可以使用两类解析器：Go 内置解析器直接向系统配置中的 DNS 服务器发送请求，cgo 解析器则调用系统的 getaddrinfo 等库函数。官方文档说明，Unix 默认倾向 Go resolver，但操作系统、LOCALDOMAIN、RES_OPTIONS、HOSTALIASES、/etc/resolv.conf 或 /etc/nsswitch.conf 的特定配置，都会改变选择。

Resolver.Dial 的注释有一个关键限定：它是“供 Go 内置 DNS resolver 使用”的替代拨号器。换句话说，它不是操作系统级的 DNS 劫持，也不会改写 libc 的解析行为。调用的是默认 Resolver、实际使用了 cgo，或者调用入口根本没有带上自定义 Resolver，都会让查询继续表现为系统配置。

PreferGo 要和自定义 Dial 一起设置

仅填写 Dial 并不等于强制采用 Go resolver。将 PreferGo 设置为 true，相当于只对这个 Resolver 使用 GODEBUG=netdns=go 的选择效果。这样做不会修改进程中其他默认解析调用，也不会把系统的 resolv.conf 改掉。

package dnsdemo

import (
	"context"
	"net"
)

// newResolver 把自定义 DNS 限定在 Go 内置 resolver 的边界内。
func newResolver(server string) *net.Resolver {
	return &net.Resolver{
		PreferGo: true, // 让当前 Resolver 优先走 Go 内置解析器。
		Dial: func(ctx context.Context, network, _ string) (net.Conn, error) {
			// Resolver 会传入 udp 或 tcp；server 应是字面 IP:端口。
			return (&net.Dialer{}).DialContext(ctx, network, server)
		},
	}
}

这里的 server 应该是类似 223.5.5.5:53 的字面地址。回调收到的第三个参数本身也是 DNS 服务的 IP:端口，示例用闭包里的固定地址覆盖它，是为了明确“所有请求只去指定服务器”；如果业务要按网络类型或地址做策略，也可以读取传入的 network，但不要把 DNS 回调再交给一个需要解析的地址。

让实际查询入口持有同一个 Resolver

自定义 Resolver 只在被真正使用时生效。直接调用包级的 net.LookupHost 使用的是 net.DefaultResolver，它不知道你新建的实例。若是 HTTP 客户端，则要把带 Resolver 的 net.Dialer 放进 Transport；若只是查询主机名，则直接调用这个 Resolver 的方法。

func lookupWithCustomDNS(ctx context.Context, host string) ([]string, error) {
	resolver := newResolver("223.5.5.5:53")
	// 从同一实例发起查询，避免意外回到 net.DefaultResolver。
	return resolver.LookupHost(ctx, host)
}

func dialerWithCustomDNS() *net.Dialer {
	resolver := newResolver("223.5.5.5:53")
	// HTTP Transport 或其他网络客户端应使用这个 Dialer。
	return &net.Dialer{Resolver: resolver}
}

Resolver.Dial 和 net.Dialer.Control 不是同一个层次：前者负责“DNS 查询包去哪里”，后者以及 DialContext 负责“解析出地址后，业务连接如何建立”。如果只改了 HTTP 的连接拨号器，却继续让 URL 主机名由默认 Resolver 解析，看到系统 DNS 是预期结果。

按四个边界排查仍走系统 DNS 的情况

遇到“回调没有打印日志”或“解析结果与系统一致”时，可以按调用边界、解析器选择、地址语义和对象复用四处排查。每一项都对应一个明确结论，不需要先怀疑缓存。

如果需要观察解析器选择，可以在受控环境中使用 GODEBUG=netdns=go 或 GODEBUG=netdns=cgo 对比，但这只是帮助确认路径的诊断手段。生产代码更应该通过 PreferGo 和显式 Resolver 表达依赖，而不是依赖全局环境变量。

几个容易混淆的边界

第一，PreferGo:true 不会让 DNS 服务器支持一个不存在的协议；回调必须返回符合 DNS 传输要求的 net.Conn，UDP/TCP 的选择由 resolver 传入。第二，DNS 回调里的连接会由 resolver 管理和关闭，业务不应在回调外重复接管它。第三，net.Resolver 影响的是名称解析，不会自动修改已经拿到 IP 后的 HTTP、TLS 或代理策略。

还要注意系统差异：官方文档明确说明不同平台可能优先使用 cgo 或系统 API。本文的修复目标不是让每个系统都表现成同一个底层实现，而是让“需要自定义 DNS 的这一条调用路径”显式绑定到 Go resolver；不需要自定义 DNS 的其他调用仍可保留系统默认行为。

相关问题

为什么把 DNS 地址写成域名会让问题再次出现？ 因为 Resolver.Dial 的地址参数要求是字面 IP 和字面端口；写成域名会引入另一轮需要解析的过程。

设置了 PreferGo 以后，系统的 resolv.conf 还重要吗？ 仍然重要。Go resolver 需要从系统配置读取默认搜索域、DNS 服务器和其他解析参数；自定义 Dial 只替换连接 DNS 服务的方式。

能不能只改 GODEBUG？ 可以用它做进程级诊断或强制选择，但库代码通常更适合把 Resolver 作为依赖显式传入，避免影响无关调用。