客户端与服务端 Protocols 配置不一致会怎样

如果客户端和服务端的 http.Protocols 配置不完全相同，不一定会报错。它们更像两张“可用协议清单”：在具体的 URL scheme、TLS 协商和明文 HTTP/2 条件下，双方取能真正使用的交集。有共同协议就可能回退或协商成功，没有共同协议才会在连接或请求阶段失败。

先把 Protocols 看成集合，而不是开关

Protocols 在 Go 1.24 中加入 net/http。它提供 HTTP1、HTTP2 和 UnencryptedHTTP2 三类能力。HTTP1 同时覆盖 HTTP/1.0 与 HTTP/1.1，HTTP2 指 TLS 连接上的 HTTP/2，UnencryptedHTTP2 则是明文 TCP 上的 HTTP/2 prior knowledge。

因此，客户端启用 HTTP/1 和 HTTP/2，而服务端只启用 HTTP/1，并不意味着配置错误。对于 HTTPS，请求仍可落到 HTTP/1.1。真正危险的是双方集合没有交集，或者代码以为某个协议已经启用，实际却受 URL scheme、TLS 配置或代理链限制。

HTTPS 不一致时，常见结果是回退或无共同协议

HTTPS 场景先经过 TLS，再由客户端和服务端的协议能力决定后续 HTTP 层。下面的配置让客户端同时声明 HTTP/1 与 HTTP/2，让服务端只接受 HTTP/1：

package main

import "net/http"

func makeClient() *http.Client {
	transport := http.DefaultTransport.(*http.Transport).Clone()
	transport.Protocols = new(http.Protocols)
	transport.Protocols.SetHTTP1(true) // 保留兼容性更好的 HTTP/1.1
	transport.Protocols.SetHTTP2(true) // 允许服务端通过 TLS 协商 HTTP/2
	return &http.Client{Transport: transport}
}

func makeServer() *http.Server {
	protocols := new(http.Protocols)
	protocols.SetHTTP1(true) // 服务端只接受 HTTP/1，客户端仍可回退到它
	return &http.Server{Addr: ":8443", Protocols: protocols}
}

这个组合的共同能力是 HTTP/1，所以不能把“客户端声明了 HTTP/2”理解成请求一定使用 HTTP/2。相反，如果服务端只开 HTTP/2、客户端显式只开 HTTP/1，就没有共同协议，HTTPS 请求应优先检查 TLS ALPN、服务端 NextProtos 和 Response.Proto，不要只看 HTTP 状态码。

明文 HTTP/2 是最容易误判的边界

对 http:// URL，Transport.Protocols 同时包含 HTTP/1 与 UnencryptedHTTP2 时，标准库客户端会优先使用 HTTP/1。想让它以 h2c 方式发送，需要关闭 HTTP/1；服务端也必须接受 UnencryptedHTTP2。

func h2cOnlyClient() *http.Client {
	transport := http.DefaultTransport.(*http.Transport).Clone()
	transport.Protocols = new(http.Protocols)
	transport.Protocols.SetUnencryptedHTTP2(true) // 明文 HTTP/2 使用 prior knowledge
	transport.Protocols.SetHTTP1(false)           // 避免 http:// 请求优先落到 HTTP/1
	return &http.Client{Transport: transport}
}

func h2cOnlyServer() *http.Server {
	protocols := new(http.Protocols)
	protocols.SetUnencryptedHTTP2(true) // 只接收明文 HTTP/2
	return &http.Server{Addr: ":8080", Protocols: protocols}
}

如果只有一端打开 h2c，另一端仍只支持 HTTP/1，请求就没有可用交集。这里不能靠增加 Connection: Upgrade 头来“补救”：标准库的配置描述的是 HTTP/2 prior knowledge，已废弃的 Upgrade h2c 路径不属于这组自动协商。

用响应协议和错误位置定位不一致

先记录实际响应的 Response.Proto，它回答“这次成功请求到底使用了哪一版协议”。再按下面顺序排查：

1. 确认 URL 是 http 还是 https；不要用 HTTPS 的判断解释 h2c。
2. 打印客户端 Transport 的 Protocols 状态，确认是显式集合还是 nil 默认值。
3. 对 HTTPS 检查证书握手与 ALPN；若连接失败，先看 TLS/协议协商错误，再看服务端 Handler。
4. 对 HTTP 检查两边是否都启用 UnencryptedHTTP2，以及客户端是否仍保留 HTTP/1。
5. 如果中间有反向代理，分别记录客户端到代理、代理到上游的协议；两段连接的配置不是同一张清单。

resp, err := client.Do(req)
if err != nil {
	// 协议或 TLS 阶段失败时，Response 可能为空，先保留原始错误。
	return err
}
defer resp.Body.Close() // 无论协议版本如何，都要关闭响应体。
fmt.Println(resp.Proto) // 例如 HTTP/1.1 或 HTTP/2.0，用于确认实际结果。

上线前的配置清单

生产环境建议把协议选择写成一张矩阵：scheme、客户端集合、服务端集合、代理上游集合、期望的 Response.Proto 和失败回退。兼容旧服务时保留 HTTP/1；只有在链路、网关和监控都明确支持时，才把某一侧收窄为 HTTP/2 或 h2c。配置不一致本身不是故障，无法解释的“无共同协议”才是需要修复的故障。

常见问题

客户端同时开启 HTTP/1 和 HTTP/2，能保证一定使用 HTTP/2 吗？

不能。服务端能力、URL scheme、TLS ALPN 以及代理链都会影响结果，应以 Response.Proto 为准。

服务端只开 HTTP/2，客户端只开 HTTP/1 会自动降级吗？

不会，因为双方没有共同协议。要么给客户端保留 HTTP/2，要么让服务端同时接受 HTTP/1。

为什么 h2c 配置看起来正确却仍走 HTTP/1？

客户端若同时启用 HTTP/1 和 h2c，明文 http:// 请求会优先使用 HTTP/1。需要 h2c-only 时关闭 HTTP/1，并确认服务端也接受明文 HTTP/2。