Go DNS 解析慢怎样接入自定义 Resolver

Go 服务访问某个域名时，如果首个请求偶尔卡住，先不要急着把 HTTP 总超时继续调大。更稳妥的做法是把“域名解析”和“TCP/TLS 建连”拆开观察，再用 net.Resolver 把 DNS 行为接到一个明确的 Resolver 上。官方资料入口：https://pkg.go.dev/net。

自定义 Resolver 的核心不是把所有 DNS 问题都变快，而是把解析器选择、DNS 连接方式、错误严格程度和请求上下文放到应用自己的控制范围内。

• 先用独立的解析调用确认慢点是否发生在 DNS，而不是连接或服务端响应。
• PreferGo 只控制当前 Resolver 是否优先使用 Go 内置解析器，Dial 才负责改变 DNS 通道。
• 接入 HTTP 时，把 Resolver 放到 net.Dialer.Resolver，不要把它误写成 HTTP 请求的 Transport。

先把 DNS 慢点和建连慢点分开

一个请求的总耗时包含解析、建立连接、TLS 握手和读取响应。直接给 http.Client.Timeout 加时间，只能让请求等得更久，不能说明瓶颈在哪里。排查时可以先只调用 Resolver，并且给这次查询单独的上下文。

package main

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

func lookupOnce(ctx context.Context, resolver *net.Resolver, host string) error {
	// 单独测量名称解析，避免把后面的 TCP、TLS 和响应读取混进来。
	start := time.Now()
	addrs, err := resolver.LookupHost(ctx, host)
	if err != nil {
		// 让上层保留 context 超时或 DNS 错误，便于继续分层判断。
		return fmt.Errorf("lookup %s: %w", host, err)
	}
	fmt.Printf("DNS resolved in %s: %v\n", time.Since(start), addrs)
	return nil
}

func main() {
	// 使用请求级超时，避免排查代码本身无限等待。
	ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second)
	defer cancel()
	if err := lookupOnce(ctx, net.DefaultResolver, "example.com"); err != nil {
		fmt.Println(err)
	}
}

如果这里已经超时，优先检查 Resolver、系统 DNS 配置和网络出口；如果解析很快而请求仍慢，再去看连接建立、TLS 或服务端响应。这个分层也能避免把一个“解析器不可达”误诊成 HTTP 连接池问题。

用 net.Resolver 配置自定义 DNS 通道

net.Resolver 的 PreferGo 是解析器选择项，StrictErrors 会影响组合查询遇到临时错误时是否直接失败，Dial 则为 Go 内置解析器提供 DNS 服务连接函数。Dial 收到的地址应当按字面 IP 和端口处理，因此示例不在这个回调里再次解析 DNS 名称。

package main

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

func customResolver() *net.Resolver {
	return &net.Resolver{
		// 将选择范围收窄到这个 Resolver，不修改进程外的全局环境。
		PreferGo: true,
		// A 与 AAAA 等组合查询出现临时错误时，整体返回错误。
		StrictErrors: true,
		Dial: func(ctx context.Context, network, address string) (net.Conn, error) {
			// address 是 DNS 服务的字面 IP:端口；这里设置独立的连接期限。
			dialer := net.Dialer{Timeout: 800 * time.Millisecond}
			return dialer.DialContext(ctx, network, address)
		},
	}
}

func main() {
	// Resolver 本身不保存业务状态，可以按应用配置复用。
	resolver := customResolver()
	ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second)
	defer cancel()
	addrs, err := resolver.LookupHost(ctx, "example.com")
	if err != nil {
		fmt.Println("DNS failed:", err)
		return
	}
	fmt.Println("addresses:", addrs)
}

这里没有把某个 DNS 域名写进 Dial 回调，因为回调的目标地址已经由 Resolver 选定。实际部署时应根据网络环境配置可达的 DNS 服务地址，并让外层上下文拥有比单次 DNS 连接更大的总期限。

把 Resolver 接到 http.Transport

HTTP 客户端真正发起域名连接时，通常经过 http.Transport 的拨号逻辑。将 Resolver 放进 net.Dialer，再把这个 Dialer 交给 Transport，就能让该 Transport 使用自定义解析策略。

package main

import (
	"context"
	"net"
	"net/http"
	"time"
)

func newClient() *http.Client {
	resolver := customResolver()
	dialer := &net.Dialer{
		Timeout:   3 * time.Second,
		KeepAlive: 30 * time.Second,
		Resolver:  resolver,
	}
	transport := &http.Transport{
		// 让 HTTP 连接建立阶段使用上面的 Dialer 和 Resolver。
		DialContext:         dialer.DialContext,
		MaxIdleConns:        100,
		MaxIdleConnsPerHost: 10,
		IdleConnTimeout:     90 * time.Second,
	}
	return &http.Client{Transport: transport, Timeout: 8 * time.Second}
}

func request(ctx context.Context, client *http.Client, url string) (*http.Response, error) {
	// 每个请求仍需绑定自己的上下文，Client.Timeout 不是取消策略的替代品。
	req, err := http.NewRequestWithContext(ctx, http.MethodGet, url, nil)
	if err != nil {
		return nil, err
	}
	return client.Do(req)
}

注意，连接复用会让后续请求不一定再次触发 DNS；这属于正常现象。若要观察新的解析行为，应结合空闲连接回收、不同主机或独立的 LookupHost 调用判断，而不是每次请求都强制关闭复用。

反向验证：四个容易误判的边界

第一，DNS 地址不要再写主机名。 Resolver.Dial 回调里的 address 是字面 IP 和端口，不能假设它是一个需要二次解析的域名。

第二，区分超时来源。 context.WithTimeout、net.Dialer.Timeout 和 http.Client.Timeout 作用层级不同；短期限可能让 DNS 还没返回就被上层取消。

第三，谨慎启用 StrictErrors。 它会让组合查询中的临时错误更快暴露，但也可能改变对部分 DNS 服务行为的兼容性，应该结合实际网络环境选择。

第四，不要把 Resolver 当缓存。 net.Resolver 负责解析路径与 DNS 连接配置，代码本身不等于业务级 DNS 缓存。若要缓存，应单独设计过期、失败和刷新策略。

常见问题

自定义 Resolver 会自动让 DNS 更快吗？

不会。它提供可控的解析器和 DNS 连接路径，速度仍取决于 DNS 服务、网络路径、上下文期限和连接复用。

只改 PreferGo 就能指定 DNS 服务器吗？

不能。PreferGo 只影响解析器选择；要接入指定通道，需要配置 Resolver.Dial，并让它返回可用的 net.Conn。

为什么独立 LookupHost 很快，HTTP 首请求仍然慢？

因为 HTTP 还包含建连、TLS 和响应读取，且实际 Transport 可能没有使用同一个 Dialer。应确认 DialContext 已绑定到携带 Resolver 的 net.Dialer。

排查 Go DNS 解析慢时，先把解析与建连拆成两个证据面，再决定是否需要自定义 net.Resolver。这样即使最终不替换默认解析路径，也能明确知道调整的是哪一层。