Go TLS ALPN 没协商到 HTTP/2 时先查哪些字段

Go 程序访问 HTTPS 时，如果 resp.Proto 仍然是 HTTP/1.1，不要先把问题归结为“HTTP/2 没打开”。ALPN 排查至少要分成三层：客户端有没有在 tls.Config.NextProtos 声明 h2，TLS 握手后 ConnectionState().NegotiatedProtocol 选中了什么，以及 net/http 最终用什么协议发送请求。三者不一致时，修错一层不会改变结果。

最有价值的第一组日志是 NextProtos、NegotiatedProtocol 和 Response.Proto。结果为空通常表示没有选中 ALPN，结果为 http/1.1 表示发生了回落，只有结果为 h2 且响应协议也为 HTTP/2，才能认为这次请求真的走了 HTTP/2。

先把三个协议字段分开看

NextProtos 是输入，表示本端愿意参与 ALPN 的应用协议列表；它不是最终结果。客户端通常会把 h2 和 http/1.1 放进去，服务端根据自己支持的协议选择一个。握手完成后，Go 把选择结果放在 tls.ConnectionState.NegotiatedProtocol 中。

这里有三个容易混淆的状态：

客户端配置冲突比服务器不支持更常见

如果客户端自定义了 TLSClientConfig，不要只看它是否能完成 TLS 握手，还要检查 Transport 是否仍然启用了 HTTP/2。较新的 Go 可以用 Transport.Protocols 明确表达协议集合；兼容旧写法时，ForceAttemptHTTP2 能让带自定义 TLS 配置的 Transport 继续尝试 HTTP/2。另一个危险点是非空的 TLSNextProto：它会改变 Transport 接管 ALPN 升级的方式，手工放入不完整的 map 可能让自动 HTTP/2 行为失效。

可以先用下面的检查函数打印实际状态。它故意同时输出 TLS 层和 HTTP 层字段，不把某一个布尔开关当成结论。

package main

import (
    "context"
    "crypto/tls"
    "fmt"
    "net/http"
    "time"
)

func main() {
    // 明确给出 h2 和 HTTP/1.1，便于观察服务端最终选择的 ALPN。
    tlsConfig := &tls.Config{
        ServerName: "example.test",
        NextProtos: []string{"h2", "http/1.1"},
    }

    // 自定义 TLS 配置时显式开启 HTTP/2 尝试，避免只完成 TLS 却没有 HTTP/2 Transport。
    transport := http.DefaultTransport.(*http.Transport).Clone()
    transport.TLSClientConfig = tlsConfig
    transport.ForceAttemptHTTP2 = true

    client := &http.Client{Transport: transport, Timeout: 8 * time.Second}
    req, err := http.NewRequestWithContext(context.Background(), http.MethodGet, "https://example.test/", nil)
    if err != nil {
        panic(err) // 示例程序直接终止；生产服务应记录并返回错误。
    }

    resp, err := client.Do(req)
    if err != nil {
        panic(err) // 连接、证书或协议失败都要保留原始错误信息。
    }
    defer resp.Body.Close() // 关闭响应体，避免影响连接复用和后续诊断。

    fmt.Printf("response_proto=%s tls_alpn=%q server=%s\\n",
        resp.Proto, resp.TLS.NegotiatedProtocol, resp.TLS.ServerName)
}

如果这里打印 tls_alpn=""，先查服务端有没有发送 ALPN 选择；如果是 http/1.1，说明 TLS 层完成了协议回落；如果是 h2 但 resp.Proto 仍是 HTTP/1.1，就继续检查 Transport 的 HTTP/2 接管配置。

服务端要同时提供 h2 和正确的 TLS 入口

服务端排查不能只看证书是否有效。证书解决的是身份验证，ALPN 决定的是连接建立后使用哪种应用协议。自定义 tls.Config 时确认 NextProtos 包含 h2；如果使用较新的 net/http，再看 Server.Protocols 是否允许 HTTP/2。监听地址、证书、反向代理和应用服务器可能不是同一层，客户端连到的 TLS 入口必须真正把 h2 声明给它。

特别要注意“前端代理支持 h2、后端 Go 服务不支持”的情况：浏览器到代理这一跳可以是 HTTP/2，但代理到 Go 服务的另一跳仍可能是 HTTP/1.1。排查时必须在实际发起请求的那一跳记录字段，不能拿浏览器开发者工具的协议列替代 Go 客户端日志。

按结果选择修复方向

把现场结果整理成三种情况，处理会更快：

• 空字符串：优先检查 NextProtos 是否为空、代理是否终止 TLS、服务端是否返回了 ALPN 选择。
• http/1.1：双方都完成了 TLS，但共同协议只有 HTTP/1.1，检查服务端是否真的启用 h2 以及客户端是否声明 h2。
• h2 但响应仍是 HTTP/1.1：检查 ForceAttemptHTTP2、Transport.Protocols 和 TLSNextProto，确认 HTTP Transport 没有被手工配置打断。

修复后不要只打印配置对象。把 resp.Proto、resp.TLS.NegotiatedProtocol、服务端访问日志中的协议字段和连接复用表现放在同一次测试里核对；这样才能确认改动已经穿过 TLS 层和 HTTP 层。

常见问题

NextProtos 的顺序会决定服务端选择吗？

客户端顺序代表自己的偏好和支持集合，但 ALPN 的最终选择由服务端在共同协议中决定。不要只调整列表顺序来“强制” h2，先确认服务端确实提供 h2。

NegotiatedProtocol 是空值就代表证书有问题吗？

不是。空值首先说明没有协商出 ALPN 协议，证书校验和 ALPN 是两件事；证书可以有效，应用协议仍然回落或未选择。

为什么 curl 能用 HTTP/2，Go 客户端却不行？

两者的 TLS 扩展和 HTTP Transport 配置可能不同。先让 Go 打出三个字段，再比较是否连到了同一地址、是否经过同一代理，以及自定义 TLS 配置是否关闭了自动 HTTP/2 路径。

排查 ALPN 时，最小闭环就是“声明什么、握手选什么、请求用了什么”。把这三个字段固定进测试日志后，HTTP/2 没协商到的问题通常能很快落到客户端 Transport、服务端 TLS 入口或中间代理的具体一层。