Go HTTP 客户端为什么会卡在连接阶段：Transport 超时参数与复测指标

线上调用一个看起来很普通的 HTTP 接口，日志却总在 2 秒左右报超时。把 Client.Timeout 从 2 秒改成 10 秒，错误暂时少了，问题却没有根绝：到底是 DNS 慢、TCP 连不上、TLS 握手卡住，还是服务端迟迟不回响应头？Go 的 http.Client 默认把这些等待阶段全部揉进一次请求流程里，排查时很容易只盯着总时长这一个指标，完全找不到具体卡点。

先用阶段耗时确认请求卡在哪里，再用 http.Transport 给连接、TLS、响应头分别设边界；Client.Timeout 只适合做最后一道总预算，不适合代替所有阶段参数。

先看一次请求的基线耗时

先不要急着改超时值。给同一个目标地址连续请求 30 次，记录成功、超时和每个阶段的耗时。假设日志大致是这样：

success=24 timeout=6
dns p95=18ms connect p95=42ms tls p95=96ms
header p95=1840ms total p95=2012ms

这组数据说明网络连接本身没有明显瓶颈，主要等待发生在响应头返回之前。此时把连接超时从 3 秒改成 8 秒，几乎不会改善结果；应该先确认服务端处理、代理转发或上游依赖为什么让响应头晚到。

反过来，如果 connect 经常接近 3 秒且报 i/o timeout，那才值得检查地址解析、路由、防火墙和目标端口。参数调整要跟实际观测到的证据走，不要凭感觉改大数值。

把 Transport 参数对准对应阶段

下面是一套适合作为服务端调用起点的配置。数值不是固定标准答案，关键是每个参数都能对应一种明确的等待场景。

transport := &http.Transport{
    DialContext: (&net.Dialer{
        Timeout:   800 * time.Millisecond,
        KeepAlive: 30 * time.Second,
    }).DialContext,
    TLSHandshakeTimeout:   1 * time.Second,
    ResponseHeaderTimeout: 1500 * time.Millisecond,
    IdleConnTimeout:       90 * time.Second,
    MaxIdleConns:          100,
    MaxIdleConnsPerHost:   20,
}

client := &http.Client{
    Transport: transport,
    Timeout:   3 * time.Second,
}

Dialer.Timeout限制建立 TCP 连接的时间；TLSHandshakeTimeout只在 HTTPS 握手阶段生效；ResponseHeaderTimeout从写出请求后开始等待响应头。最后的 Client.Timeout 是总预算，应该大于各阶段正常耗时之和，并给响应体读取留出足够余量。

如果接口会长时间返回流式数据，不能直接套用很小的 Client.Timeout。总超时会连响应体读取一起截断，这时要按业务协议设计读取边界，或者改用请求级上下文控制生命周期。

不要把连接池参数当成慢请求修复方案

IdleConnTimeout 和 MaxIdleConnsPerHost 主要影响连接复用逻辑。连接复用不足可能带来更多握手开销，但它们不能让服务端更快生成响应头。先看连接复用率和 TLS 阶段耗时，再判断是否需要调整池大小。

用 httptrace 验证假设

只看一行“请求超时”的日志远远不够。net/http/httptrace 可以把关键时间点挂载到请求上，下面的示例保留了最常用的几个节点：

var start = time.Now()
trace := &httptrace.ClientTrace{
    DNSStart: func(httptrace.DNSStartInfo) {
        log.Printf("dns_start +%s", time.Since(start))
    },
    ConnectStart: func(string, string) {
        log.Printf("connect_start +%s", time.Since(start))
    },
    GotConn: func(info httptrace.GotConnInfo) {
        log.Printf("got_conn reused=%t +%s", info.Reused, time.Since(start))
    },
    TLSHandshakeDone: func(tls.ConnectionState, error) {
        log.Printf("tls_done +%s", time.Since(start))
    },
    GotFirstResponseByte: func() {
        log.Printf("first_byte +%s", time.Since(start))
    },
}

req = req.WithContext(httptrace.WithClientTrace(req.Context(), trace))

这里的 GotConn 很有价值：如果大量请求都显示 reused=true，连接建立肯定不是主因；如果它长期为 false，再去看服务端是否主动关闭、连接池是否太小或请求是否没有正确关闭响应体。

改动后怎样复测才有意义

复测不要只发一次请求。固定同一个 URL、请求体和并发数，先预热连接，再采集至少 30 次；同时记录成功率、超时阶段、p50、p95 和 p99。一个可读的结果表可以这样整理：

如果只是把总超时从 2 秒拉到 10 秒，超时率可能下降，但 p95 仍然是 1.8 秒，调用方线程、连接和重试预算都会被拖长。更稳妥的做法是把“能接受的等待”写进调用方契约：例如响应头超过 1.5 秒就降级，整个请求超过 3 秒就结束，并把阶段字段带进日志。

几个容易误判的边界

DNS 慢不一定要调大连接超时

DNS 解析由解析器和网络环境共同决定，连接超时并不覆盖所有解析等待。先核对解析耗时和地址族，再考虑解析配置；不要用一个更大的总预算把每次请求都拖长。

响应体读取慢，不能只看响应头

响应头已经回来，不代表正文读完了。下载接口、流式接口或大 JSON 都可能在读取阶段耗时。记录正文读取耗时，并检查调用方是否关闭 resp.Body，否则连接复用和文件描述符都会受影响。

重试必须占用独立预算

单次请求 3 秒、最多重试 3 次，整体等待可能接近 9 秒，还没算退避时间。应给重试设置总截止时间，并区分连接失败、响应头超时和业务状态码，不能对所有错误一律重试。

常见问题

只设置 Client.Timeout 够不够？

小工具或内部脚本可以先用它兜底，但生产调用最好同时设置关键阶段参数，否则日志只能知道“总超时”，不知道哪一段在等待。

ResponseHeaderTimeout 会限制响应体吗？

它主要限制等待响应头的时间，响应头收到后，正文读取仍要由总超时、请求上下文或业务读取逻辑控制。

IdleConnTimeout 越大越好吗？

不是。空闲连接太久可能遇到中间设备回收，太短又会增加重新建连开销；应结合服务端 keep-alive、代理策略和复用率复测。

把超时变成可解释的指标

这次调整的目标不是得到一组“看起来专业”的数字，而是让每次失败都能回答：卡在 DNS、连接、TLS、响应头，还是正文读取？先保存基线，再改一个边界，最后用相同负载复测。这样即使目标服务下次变慢，也能快速判断该改调用方预算、服务端性能，还是网络链路。