Go DNSIPv6 优先导致连接等待过长怎么办

遇到“Go 通过域名连接要等很久”，先不要把结论写成“IPv6 一定有问题”。更准确的判断是：域名可能同时返回 AAAA 和 A 记录，Go 先尝试了 IPv6；如果本机拿到了 IPv6 地址，却没有可用的路由、网关或服务端路径，TCP 建连就会先卡在这个地址上。对 TCP 来说，net.Dialer 默认带有 Fast Fallback，IPv4 通常会在短暂等待后接管；真正需要修的是没有边界的等待，以及无法区分解析慢和建连慢的排障方式。

一、先把等待拆成解析和连接两段

DNS 只负责把主机名变成地址，TCP 连接还要经过路由、邻居发现、防火墙和服务端监听。问题定位的第一步，是分别记录 LookupIPAddr 和 DialContext 的耗时。下面的示例只输出地址族和阶段耗时，不把具体域名、IP 或凭据写进日志。

package main

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

func inspectDial(host, port string) error {
	// 解析阶段单独设置截止时间，避免 DNS 慢被误判成 IPv6 建连慢。
	lookupCtx, cancelLookup := context.WithTimeout(context.Background(), 2*time.Second)
	defer cancelLookup()

	started := time.Now()
	addrs, err := net.DefaultResolver.LookupIPAddr(lookupCtx, host)
	fmt.Printf("dns_elapsed=%s addresses=%d err=%v\n", time.Since(started), len(addrs), err)
	if err != nil {
		return err
	}
	for _, addr := range addrs {
		family := "ipv6"
		if addr.IP.To4() != nil {
			family = "ipv4"
		}
		fmt.Printf("dns_address_family=%s\n", family)
	}

	// 建连阶段复用独立的 context，让 IPv6 失败或回退不会无限等待。
	dialCtx, cancelDial := context.WithTimeout(context.Background(), 5*time.Second)
	defer cancelDial()
	dialer := net.Dialer{}
	conn, err := dialer.DialContext(dialCtx, "tcp", net.JoinHostPort(host, port))
	if err != nil {
		return fmt.Errorf("tcp dial: %w", err)
	}
	defer conn.Close() // 诊断连接只用于确认建连，确认后立即释放资源。
	fmt.Printf("tcp_elapsed=%s local=%s remote=%s\n", time.Since(started), conn.LocalAddr().Network(), conn.RemoteAddr().Network())
	return nil
}

如果 dns_elapsed 已经接近上限，先查 DNS 服务器、搜索域和解析器选择；如果 DNS 很快但 tcp dial 久，才把注意力放到 IPv6 路由和 TCP 回退。示例中的 local=%s 与 remote=%s 输出的是网络类型，不会泄露地址。

二、检查 IPv6 优先是否真的成为瓶颈

LookupIPAddr 会返回主机的 IPv4 和 IPv6 地址，但“列表里 IPv6 在前”并不等于 DNS 出错。它只说明后续拨号有一个 IPv6 候选；是否等待过长，还要看 IPv6 路径是否可用，以及拨号器是否启用了快速回退。

常见的坏路径是：主机有全球或局部 IPv6 地址，DNS 也返回 AAAA，然而出口网络没有稳定的 IPv6 默认路由。此时 IPv6 SYN 可能被静默丢弃，等待会比“立即拒绝连接”更明显。另一类问题是服务端只有 IPv4 监听，或者中间防火墙只允许 A 记录对应的路径。排查时应把以下现象分开记录：

• 解析阶段是否同时返回 A 和 AAAA。
• IPv6 单独拨号是立即失败、超时，还是成功。
• 使用网络名 tcp 时，IPv4 是否在回退边界后成功。
• 应用自己的总超时是否短于底层连接的逐地址尝试时间。

不要为了“看起来快”直接把所有请求改成 tcp4。那会掩盖部署环境的 IPv6 配置问题，也会让真正支持 IPv6 的服务失去双栈能力。只有在明确的单栈 IPv4 边界，例如某个内网出口完全不提供 IPv6 时，才把 tcp4 作为局部、可说明的策略。

三、用 DialContext 保留双栈快速回退

对于 tcp 连接，如果解析结果同时包含 IPv6 和 IPv4，Go 的 net.Dialer 会把第一个地址族当作首选，并在 FallbackDelay 后尝试另一个地址族。当前官方文档说明，FallbackDelay 为零时使用默认的 300 毫秒，负值才会关闭 Fast Fallback；因此通常不必自己实现“先 IPv6，睡眠后再 IPv4”的 goroutine 竞速。

package client

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

func dialServer(ctx context.Context, address string) (net.Conn, error) {
	// 零值保留 Go 的默认 Fast Fallback；只给整次拨号设置业务边界。
	dialer := net.Dialer{
		Timeout: 5 * time.Second,
	}
	return dialer.DialContext(ctx, "tcp", address)
}

func requestConn(address string) (net.Conn, error) {
	// 上层截止时间应覆盖解析、排队和建连，避免单个 IPv6 地址拖住请求。
	ctx, cancel := context.WithTimeout(context.Background(), 6*time.Second)
	defer cancel()
	return dialServer(ctx, address)
}

这里把 Dialer.Timeout 和 context 都设置成有限值，是为了让库函数即使被错误调用也有兜底；实际项目应根据连接池、重试和上游总预算重新分配。若业务确实需要改变回退等待，可以显式设置一个正的 FallbackDelay，但不要用负值关闭回退后再声称解决了 IPv6 优先问题。

四、只在证据充分时调整解析器

Go 的解析器有纯 Go 和系统原生两种路径，最终选择会受平台、构建标签、环境变量和系统配置影响。Resolver.PreferGo 只是在这个 Resolver 上偏好 Go 内置解析器；GODEBUG=netdns=go 是进程级运行时开关，GODEBUG=netdns=cgo 则偏好系统解析器。它们改变的是“怎么问 DNS”，不是“IPv6 能不能走通”。

package diagnostic

import (
	"context"
	"net"
)

func lookupWithChosenResolver(ctx context.Context, host string) ([]net.IPAddr, error) {
	resolver := &net.Resolver{
		PreferGo: true, // 仅用于对比解析器行为，不作为全局网络修复。
	}
	return resolver.LookupIPAddr(ctx, host)
}

把 PreferGo 放进一次可控的诊断调用，比在生产环境永久设置全局 GODEBUG 更容易回滚。若两种解析器返回的地址集合都正常，而连接仍只在 IPv6 首选时变慢，就不要继续调整 DNS 实现，应回到路由、出口防火墙、服务端监听和拨号超时。

五、建立上线前的排查清单

最后再看重试：如果一次连接有 6 秒截止时间，失败后又立即重试三次，用户感受到的等待仍可能接近 18 秒。把解析、建连、重试和上游请求放进同一个总预算，才能避免局部 timeout 叠加成更大的延迟。

相关问题

为什么直接把网络名改成 tcp4 会立刻变快？

因为它跳过了 IPv6 候选，但这只证明 IPv6 路径可能有问题，不证明 DNS 解析器有问题。应把它作为隔离实验，不要直接当成长期修复。

FallbackDelay 能解决 DNS 查询本身很慢吗？

不能。它只影响已有 IPv6、IPv4 地址之后的 TCP 建连回退；DNS 查询仍要用独立的解析 context 和日志字段定位。

什么时候可以使用 GODEBUG=netdns=go？

当你需要对比 Go 内置解析器和系统解析器的行为时可以临时使用；上线前应确认它不会改变当前平台对本地解析、搜索域或特殊名称的兼容性。