Go net.Resolver Dial 怎样为 DNS 查询走自定义网络

如果 Go 程序需要让 DNS 查询经过指定的网络出口，关键不是改写 LookupHost，而是给 net.Resolver 配置 Dial，并同时设置 PreferGo: true。这样自定义函数才会被 Go 内置 DNS 解析器用于连接 DNS 服务；它不会自动接管后续的业务 TCP 连接。

官方文档：https://pkg.go.dev/net#Resolver

本文只讨论三个边界：Resolver.Dial 收到什么参数、怎样把解析阶段的网络和超时交给它，以及如何用指标确认配置确实生效。

先看基线：为什么只写 Dial 可能没有效果

net.Resolver 同时包含 PreferGo、StrictErrors 和 Dial。其中 Dial 是 Go 内置 DNS 解析器连接 DNS 服务时的可选拨号函数；如果最终选择了 cgo 解析器，这个函数就不是你控制 DNS 网络路径的入口。

所以排查时先记录两件事：自定义 Dial 是否被调用，以及查询是否在上下文截止前完成。若没有任何 Dial 日志，优先检查解析器实现选择，而不是先怀疑代理地址。

同时设置 PreferGo 和 Dial

下面的示例用一个自定义 net.Dialer 连接解析器传入的地址。代码里的代理只是网络策略示意，不要把它误认为业务请求已经经过同一条路径。

package main

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

func main() {
    dialer := &net.Dialer{Timeout: 2 * time.Second}
    resolver := &net.Resolver{
        // 强制优先使用 Go 内置解析器，否则自定义 Dial 可能不会进入。
        PreferGo: true,
        // 这里的 Dial 只负责 DNS 服务连接，不负责后续业务连接。
        Dial: func(ctx context.Context, network, address string) (net.Conn, error) {
            // address 应是字面量 IP:port；把 ctx 传下去才能响应解析截止时间。
            return dialer.DialContext(ctx, network, address)
        },
    }

    ctx, cancel := context.WithTimeout(context.Background(), 1500*time.Millisecond)
    defer cancel() // 释放定时器资源，避免调用方长期持有上下文。

    hosts, err := resolver.LookupHost(ctx, "example.com")
    if err != nil {
        // 生产代码可结合 errors.Is 判断 context.DeadlineExceeded。
        fmt.Println("DNS lookup failed:", err)
        return
    }
    fmt.Println("resolved:", hosts)
}

这里有两个不同的时间预算：net.Dialer.Timeout限制每次 DNS 网络连接，而外层 context.WithTimeout限制整次解析调用。外层预算更短时，底层拨号会收到取消信号。

把解析超时和业务连接超时拆开

真实请求通常还会经历“DNS 解析—建立业务连接—发送请求”三个阶段。要判断慢在哪里，不要只给整个请求套一个总超时；至少把解析阶段单独包起来，再给业务连接保留自己的预算。

func resolveThenConnect(parent context.Context, host, port string) (net.Conn, error) {
    resolver := &net.Resolver{
        // 只有纯 Go 解析器会使用下面的自定义 DNS 拨号函数。
        PreferGo: true,
        Dial: func(ctx context.Context, network, address string) (net.Conn, error) {
            start := time.Now()
            conn, err := (&net.Dialer{Timeout: 800 * time.Millisecond}).DialContext(ctx, network, address)
            // 记录 DNS 拨号耗时，便于区分 DNS 慢与业务连接慢。
            fmt.Printf("dns dial network=%s address=%s elapsed=%s err=%v\n", network, address, time.Since(start), err)
            return conn, err
        },
    }

    lookupCtx, cancelLookup := context.WithTimeout(parent, 1200*time.Millisecond)
    defer cancelLookup() // 解析完成后及时停止定时器。
    addrs, err := resolver.LookupHost(lookupCtx, host)
    if err != nil {
        return nil, fmt.Errorf("resolve %s: %w", host, err)
    }

    connectCtx, cancelConnect := context.WithTimeout(parent, 2*time.Second)
    defer cancelConnect() // 业务连接也使用独立预算。
    return (&net.Dialer{}).DialContext(connectCtx, "tcp", net.JoinHostPort(addrs[0], port))
}

这个函数的记录重点不是“是否使用了某个代理”，而是 Dial 是否被调用、收到的是 udp 还是 tcp、目标地址是否为字面量，以及错误是否来自上下文截止。DNS 查询可能先走 UDP，在需要时再走 TCP，因此不能把 network 参数硬编码成单一值。

用指标判断自定义网络是否真的生效

可以用下面的最小对照表检查结果。它描述的是观测方法，不是假设某个网络环境必然得到的耗时。

如果 Dial 一次都没有进入，继续调大 Dialer 的超时没有意义；如果 Dial 已进入但 address 不是预期的 DNS 服务地址，应先确认系统解析配置和运行平台。若错误满足 errors.Is(err, context.DeadlineExceeded)，说明应先调整阶段预算或网络连通性，而不是简单重试。

几个容易混淆的边界

• Dial 不是 HTTP 代理入口：它接管的是 Go DNS 解析器连接 DNS 服务的动作，不能让后续 HTTP 请求自动经过代理。
• PreferGo 不是全局开关：它只作用于当前 Resolver；需要全局改变解析选择时才考虑进程级配置。
• 地址不要再次按域名解析：官方约定 Dial 收到的 host 是字面量 IP，port 是字面量端口，直接交给底层拨号器即可。
• 不要吞掉 ctx：如果自定义函数改用 Background，外层 LookupHost 的截止时间就无法及时传到 DNS 连接。

结论与延伸问题

要让 net.Resolver.Dial 真正控制 DNS 查询的网络路径，最小组合是 PreferGo: true 加一个遵守签名的 Dial。把上下文继续传给 Dialer.DialContext，再把解析预算和业务连接预算拆开，日志就能回答“没有进入自定义 Dial”“DNS 服务不可达”还是“业务连接慢”。

Resolver.Dial 收到的 address 可以是域名吗？按官方约定它是字面量 IP 地址和字面量端口，不应在 Dial 内再次做域名解析。

只设置 PreferGo 不写 Dial 有什么用？它可以选择 Go 内置解析器，但网络连接仍使用默认拨号逻辑；只有需要自定义 DNS 连接路径时才实现 Dial。

为什么一次查询可能看到 UDP 和 TCP？DNS 解析器会根据查询过程和响应情况选择网络连接，Dial 的 network 参数应被原样尊重，而不是强制改成固定协议。