用 http.Protocols 控制反向代理上游协议

反向代理有两条独立的 HTTP 连接：客户端到代理、代理到上游。要控制上游协议，应该给 httputil.ReverseProxy 配置一个可复用的 http.Transport，再设置它的 Protocols；只改入口 http.Server.Protocols，不会改变代理发往后端的协议。

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

先分清 Server.Protocols 与 Transport.Protocols

http.Protocols 在 Go 1.24 引入后，服务端和客户端都能用同一组方法表达协议集合，但配置位置代表不同方向。Server.Protocols 作用在监听端；Transport.Protocols 作用在出站端。反向代理同时扮演 HTTP 服务端和 HTTP 客户端，所以两处可以不同。

给 ReverseProxy 配置上游 HTTP/1 与 HTTP/2

实际项目建议从 http.DefaultTransport 克隆，保留代理、连接池和 TLS 等默认能力，再替换协议集合。Transport 应在启动时创建并复用，不要在每个请求中重新实例化。

package main

import (
	"log"
	"net/http"
	"net/http/httputil"
	"net/url"
)

func main() {
	target, err := url.Parse("https://upstream.example.internal")
	if err != nil {
		// 目标地址属于部署配置，解析失败时直接阻止代理启动。
		log.Fatal(err)
	}

	transport := http.DefaultTransport.(*http.Transport).Clone()
	transport.Protocols = new(http.Protocols)
	transport.Protocols.SetHTTP1(true) // 保留后端的 HTTP/1 兼容路径。
	transport.Protocols.SetHTTP2(true) // HTTPS 上游允许通过 ALPN 协商 HTTP/2。

	proxy := httputil.NewSingleHostReverseProxy(target)
	proxy.Transport = transport // 只有挂到这里，配置才会影响上游请求。

	server := &http.Server{Addr: ":8443", Handler: proxy}
	server.Protocols = new(http.Protocols)
	server.Protocols.SetHTTP1(true) // 入口允许普通 HTTP/1 客户端。
	server.Protocols.SetHTTP2(true) // TLS 入口同时接受 HTTP/2。

	// 证书参数只表示入口 TLS；上游是否用 HTTP/2 由 transport 决定。
	log.Fatal(server.ListenAndServeTLS("cert.pem", "key.pem"))
}

这里的关键不是把两处配置写成相同，而是明确每个方向的目标。入口可以只接受 HTTP/1，而上游仍然可以使用 HTTP/2；反过来也成立。对于 HTTPS 上游，HTTP/2 还要受对端能力和 TLS ALPN 协商影响，打开开关不等于强制后端一定返回 HTTP/2。

明文 h2c 只在上游明确支持时启用

如果上游 URL 是 http://，并且后端使用明文 HTTP/2 prior knowledge，可以把 UnencryptedHTTP2 加入集合。若只想让该链路使用 h2c，可以关闭 HTTP/1；若还要兼容旧后端，则同时保留 HTTP/1。

transport := http.DefaultTransport.(*http.Transport).Clone()
transport.Protocols = new(http.Protocols)
transport.Protocols.SetHTTP1(true) // 灰度期间保留 HTTP/1 回退能力。
transport.Protocols.SetUnencryptedHTTP2(true) // 仅对确认支持 h2c 的 http:// 上游开启。

proxy := httputil.NewSingleHostReverseProxy(target)
proxy.Transport = transport // 复用同一个 Transport，避免连接池被频繁丢弃。

想强制 h2c 时可以改成 SetHTTP1(false) 与 SetUnencryptedHTTP2(true)，但这会把不支持明文 HTTP/2 的后端直接变成失败。生产环境更适合先同时打开两者，观察连接错误和后端兼容性，再做灰度收窄。

协议不生效时按边界排查与回滚

第一项检查是请求 URL：https:// 才有 TLS ALPN 的 HTTP/2 协商，http:// 不会自动变成 h2c。第二项检查是 proxy.Transport 是否确实指向已配置的 Transport；只创建变量但没有挂到代理上，配置不会生效。第三项检查是是否复用了旧 Transport，运行中替换字段容易和已有连接池的观察结果混在一起，变更时应重启或明确关闭空闲连接。

如果后端报协议不支持、网关返回 502 或 TLS 协商失败，先把上游集合收敛到 HTTP/1：保留 new(http.Protocols)，只调用 SetHTTP1(true)，并移除 SetHTTP2 与 SetUnencryptedHTTP2。这是一条清晰的回滚路径，比继续修改 GODEBUG 或旧的 TLSNextProto 更容易定位。

常见问题

只设置 Server.Protocols 能控制上游吗？

不能。它只控制代理作为服务端接收客户端连接的协议；上游请求要看 ReverseProxy 使用的 Transport.Protocols。

Transport.Protocols 只打开 HTTP/2 就一定更快吗？

不一定。它会缩小兼容范围，后端、TLS 或中间设备不支持时反而失败。先确认链路能力，再用指标和灰度验证收益。

什么时候应该使用 UnencryptedHTTP2？

只有上游明确提供 h2c、网络边界可控且团队接受明文链路的场景。普通 HTTPS 上游应使用 HTTP2，而不是把 h2c 当成替代品。