Go net/http 自定义 net.Conn 后 ALPN 状态缺失怎么办

如果 Go 1.27 中通过 Transport.DialTLSContext 返回了自定义 net.Conn，但 ALPN 状态变成空字符串，优先检查包装类型是否保留了 ConnectionState() tls.ConnectionState。不要只把 *tls.Conn 塞进一个实现了 Read、Write、Close 的结构体；这个包装若没有转发 TLS 状态，net/http 就无法判断协商出的协议。

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

先确认问题出在 TLS 状态还是 HTTP/2 选择

Go 1.27 的变化是：net/http 对用户提供的连接也支持读取 TLS ALPN 状态，但前提是连接实现了与 *tls.Conn 相同的 ConnectionState 方法。这里有两个容易混淆的时间点：DialTLSContext 返回时，Transport 假定 TLS 握手已经完成；而 tls.Conn.ConnectionState() 在握手之前读取没有意义。

因此，先把故障拆成三类。若 HandshakeComplete 是 false，是返回过早或握手失败；若握手完成但 NegotiatedProtocol 为空，通常是 NextProtos 没有配置、对端没有共同协议，或包装返回了默认零值；若状态是 h2 但请求仍走 HTTP/1.1，再看 Transport 是否真的尝试 HTTP/2。

包装 net.Conn 时显式保留 ConnectionState

最稳妥的做法是在完成握手后缓存一次状态，并由包装类型显式实现方法。示例中的 trackedConn 仍把读写、关闭和地址方法交给底层 TLS 连接，只增加一个不会改变协议数据的状态入口：

package main

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

// trackedConn 保留底层连接的 I/O 行为，并显式暴露 TLS 状态。
type trackedConn struct {
	net.Conn
	state tls.ConnectionState
}

// ConnectionState 让 net/http 能读取 ALPN 协商结果。
func (c *trackedConn) ConnectionState() tls.ConnectionState {
	return c.state
}

func dialTLS(ctx context.Context, network, addr string) (net.Conn, error) {
	// ServerName 应与证书和虚拟主机匹配；示例故意使用固定测试域名。
	raw, err := (&net.Dialer{}).DialContext(ctx, network, addr)
	if err != nil {
		return nil, err
	}
	cfg := &tls.Config{
		ServerName: "example.com",
		NextProtos: []string{"h2", "http/1.1"},
	}
	tlsConn := tls.Client(raw, cfg)
	// DialTLSContext 返回前完成握手，避免 Transport 读到未初始化状态。
	if err := tlsConn.HandshakeContext(ctx); err != nil {
		_ = raw.Close() // 握手失败时释放底层 TCP 连接。
		return nil, err
	}
	return &trackedConn{
		Conn:  tlsConn,
		state: tlsConn.ConnectionState(),
	}, nil
}

var transport = &http.Transport{
	// 自定义 TLS 拨号时，仍明确允许 Transport 尝试 HTTP/2。
	ForceAttemptHTTP2: true,
	DialTLSContext:    dialTLS,
}

这里的关键不是把状态复制到任意字段，而是方法签名必须准确：返回值是 tls.ConnectionState，方法名是 ConnectionState。如果状态要实时反映底层连接，也可以在方法内调用被包装的 *tls.Conn；但前提仍是握手已完成，并且包装层没有把底层连接替换成另一个没有 TLS 状态的对象。

用三项检查定位 ALPN 为空

不要直接把“HTTP/2 没启用”归因于 ALPN 丢失。可以在连接刚完成握手的位置记录以下状态；这只是排查日志，不应把敏感证书内容写入日志：

NextProtos 只是客户端声明的候选协议，不保证结果一定是 h2。如果对端不支持 ALPN 或没有交集，TLS 仍可能成功，但 NegotiatedProtocol 为空。反过来，即使状态已经是 h2，也不要把它解释成业务请求必然按某个顺序执行；协议协商和业务调度是两层问题。

常见问题

只嵌入 *tls.Conn，为什么还会丢 ALPN？

如果嵌入字段的静态类型是 net.Conn，它本身没有 ConnectionState 方法，方法不会被提升。显式写一个转发方法最清楚，也能避免以后更换底层连接类型时悄悄返回零值。

把 NextProtos 写成只有 h2 可以吗？

可以，但这会把协商范围收窄到 HTTP/2。需要兼容 HTTP/1.1 时同时声明两个协议，并根据实际协商结果处理，而不是强行把空结果改成 h2。

为什么设置了 ForceAttemptHTTP2 仍然没有 HTTP/2？

它只表示 Transport 可以尝试 HTTP/2，不能代替 TLS 的 ALPN 配置，也不能修复包装层返回的错误状态。先确认握手完成和 NegotiatedProtocol，再看对端与 Transport 的协议配置。