当前位置：首页 > 文章列表 > Golang > Go问答 > Go HTTP 服务关闭 HTTP/2 后为什么客户端仍复用旧连接

Go HTTP 服务关闭 HTTP/2 后为什么客户端仍复用旧连接

来源：17golang原创 2026-09-28 11:40:55 0浏览收藏

Go HTTP 服务把 HTTP/2 关闭后，客户端仍显示 HTTP/2.0，通常不是开关失效，而是客户端正在复用关闭前已经建立的 TLS 连接。协议选择发生在连接建立时，连接进入复用池后，后续请求不会因为服务端配置字段变化而自动重新协商。

Go 官方文档：https://pkg.go.dev/net/http

要让切换结果真正体现出来，服务端要在新连接上只开放 HTTP/1.1，客户端还要清理或替换旧 Transport；验证时同时看 Response.Proto、httptrace.GotConnInfo.Reused 和 WasIdle。

要点速览

Server.Protocols 约束服务端接受的新连接协议，不能把既有 HTTP/2 连接降级成 HTTP/1.1。
http.Transport 会缓存连接；Client.CloseIdleConnections 只处理空闲连接，不中断活跃请求。
发布切换要区分新连接、空闲连接、活跃长连接和代理层连接，不能只看一次请求结果。

关闭 HTTP/2 只影响新连接协商

HTTPS 建连时，客户端和服务端通过 TLS 的 ALPN 选择 h2 或 http/1.1。Go 的 Server.Protocols 决定服务端允许哪些协议，配置只会作用于后续建立的连接。已经完成握手的 HTTP/2 连接仍然是一个可承载多个请求的连接，服务端不会因为修改配置字段就把它原地改成 HTTP/1.1。

Go 1.24 及以后可以显式只保留 HTTP/1。这个配置要在服务开始监听前完成：

srv := &http.Server{
    Addr:    ":8443",
    Handler: handler,
}

srv.Protocols = new(http.Protocols)
srv.Protocols.SetHTTP1(true) // 只接受 HTTP/1，不把 HTTP/2 放入协议集合

// 证书和密钥应由部署配置提供，示例只展示协议边界。
if err := srv.ListenAndServeTLS("server.crt", "server.key"); err != nil && err != http.ErrServerClosed {
    log.Fatal(err) // 启动或监听失败时立即暴露错误
}

旧版本 Go 常见的兼容写法是把 TLSNextProto 设为非 nil 且不包含 h2，或者在进程启动时使用 GODEBUG=http2server=0。新代码优先使用 Server.Protocols，这样 HTTP/1、HTTP/2 与未加密 HTTP/2 的意图更清楚。

Go http.Server、Server.Protocols、TLS、ALPN 与 HTTP/1.1 和 HTTP/2 的静态关系图 — 图1：Server.Protocols 约束新连接可协商的协议，已经建立的 TLS 连接仍保留原来的协议状态；这是原创结构说明图，不是运行截图。

客户端 Transport 为什么还会复用旧连接

http.Client 通常持有一个长期复用的 http.Transport。Transport 内部会缓存连接，HTTP/2 连接还可以在同一条连接上承载多个请求，所以服务端刚完成切换时，客户端继续得到 HTTP/2.0 是符合连接生命周期的。

如果客户端只是想让下一批请求重新建立连接，可以先关闭空闲连接；如果需要彻底切换连接池，则创建新的 Transport 和 Client。关闭空闲连接不会打断正在传输的请求：

client.CloseIdleConnections() // 只清理当前 Transport 中已经空闲的连接

// 切换到新连接池，避免继续持有旧 Transport 的连接状态。
newTransport := http.DefaultTransport.(*http.Transport).Clone()
newClient := &http.Client{Transport: newTransport}

resp, err := newClient.Get(targetURL)
if err != nil {
    return err // 建连或协议协商失败要交给调用方处理
}
defer resp.Body.Close() // 读完响应后关闭 Body，允许 Transport 回收连接

这个动作只能影响客户端一侧的连接池。若旧 HTTP/2 连接仍有活跃流，服务端发布切换应采用连接排空：停止接收新连接，等待活跃请求结束，再退出旧进程。Server.Shutdown 会关闭监听器和空闲连接，但不会强行中断活跃连接；硬切换才考虑 Server.Close，代价是正在处理的请求可能被打断。

Go http.Client、http.Transport、连接池、HTTP/2 连接与 CloseIdleConnections 的静态关系图 — 图2：客户端 Transport 持有连接池，旧 HTTP/2 连接与新建 Transport 属于不同生命周期对象；这是原创关系说明图，不是运行截图。

用请求协议和连接追踪确认结果

不要只根据服务端配置或浏览器开发者工具下结论。服务端可以在处理器中记录 r.Proto，客户端则可以用 httptrace 观察 Transport 取到的连接是否复用：

trace := &httptrace.ClientTrace{
    GotConn: func(info httptrace.GotConnInfo) {
        log.Printf("reused=%v wasIdle=%v idle=%s", info.Reused, info.WasIdle, info.IdleTime)
    }, // Reused 和 WasIdle 用来区分旧连接与新建连接
}

req, err := http.NewRequest(http.MethodGet, targetURL, nil)
if err != nil {
    return err // URL 构造失败时不要继续发起请求
}
req = req.WithContext(httptrace.WithClientTrace(req.Context(), trace))

resp, err := client.Do(req)
if err != nil {
    return err // 传输错误与协议协商错误都在这里返回
}
defer resp.Body.Close()
log.Printf("protocol=%s", resp.Proto) // 最终以响应记录的协议为准

如果第一次请求的 Reused=false 且 Proto=HTTP/2.0，说明新连接仍然协商到了 HTTP/2，应检查服务端实际运行的配置、前置代理和 TLS 终止位置。如果 Reused=true，则先清理客户端连接池再复查；如果请求经过网关，客户端看到的协议可能只是客户端到网关这一段。

观测结果	更可能的原因	处理方向
`Reused=true`、仍为 HTTP/2	客户端继续使用旧连接	清理空闲连接或替换 Transport
`Reused=false`、仍为 HTTP/2	新连接的服务端或代理仍允许 h2	检查实际 TLS 终止点与运行时配置
新请求为 HTTP/1.1，旧请求仍为 HTTP/2	旧活跃流尚未排空	等待优雅关闭完成，不要把两种状态混为配置失败

发布切换时保留可回退边界

这类变更最容易误判的地方，是把“服务策略已经改变”当成“所有连接已经改变”。灰度发布时，先确认新实例只在新连接上返回 HTTP/1.1，再让客户端逐步清理连接池；如果前面还有反向代理，要分别记录客户端到代理、代理到 Go 服务的协议。

服务端：在监听前设置 Server.Protocols，并确认真正终止 TLS 的组件使用了同样的策略。
客户端：复用长期存在的 Client 没问题，但协议切换窗口要显式调用 CloseIdleConnections 或替换 Transport。
观测：同时记录 Request.Proto、Response.Proto、连接是否复用和实例版本。
回退：保留 HTTP/2 兼容实例，直到活跃长连接和代理缓存都排空。

总结

Go 服务关闭 HTTP/2 后客户端仍复用旧连接，核心原因是协议协商和连接复用属于两个生命周期。Server.Protocols 负责新连接的协议集合，http.Transport 负责客户端连接池；把旧连接清理、把活跃连接排空，再用 httptrace 和 Response.Proto 验证，才能判断切换是否真正完成。