Go DNS Resolver 怎样分别设置解析和连接超时

Go 客户端连接一个域名时，常见的误判是把“解析慢”和“连接慢”都归结为网络超时。实际上，net.Resolver.LookupIPAddr 负责把主机名解析成地址，net.Dialer.DialContext 负责建立连接；如果直接把主机名交给 Dialer，两段工作会共享一次调用的上下文。

需要分别统计或限制两个阶段时，可以先用一个父级上下文约束总预算，再为 DNS 和 TCP 建连各派生一个子上下文。下面的模式只讨论这两个阶段，不把 TLS 握手和响应读取混入连接超时。

简单客户端用一个总超时就够了；只有在需要区分 DNS 故障与建连故障时，才把主机名先解析成 IP，再把 IP 交给 Dialer。

为什么要把 DNS 和连接分开计时

解析阶段的输入是主机名，输出是一个或多个 IP 地址；连接阶段的输入则是地址和端口。二者属于不同的资源边界：解析器可能等待本地解析配置或上游 DNS，连接器则可能等待路由、端口或对端建立 TCP。

如果直接调用 DialContext(ctx, "tcp", "api.example.com:443")，这个 ctx 会约束整个建连动作，其中也包含主机名解析。它适合“从开始连接到建立成功最多等待多久”的总预算，却不能回答“解析用了多少、真正连接用了多少”。

先给 LookupIPAddr 一个独立的解析预算

为解析单独派生上下文，并在函数返回时调用取消函数。这样既能释放计时器，又能让父级截止时间自然成为上限：

package main

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

func resolve(ctx context.Context, host string) ([]net.IPAddr, error) {
	// 解析预算只负责 DNS 阶段；父级 ctx 更早截止时仍然优先结束。
	resolveCtx, cancel := context.WithTimeout(ctx, 800*time.Millisecond)
	defer cancel()

	addrs, err := net.DefaultResolver.LookupIPAddr(resolveCtx, host)
	if err != nil {
		// DeadlineExceeded 便于上层区分“解析超时”和其他 DNS 错误。
		if errors.Is(err, context.DeadlineExceeded) {
			return nil, fmt.Errorf("DNS 解析超时: %w", err)
		}
		return nil, fmt.Errorf("DNS 解析失败: %w", err)
	}
	return addrs, nil
}

LookupIPAddr 返回的是 []net.IPAddr，所以后续还要选择一个地址并拼出带端口的目标。这里没有把解析结果当成“永远有效”的缓存；缓存策略属于另一个问题，不能用来替代本次调用的上下文控制。

把解析结果交给 Dialer 控制连接预算

连接阶段不要再次传入域名，否则 Dialer 可能重新进入解析路径。选取一个地址后，用 net.JoinHostPort 处理 IPv6 方括号，再用新的上下文调用 DialContext：

func dialHost(ctx context.Context, host string, port int) (net.Conn, error) {
	addrs, err := resolve(ctx, host)
	if err != nil {
		return nil, err
	}
	if len(addrs) == 0 {
		return nil, fmt.Errorf("DNS 没有返回地址")
	}

	// 连接预算只覆盖 TCP 建连；使用 IP 避免再次触发主机名解析。
	dialCtx, cancel := context.WithTimeout(ctx, 2*time.Second)
	defer cancel()
	target := net.JoinHostPort(addrs[0].IP.String(), fmt.Sprint(port))

	dialer := net.Dialer{}
	conn, err := dialer.DialContext(dialCtx, "tcp", target)
	if err != nil {
		// 连接超时时保留原始上下文错误，方便上层记录阶段名称。
		if errors.Is(err, context.DeadlineExceeded) {
			return nil, fmt.Errorf("TCP 建连超时: %w", err)
		}
		return nil, fmt.Errorf("TCP 建连失败: %w", err)
	}
	return conn, nil
}

调用方拿到连接后仍然拥有关闭责任，例如在成功返回后立即安排 defer conn.Close()。这段示例只建立 TCP 连接；如果后面还要做 TLS 或读取响应，应再设计它们各自的预算，而不是把所有阶段都误记为“连接超时”。

父级截止时间如何约束两个子预算

两个子上下文的超时时间不是总预算的额外叠加。假设父级只剩 500 毫秒，即使解析子上下文配置了 800 毫秒，解析也会在父级截止时结束；解析成功后，连接子上下文同样不能越过父级截止点。

因此，分阶段预算应写成“阶段上限 + 父级总上限”：父级负责请求整体可接受的最长时间，子级负责在某阶段提前失败并给出可识别的原因。日志至少记录阶段名、目标主机和 errors.Is(err, context.DeadlineExceeded) 的判断结果。

什么时候不该拆成两段

如果业务只关心“连接动作不能超过 3 秒”，直接给 DialContext 一个带超时的上下文更简单，也更不容易引入地址选择、IPv6、重试和连接关闭等额外逻辑。只有以下情况值得采用分阶段模式：

• 需要区分 DNS 服务变慢与目标端口不可达；
• 需要为解析和建连分别统计耗时或告警；
• 解析结果要交给后续连接策略，且不希望再次解析。

反过来，如果你只把 net.Dialer.Timeout 当作 DNS 专属超时，结论会失真：Dialer 的连接动作仍可能包含名字解析。要得到清晰边界，就让 LookupIPAddr 明确承担解析，让 DialContext 接收已经解析出的地址。

落地前的判断清单

先问自己三个问题：是否需要分别观测 DNS 和 TCP；父级请求是否有总截止时间；连接成功后谁负责关闭 net.Conn。三个答案都清楚时，采用“父级 Context → resolveCtx → IP 地址 → dialCtx → net.Conn”的结构；否则优先使用一个总超时的简单调用。

常见延伸问题：

• 解析超时后能不能立刻换备用 DNS？ 可以设计备用解析器，但应单独规划重试预算，不能无限延长父级上下文。
• 拿到多个 IP 是否必须全部尝试？ 不必须，地址选择和 Happy Eyeballs 属于连接策略；本文只展示一个地址的边界。
• 连接建立成功后读响应超时怎么办？ 需要为读写阶段另行设计 deadline，不能复用本文的 DNS 预算。