Go transport 出错时怎么查端口增长

看到 dial tcp、too many open files，或者监控里本地端口一路上涨时，先不要急着把 DisableKeepAlives 打开。Go 的端口增长要先看 TCP 状态：ESTABLISHED 多，可能是真实并发或连接上限偏小；TIME_WAIT 多，通常是短连接频繁建立和关闭；CLOSE_WAIT 多，则优先检查应用是否没有结束响应体。真正有效的修复通常是复用一个长期存活的 http.Transport，正确收尾 Response.Body，再按上游数量设置连接边界。

官方资料：https://pkg.go.dev/net/http

端口数不是连接池大小的同义词。先按 socket 状态定位，再用 httptrace 看是否复用，最后调整 MaxIdleConnsPerHost、MaxConnsPerHost 和 IdleConnTimeout，排查才不会变成盲目改参数。

先把端口增长分成三种状态

出站请求使用的是本地临时端口。一个目标地址可能同时对应许多连接，但端口数量还受协议、连接生命周期和上游数量影响。尤其是 HTTP/2，多个请求可以共享一条 TCP 连接，不能拿“请求数 ÷ 端口数”推导复用率。

用 httptrace 判断 Transport 是否复用连接

仅看端口总数，很难知道请求拿到的是新连接还是空闲连接。httptrace.ClientTrace.GotConn 能记录本次请求获得连接时的 Reused 和 WasIdle。这一步适合在小流量或压测样本中打开，不建议把每个请求的完整诊断日志永久打满。

package main

import (
    "context"
    "log"
    "net/http"
    "net/http/httptrace"
)

// requestWithTrace 只记录连接取得时的复用信号，不把它当成性能结论。
func requestWithTrace(ctx context.Context, client *http.Client, target string) (*http.Response, error) {
    trace := &httptrace.ClientTrace{
        GotConn: func(info httptrace.GotConnInfo) {
            // Reused 表示连接曾经被使用，WasIdle 表示取得前处于空闲状态。
            log.Printf("reused=%v was_idle=%v", info.Reused, info.WasIdle)
        },
    }
    req, err := http.NewRequestWithContext(httptrace.WithClientTrace(ctx, trace), http.MethodGet, target, nil)
    if err != nil {
        return nil, err
    }
    return client.Do(req)
}

连续样本里的 Reused=false，可以把排查范围收窄到 Transport 是否重复创建、响应体是否没有收尾、目标主机是否不断变化，以及是否设置了 DisableKeepAlives。如果 Reused=true 但端口仍然增长，也不矛盾：可能是并发超过空闲容量，或者同时访问了很多不同的主机。

复用 Transport 并保证 Response.Body 收尾

Transport 默认会缓存连接，官方文档也建议复用它，并且它可以被多个 goroutine 并发使用。最容易踩的坑是把 http.Client 或 Transport 写进单次调用：每个请求都有自己的连接池，短时间内就可能制造大量新连接和 TIME_WAIT。

func doRequest(ctx context.Context, client *http.Client, target string) ([]byte, error) {
    req, err := http.NewRequestWithContext(ctx, http.MethodGet, target, nil)
    if err != nil {
        return nil, err
    }
    resp, err := client.Do(req)
    if err != nil {
        return nil, err
    }
    defer resp.Body.Close() // 所有返回路径都要释放响应体。

    // 先消费正文，给 HTTP/1.x 持久连接留下复用机会。
    body, err := io.ReadAll(resp.Body)
    if err != nil {
        return nil, err
    }
    if resp.StatusCode = 300 {
        return nil, fmt.Errorf("上游返回 %s", resp.Status)
    }
    return body, nil
}

这段示例省略了 io 和 fmt 的导入，只突出响应体边界。生产代码若遇到很大的错误响应，可以使用有上限的读取策略；但不能因为只关心状态码，就直接返回而忘记关闭 Body。真正的网络错误发生在 client.Do 时，则没有可关闭的响应体。

按上游和并发设置连接边界

MaxIdleConnsPerHost 只控制每个主机保留的空闲连接，MaxIdleConns 控制所有主机的空闲连接总量，MaxConnsPerHost 才是该主机活动、拨号和空闲连接的总上限。IdleConnTimeout 只针对空闲 keep-alive 连接，不是请求超时。

transport := &http.Transport{
    MaxIdleConns:        100,
    MaxIdleConnsPerHost: 8,
    MaxConnsPerHost:     64,
    IdleConnTimeout:     90 * time.Second,
}
client := &http.Client{
    Transport: transport,
    Timeout:   15 * time.Second, // 给整个请求设置上限，和空闲连接超时不是一回事。
}

上面的数值只是配置示例。若 ESTABLISHED 长期贴着 MaxConnsPerHost，先看上游延迟和等待队列，不要只把上限继续调大；若 TIME_WAIT 很多，则要回到 Transport 创建位置和请求关闭策略。切断 keep-alive 会减少空闲连接，却可能增加拨号、握手和端口回收压力。

用 socket 检查和 CloseIdleConnections 收尾

Linux 上可以先按状态观察进程的出站连接分布；macOS 可用同样思路配合 lsof 查看。下面的命令是排查示例，输出数量只代表观察时刻，不是固定阈值。

# Linux：按 TCP 状态统计目标服务的连接数量，替换进程名再执行。
ss -tanp | awk '$0 ~ /my-service/ {print $1}' | sort | uniq -c

# macOS：查看进程打开的 TCP 连接，重点观察状态列的变化。
lsof -nP -a -p 12345 -iTCP -sTCP:ESTABLISHED

如果上游切换、代理更新或证书策略变化，旧的空闲连接不应继续留在池里，可以在变更点调用 transport.CloseIdleConnections()。它只清理当前空闲连接，不会中断正在使用的请求；也不要把它放进每次请求的 defer，否则刚建立的复用池会被自己反复清空。

常见问题

TIME_WAIT 很多是不是 Go 连接泄漏？

不一定。它表示连接已经关闭，内核暂存关闭状态。若短连接创建频率很高，TIME_WAIT 会自然堆积；应检查 Transport 是否被重复创建，以及是否主动禁用了 keep-alive。

CLOSE_WAIT 多时只调大 MaxIdleConnsPerHost 有用吗？

通常没用。CLOSE_WAIT 更应该先查响应体关闭、读取失败和提前返回路径；空闲连接容量解决的是池中可复用连接数量，不是本地未收尾的连接。

Reused=true 后为什么端口还会上涨？

一次或部分请求复用，并不代表所有请求都复用。多个上游、并发高于空闲容量、HTTP/1.x 与 HTTP/2 差异，都可能让端口继续增加。把 httptrace 样本与三种 socket 状态放在同一时间窗口观察，结论才完整。