Go net IPv6 优先连接等待过长怎样判断来源

判断 Go 连接等待是否来自 IPv6，不能只看请求总耗时。应先记录 DNS 完成、各地址连接尝试和最终取得的连接：DNS 很慢、首地址族连接挂起、连接已成功但 TLS 或响应慢，是三类不同问题。不要仅凭一次请求慢就永久改成 tcp4。

Go net 官方入口：https://pkg.go.dev/net

连接数增加时，先把慢分成三类

服务扩大调用量后，少量慢连接可能开始影响尾延迟。但没有现场数据时，不能声称已经找到 IPv6 黑洞，更不能编造某次线上事故。可先按“解析、建连、取得连接之后”划分观察范围，再决定改解析服务、连接策略还是上游网络。

这个表给出归因方向，不是性能测试结果。应对相同部署位置、目标域名和连接复用状态分别采样，避免将冷连接与热连接混在一起比较。

回退不是固定等待 IPv6 超时

net.Dialer 对 tcp 双栈地址支持快速回退。当 IPv4、IPv6 都可用时，解析结果中首个地址所属的地址族作为主族，不应写成“Go 永远先试 IPv6”。主族未成功时，另一族可按 FallbackDelay 发起连接；某些主族失败情况还可能让回退提前发生。因此它不是等待某个 IPv6 连接完整超时后才串行尝试 IPv4。

FallbackDelay 为0使用默认300ms，负数禁用快速回退，正数设置延迟。旧的 DualStack 字段已弃用，不需要靠把它设置为true来启用默认行为。默认延迟不是每个请求必付出的固定耗时。

预算另算：Dialer.Timeout、Dialer.Deadline 与 context 截止时间共同限制拨号，较早的截止约束会生效。DNS也可能消耗拨号预算。把回退延迟调小不能修复解析超时，也不能修复两族路径都不可达。

结构上可以把 Dialer、解析地址、主地址族、备用地址族、FallbackDelay 与总拨号预算分开理解：前四者说明参与连接的对象，延迟说明备用族的启动条件，预算约束拨号整体。这些关系不代表请求一定采用哪种地址。

让一次请求留下可分辨的事件

HTTP场景可用 httptrace.ClientTrace 记录事件。以下是独立诊断程序，只在读者主动传入自有或获授权的 HTTPS 地址后发出一次请求；本文未运行它，也没有请求探测目标。日志可能包含域名和地址，不应在生产中无采样地长期保留。

package main

import (
    "context"
    "crypto/tls"
    "fmt"
    "log"
    "net"
    "net/http"
    "net/http/httptrace"
    "net/url"
    "os"
    "sync"
    "time"
)

func main() {
    if len(os.Args) != 2 {
        log.Fatal("请传入一个获授权的HTTPS地址")
    }
    u, err := url.Parse(os.Args[1])
    if err != nil || u.Scheme != "https" || u.Host == "" || u.User != nil {
        log.Fatal("地址必须是无用户信息的HTTPS URL")
    }

    start := time.Now()
    var mu sync.Mutex
    event := func(name string, fields ...any) {
        // 回调可能并发或晚于请求结束，串行输出，不共享可变事件表。
        mu.Lock()
        defer mu.Unlock()
        log.Printf("elapsed=%s event=%s fields=%v",
            time.Since(start).Round(time.Millisecond), name, fields)
    }
    trace := &httptrace.ClientTrace{
        DNSStart: func(i httptrace.DNSStartInfo) {
            event("DNSStart", i.Host)
        },
        DNSDone: func(i httptrace.DNSDoneInfo) {
            event("DNSDone", i.Addrs, i.Err)
        },
        ConnectStart: func(network, addr string) {
            event("ConnectStart", network, addr)
        },
        ConnectDone: func(network, addr string, err error) {
            event("ConnectDone", network, addr, err)
        },
        GotConn: func(i httptrace.GotConnInfo) {
            // 只读取连接信息；连接归Transport管理，不在回调中关闭。
            event("GotConn", "reused", i.Reused, "remote", i.Conn.RemoteAddr())
        },
        TLSHandshakeStart: func() {
            event("TLSHandshakeStart")
        },
        TLSHandshakeDone: func(_ tls.ConnectionState, err error) {
            event("TLSHandshakeDone", err)
        },
        GotFirstResponseByte: func() {
            event("GotFirstResponseByte")
        },
    }

    // 示例预算不是所有业务的推荐值；保留默认的300ms快速回退。
    dialer := &net.Dialer{Timeout: 4 * time.Second, FallbackDelay: 0}
    tr := &http.Transport{
        DialContext: dialer.DialContext,
        TLSHandshakeTimeout: 4 * time.Second,
    }
    defer tr.CloseIdleConnections()
    client := &http.Client{
        Transport: tr,
        // 不自动跟随跳转，减少跨域事件混合。
        CheckRedirect: func(_ *http.Request, _ []*http.Request) error {
            return http.ErrUseLastResponse
        },
    }
    ctx, cancel := context.WithTimeout(context.Background(), 10*time.Second)
    defer cancel()
    ctx = httptrace.WithClientTrace(ctx, trace)
    req, err := http.NewRequestWithContext(ctx, http.MethodGet, u.String(), nil)
    if err != nil {
        log.Fatal(err)
    }
    resp, err := client.Do(req)
    if err != nil {
        event("RequestError", err)
        return
    }
    // 这里只诊断到响应头；不把它当成完整正文下载耗时。
    defer resp.Body.Close()
    fmt.Println("HTTP状态:", resp.Status)
}

程序使用新 Transport，未设置代理，目的是观察直接连接；若生产走代理，诊断对象和路径并不相同。不要把这个小程序直接替换进生产客户端：生产通常需要复用长期存在的 Transport，且代理、连接池和请求预算应继承原有设计。

ConnectStart、ConnectDone 可能多次出现，应按地址区分尝试，不要用一个全局“建连开始时间”覆盖所有回调。日志的 network 标签也不能单独证明地址族，应结合 addr 和最终远端地址判断。某次尝试失败也不等于整个请求失败，另一个地址可能已成功。

按观测结果调整，而非全局强制 tcp4

把旧的“一个请求总耗时”观察方式改成解析、拨号和复用信息分层后，才有条件比较调整。若 DNS 占据主要时间，应研究解析服务和部署环境；若有明确的双栈路径差异，可在相同节点进行限定范围的 tcp、tcp4、tcp6 对照，但只对获授权目标进行，且同样记录超时、失败率和目标地址。

强制 tcp4 会排除 IPv6，只能作为受控诊断或有条件的临时降级，不能作为全站默认修复。它可能掩盖路由、防火墙或服务端监听问题，也改变可达目标集合。单独 tcp6 的失败只能说明当前节点到相应目标的这条路径存在问题，不能证明整个 IPv6 网络有故障。

如果确认等待来自回退设置，再考虑按业务预算调整 FallbackDelay。更短延迟可能增加并行连接尝试；更长延迟可能延后可用备用路径。每次仅改变一项，保留配置回滚能力，不把 DNS、超时、代理和连接池同时改掉后再猜测哪个生效。

上线后仍要观察哪些边界

本文没有上线结果或性能提升数字。实际调整后，至少对比相同时间窗的建连失败率、冷连接耗时分位数、成功连接地址族比例，以及各部署区域的差异。请求总延迟下降而失败率上升，不应判作优化成功；仅看到回退事件减少，也可能是目标集合或连接复用比例变化。

没有 ConnectStart，是否说明 IPv6 卡住了？

不能。连接可能被复用，DNS可能还没结束，或者自定义Transport未走预期拨号入口。先确认GotConn.Reused与实际客户端配置。

把 Timeout 调大能修复回退吗？

它只改变可用等待预算，不让坏路径变好。较早的context截止仍可能终止操作，服务整体排队也可能因等待更久而恶化。

HTTP用了代理，日志里的地址就是源站吗？

不一定。TCP建连可能面对代理，TLS又属于不同层；应把生产代理配置与诊断直连区分开，不能以代理连接的地址族推断源站直连行为。

判断来源的关键不是先禁用IPv6，而是将解析地址、连接尝试、最终连接和请求后续阶段对齐。只有证据指向某个配置或路径，才做相应的局部调整。

参考：net.Dialer 官方文档；Go 拨号实现；HTTP ClientTrace 回调说明。