Go net.Resolver区分 DNS 名称解析与连接失败的定位方法

排查 Go 网络请求时，最容易混淆的是“域名能解析”和“服务能连接”这两件事。前者只说明 net.Resolver 从本机解析器拿到了一个或多个地址，后者还要经过目标端口监听、路由和防火墙等环节。把两步拆开，错误就不会都被归结成一句“网络不通”。

一、先把 DNS 解析和 TCP 连接拆成两个检查点

Go 的 net 包既提供名称解析，也提供 Dial、DialContext 等连接接口。若直接调用带域名的 DialContext，解析与连接会连续发生，日志里往往只剩一个包装后的错误。定位工具应先调用 Resolver.LookupHost，拿到地址列表后再对具体地址建连。

二、用 net.Resolver.LookupHost 获取地址并识别解析错误

下面的小工具把解析阶段的证据单独打印出来。给每次查询设置超时，既能避免诊断命令一直等待，也能把“DNS 服务没有及时响应”和“域名不存在”区分开。

package main

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

// resolveHost 只负责 DNS 名称解析，不尝试连接业务端口。
func resolveHost(parent context.Context, host string) ([]string, error) {
    ctx, cancel := context.WithTimeout(parent, 3*time.Second)
    defer cancel() // 释放定时器，避免诊断命令结束后仍保留资源

    resolver := net.Resolver{}
    addrs, err := resolver.LookupHost(ctx, host)
    if err == nil {
        return addrs, nil
    }

    var dnsErr *net.DNSError
    switch {
    case errors.As(err, &dnsErr):
        // DNSError 能说明是名称、DNS 服务还是解析超时方向。
        return nil, fmt.Errorf("DNS 解析失败: name=%s timeout=%t temporary=%t: %w", dnsErr.Name, dnsErr.IsTimeout, dnsErr.IsTemporary, err)
    case errors.Is(err, context.DeadlineExceeded):
        // 上下文超时表示本次诊断预算用尽，不等同于域名不存在。
        return nil, fmt.Errorf("DNS 查询超过 3 秒: %w", err)
    default:
        return nil, fmt.Errorf("DNS 查询出现未分类错误: %w", err)
    }
}

LookupHost 返回的是该主机的地址切片；切片为空并且有错误时，不要先去改端口或重试连接。先记录 dnsErr.Name、超时和临时错误标记，再检查本机解析器配置、搜索域和 DNS 服务。

三、用解析出的地址执行带超时的 TCP 连接

解析成功后，对返回的每个地址分别连接。这样做的关键不是“多试几次”，而是避免第二次连接时又悄悄触发 DNS，让结果仍然混在一起。net.JoinHostPort 可以正确拼接 IPv4 和 IPv6 地址。

// probeTCP 只检查已经得到的 IP 地址和目标端口。
func probeTCP(parent context.Context, ip, port string) error {
    ctx, cancel := context.WithTimeout(parent, 2*time.Second)
    defer cancel() // 连接返回后立即释放超时资源

    address := net.JoinHostPort(ip, port)
    dialer := net.Dialer{}
    conn, err := dialer.DialContext(ctx, "tcp", address)
    if err != nil {
        var opErr *net.OpError
        if errors.As(err, &opErr) {
            // OpError 的 Net、Op 字段能帮助确认失败发生在连接阶段。
            return fmt.Errorf("TCP 连接失败: op=%s net=%s: %w", opErr.Op, opErr.Net, err)
        }
        if errors.Is(err, context.DeadlineExceeded) {
            // 连接超时常见于路径不可达或中间设备丢包。
            return fmt.Errorf("TCP 连接超过 2 秒: %w", err)
        }
        return fmt.Errorf("TCP 连接出现未分类错误: %w", err)
    }
    defer conn.Close() // 探测只需确认能建立连接，随后关闭连接
    return nil
}

如果报错包含 connection refused，通常说明地址已经可用，但目标端口没有接受连接；如果是 i/o timeout，更应检查路由、安全组、防火墙或目标服务是否丢弃握手包。它们都不是 DNS 名称解析失败。

四、按证据组合定位故障层级

诊断时建议把每个地址的结果保留下来，而不是只打印最后一个错误。双栈主机可能出现 IPv6 连接失败、IPv4 成功的组合；只看一条失败日志会得出“服务不可用”的错误结论。

五、IPv4、IPv6 与 Resolver 配置的边界

Resolver.LookupIP 可以按 ip4 或 ip6 选择地址族；而 StrictErrors 会影响多子查询时临时错误是否让整个查询失败。它们适合在明确的诊断场景使用，不要为了让一次请求“看起来成功”就盲目忽略错误。生产代码仍应使用请求级 context，记录每个地址的地址族与耗时，并把重试交给有上限的策略。

还要注意：net.Resolver 的实际解析路径会受操作系统和 resolver 配置影响。排查时把运行环境、解析器地址和 GODEBUG=netdns=go+1 等诊断信息作为上下文记录；不要把某台机器上的解析结果当成所有环境的结论。

相关问题

LookupHost 成功后还需要 DialContext 吗？

需要。LookupHost 只验证名称解析，DialContext 才能验证指定地址和端口的连接路径。

为什么不直接对域名调用 DialContext？

业务请求可以直接这样做，但故障定位会把解析和连接包装在同一条错误链里，不利于确定责任层。

连接错误应该重试几次？

先按错误类型决定是否重试：解析配置错误不应无上限重试，临时超时可以在总截止时间内做少量退避，端口拒绝则应优先检查服务状态。

把“主机名有没有地址”和“这个地址的端口能不能连”分开记录，Go 网络故障的排查就从一句模糊的网络错误，变成了可复核的证据链。