Go DNS 轮询返回多地址后的连接选择策略

服务商给同一个域名配置多个 A/AAAA 记录后，Go 客户端拿到的是一组候选地址，不是“每个请求自动平均分配”。真正决定连接落到哪个地址的，是解析结果顺序、net.Dialer 的拨号策略、IPv4/IPv6 回退以及你是否自己改写了地址选择。

官方资料：https://pkg.go.dev/net#Resolver.LookupIPAddr　https://pkg.go.dev/net#Dialer.DialContext

先区分 DNS 多地址与应用层轮询

Resolver.LookupIPAddr 返回的是 []net.IPAddr。同一主机可能同时得到 IPv6 和 IPv4，也可能得到多个 IPv4。这个切片描述“可以尝试谁”，并不承诺每一次查询都以相同顺序返回，更不表示已经完成连接。

因此，想解决“某个地址偶尔不可用”，应该关注拨号失败后的回退；想解决“请求长期集中在一个后端”，则要继续检查 DNS TTL、连接池复用和应用层分配。单纯打印解析结果，不能证明请求已经轮询。

默认连接优先交给 net.Dialer

普通 TCP 或 HTTP 客户端没有特殊分配要求时，直接使用带 context 的 Dialer 更稳妥。Go 文档说明：主机解析出多个网络地址时，TCP 拨号的总超时会分摊到连续尝试；双栈连接还会在主地址与回退地址之间竞速。这里的目标是尽快建立一条连接，而不是让所有地址都获得相同请求量。

// 给一次连接设置总预算；连接成功后由调用方负责关闭 conn。
func dialHost(ctx context.Context, host string) (net.Conn, error) {
    ctx, cancel := context.WithTimeout(ctx, 800*time.Millisecond)
    defer cancel() // 无论成功或失败都释放计时器

    d := net.Dialer{
        Timeout: 700 * time.Millisecond, // 连接预算，不把失败地址无限等待
    }
    // 让 net 包自行解析并处理多地址、IPv4/IPv6 回退。
    return d.DialContext(ctx, "tcp", net.JoinHostPort(host, "8443"))
}

这条路径适合连接池、HTTPS 和一般 RPC。它保留了主机名语义，HTTP/TLS 层仍可以使用原始主机名完成 Host 与 SNI 处理；不要为了“控制 IP”而随意把 URL 改成裸 IP。

需要固定分配时显式组织地址切片

如果业务确实需要按实例轮转，例如给长连接客户端分散初始连接，可以先解析一次，再旋转起点。下面的示例仍使用一个 context deadline：某个地址失败就换下一个，但所有尝试共享同一份预算。

var cursor atomic.Uint64

func dialRotated(ctx context.Context, host string, port int) (net.Conn, string, error) {
    ctx, cancel := context.WithTimeout(ctx, 900*time.Millisecond)
    defer cancel() // 解析和拨号共用预算，避免泄漏计时器

    addrs, err := net.DefaultResolver.LookupIPAddr(ctx, host)
    if err != nil || len(addrs) == 0 {
        return nil, "", fmt.Errorf("resolve %s: %w", host, err)
    }
    start := int(cursor.Add(1)-1) % len(addrs) // 轮转起点只影响本次尝试顺序
    d := net.Dialer{}
    var firstErr error
    for i := range addrs {
        ip := addrs[(start+i)%len(addrs)].IP
        target := net.JoinHostPort(ip.String(), strconv.Itoa(port))
        // 传入 IP 后不会再次依赖该主机名的解析结果。
        conn, dialErr := d.DialContext(ctx, "tcp", target)
        if dialErr == nil {
            return conn, target // 调用方使用完 conn 后必须 Close
        }
        if firstErr == nil {
            firstErr = dialErr // 保留首个错误，便于定位首选地址
        }
    }
    return nil, "", fmt.Errorf("dial %s: %w", host, firstErr)
}

这段策略控制的是“本次拨号从哪一个候选开始”，不是 DNS 缓存刷新器。生产代码还应限制解析缓存的寿命、过滤不适用地址，并把成功地址、尝试次数和总耗时写入指标。

超时、TLS 与连接复用的边界

尤其要注意长连接：一次成功连接会被复用很多请求，DNS 轮询不会打断它。若服务端实例需要更均匀的连接数，应该在连接建立策略、连接池上限和重连退避中一起设计，而不是频繁刷新 DNS。

常见问题

DNS 返回多个地址，Go 会随机选一个吗？

不能简单理解为随机。解析器和系统配置会影响返回顺序，Dialer 还会结合网络类型和回退策略处理它们；需要稳定轮转时必须自己保存并组织候选地址。

自定义轮转后还要保留 net.Dialer 吗？

要。自定义逻辑只负责候选顺序，超时、取消、底层连接和资源回收仍交给 DialContext，避免把网络细节重复实现。

如何判断策略真的生效？

记录每次连接的解析地址集合、实际成功地址、尝试次数和连接耗时，并按连接建立次数观察；不要只统计 DNS 查询次数。