关闭 HTTP/2 后客户端为什么仍显示 h2 连接

关闭 Go 源站的 HTTP/2 后，客户端仍显示 h2，最常见的原因不是配置失效，而是客户端看到的是“客户端到 CDN、负载均衡或反向代理”这一跳。HTTP 协议按连接逐跳协商：前端连接可以是 h2，而代理回源到 Go 服务仍然是 HTTP/1.1。

如果客户端直连 Go 源站仍协商到 h2，再检查两件事：Server.Protocols 是否显式只启用了 HTTP1，以及真正启动监听的是否就是这一个 http.Server 实例。

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

先把问题改成“哪一跳仍在使用 h2”

把 HTTP/2 当成端到端的全局开关，很容易得到错误结论。经过代理的请求至少包含两个独立连接：

• 客户端到边缘代理：浏览器或 curl 通常报告这一跳的协商结果。
• 边缘代理到 Go 源站：由代理的回源配置和 Go Server 的协议集合共同决定。

因此，浏览器开发者工具显示 h2，只能证明浏览器与它直接连接的服务器使用了 HTTP/2。若 TLS 在 CDN 或负载均衡处终止，Go 源站关闭 HTTP/2 并不会让前端连接自动降级。

Go 1.24 以上应显式把源站限定为 HTTP1

Server.Protocols 为 nil 时，HTTPS Server 通常默认支持 HTTP/1 与 HTTP/2。仅仅“不写 HTTP/2 配置”并不等于关闭 HTTP/2。要明确关闭，应创建协议集合并只开启 HTTP1。

package main

import (
    "errors"
    "fmt"
    "log"
    "net/http"
)

func main() {
    mux := http.NewServeMux()
    mux.HandleFunc("/proto", func(w http.ResponseWriter, r *http.Request) {
        // r.Proto 是代理到 Go 源站这一跳的实际请求协议
        _, _ = fmt.Fprintf(w, "origin_protocol=%s\n", r.Proto)
    })

    protocols := new(http.Protocols)
    protocols.SetHTTP1(true) // 只允许 HTTP/1.0 与 HTTP/1.1

    srv := &http.Server{
        Addr:      ":8443",
        Handler:   mux,
        Protocols: protocols, // 未启用 HTTP2 与 UnencryptedHTTP2
    }

    // 必须启动这个 srv，不能改完 srv 后调用包级 http.ListenAndServeTLS
    err := srv.ListenAndServeTLS("cert.pem", "key.pem")
    if err != nil && !errors.Is(err, http.ErrServerClosed) {
        log.Fatal(err)
    }
}

HTTP1 同时包含 HTTP/1.0 与 HTTP/1.1。没有调用 SetHTTP2(true)，TLS ALPN 就不应把 h2 作为这个 Go Server 的允许协议；没有调用 SetUnencryptedHTTP2(true)，也不会开放明文 HTTP/2 Prior Knowledge。

配置正确却不生效，先检查启动入口

一个很隐蔽的反例是：代码构造并配置了 srv，最后却调用了包级函数 http.ListenAndServeTLS。包级函数会启动自己的 Server，不会读取你在另一个实例上设置的 Protocols。

绕过代理，保留 SNI 直连源站

要判断 Go 源站是否仍启用 HTTP/2，测试流量必须绕过 CDN 或反向代理，同时保留正确的域名与 TLS SNI。curl --resolve 可以把指定域名临时解析到源站地址，而不改系统 DNS。

# 将 origin.example.com:8443 直连到源站地址，同时保留 Host 与 TLS SNI
curl --resolve origin.example.com:8443:10.0.0.15 \
  --http2 -sv https://origin.example.com:8443/proto

# 再强制 HTTP/1.1，对比 Go Handler 返回的 r.Proto
curl --resolve origin.example.com:8443:10.0.0.15 \
  --http1.1 -sv https://origin.example.com:8443/proto

第一条命令允许客户端尝试 HTTP/2，但服务端若只启用 HTTP1，最终不会在源站这一跳协商为 h2。比起只看 curl 的连接提示，更可靠的是同时查看 /proto 返回的 origin_protocol，因为它来自 Go 收到的 Request.Proto。

如果源站证书只对正式域名有效，不要直接用 IP 拼接 HTTPS URL；那样会改变 SNI 和证书校验条件，测试的已不是同一个入口。对于内网自签名证书，可以在受控测试环境使用对应 CA，而不是长期依赖跳过证书校验。

旧配置与外部组件也会制造错觉

TLSNextProto 与 Protocols 的职责不同

历史代码常通过把 TLSNextProto 设为不含 h2 的非空映射来关闭 HTTP/2。Go 1.24 以后，Server.Protocols 是更直接的协议集合声明。迁移时不要只改注释或辅助函数，应确认最终运行的 Server 字段值。

GODEBUG 只影响 Go 进程自身

GODEBUG=http2server=0 可以关闭 Go Server 的默认 HTTP/2 支持，但它不会改变 CDN、Ingress 或负载均衡面向客户端的协议。看到前端 h2 时，不能据此判断该环境变量没有生效。

代理头不能替代连接协议证据

X-Forwarded-Proto 通常描述原始请求使用 HTTP 还是 HTTPS，并不等同于 HTTP/1.1 或 HTTP/2。除非代理明确写入并受信任地传递协议版本信息，否则判断源站这一跳仍应使用 r.Proto。

关闭 HTTP/2 的判断清单

1. 客户端显示 h2 时，先确认它连接的是 CDN、负载均衡、反向代理还是 Go 源站。
2. Go 1.24 以上确认实际 Server 的 Protocols 非 nil，且只调用 SetHTTP1(true)。
3. 确认启动代码调用的是该实例的 srv.ListenAndServeTLS。
4. 检查是否存在旧 TLSNextProto、GODEBUG 或 x/net/http2 配置路径。
5. 用 --resolve 绕过代理直连源站，并保持正确 Host 与 SNI。
6. 在 Handler 中读取 r.Proto，确认代理到 Go 的真实协议。
7. 核对所有运行副本是否已更新和重启，避免流量命中旧实例。

这套判断的关键是把“前端连接”和“回源连接”分开。客户端显示 h2 并不与 Go 源站只接受 HTTP/1 矛盾；只有在直连实际源站、且 r.Proto 仍为 HTTP/2.0 时，才应继续追查 Go Server 的实例绑定与启动路径。

相关问题

浏览器能看到代理到源站的协议吗？

通常不能。浏览器开发者工具主要展示浏览器到前置服务这一跳，回源协议需要从代理配置、代理日志或源站的 r.Proto 判断。

关闭 Go Server 的 HTTP/2 会让网站前端不再显示 h2 吗？

不一定。如果 TLS 在 CDN 或负载均衡终止，前置服务仍可继续向浏览器提供 HTTP/2。

Server.Protocols 需要哪个 Go 版本？

http.Protocols 与 Server.Protocols 从 Go 1.24 开始提供。更旧版本需要使用对应版本支持的配置方式。