Go tls.Config怎样配置 ALPN 并选择协议为什么结果为空或不符合预期

tls.Config 的 NextProtos 用于声明支持的 ALPN 协议，真正选中的值要在 TLS 握手成功之后，从 ConnectionState().NegotiatedProtocol 读取。结果为空不等于 TLS 一定失败：可能没有启用或没有协商 ALPN，也可能读状态时握手还没完成。ALPN 只决定应用协议名称，不会替你实现 HTTP/2 或自定义协议。

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

1. 问题原文：配置了协议列表，为什么得到空字符串？

在排查“客户端配置了 h2，却没有看到 h2”的问题时，我会先把证书校验、握手状态和协议选择拆开。证书不可信导致握手失败时，不该继续解释 ALPN 空值；握手尚未执行时，读取到的零值也不代表服务端拒绝了协议。

NextProtos 中的字符串必须是精确的协议标识，例如 h2、http/1.1，而不是 HTTP/2、https 或 TLS1.3。TLS 版本和密码套件也不是 ALPN 标识。列表是能力声明，不是任意请求一个名称就能要求对端支持。

2. 先给结论：确认的是这条连接实际完成的握手

tls.Dialer 在返回成功连接前完成 TLS 握手，所以它适合编写一个小型协商诊断程序。若使用 tls.Client 包装现有 net.Conn，则应显式调用 HandshakeContext 并检查错误，之后再读取 ConnectionState；包装连接本身不等于握手完成。

标准库文档说明，NextProtos 为空或对端未支持 ALPN 时，连接可以成功但 NegotiatedProtocol 为空。双方有协议列表却没有兼容选择时通常会握手失败；HTTP/1.1 兼容处理等具体行为仍以工具链实现与应用栈约定为准，不能把所有“不符预期”都归为同一种空值情况。

3. 常见误区：协议被选中并不代表应用已经可用

特别是自行创建的 TLS socket，即使协商为 h2，也不能直接写入 HTTP/1.1 文本请求。下面代码只打印协议，不发送应用层字节。我会把“成功协商”和“应用请求成功”作为两个不同结果保留，避免诊断程序把一项检查扩大成完整兼容性结论。

4. 正确做法：保持身份验证并读取实际协议

package main

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

func inspectALPN(address string) error {
 host, _, err := net.SplitHostPort(address)
 if err != nil { return fmt.Errorf("地址必须含端口: %w", err) }
 ctx, cancel := context.WithTimeout(context.Background(), 8*time.Second)
 defer cancel()
 dialer := tls.Dialer{
  NetDialer: &net.Dialer{Timeout: 5*time.Second},
  Config: &tls.Config{
   ServerName: host,
   // 这里只探测协商，不发送 HTTP 数据。
   NextProtos: []string{"h2", "http/1.1"},
  },
 }
 raw, err := dialer.DialContext(ctx, "tcp", address)
 if err != nil { return fmt.Errorf("连接或握手失败: %w", err) }
 defer raw.Close()
 conn, ok := raw.(*tls.Conn)
 if !ok { return fmt.Errorf("返回连接不是 TLS 连接") }
 // tls.Dialer 返回前已经完成握手，此时才读取协商状态。
 state := conn.ConnectionState()
 fmt.Printf("握手完成=%t ALPN=%q\n", state.HandshakeComplete, state.NegotiatedProtocol)
 switch state.NegotiatedProtocol {
 case "h2":
  fmt.Println("已选 h2；实际通信需要 HTTP/2 实现")
 case "http/1.1":
  fmt.Println("已选 http/1.1；实际通信需要 HTTP/1.1 实现")
 case "":
  return fmt.Errorf("未协商应用协议，需要业务明确是否允许回退")
 default:
  return fmt.Errorf("不接受的应用协议 %q", state.NegotiatedProtocol)
 }
 return nil
}

func main() {
 // 使用自己有权连接且证书有效的服务地址，如 service.example:443。
 if len(os.Args) != 2 {
  fmt.Fprintln(os.Stderr, "用法: alpn-check 主机:端口")
  os.Exit(2)
 }
 if err := inspectALPN(os.Args[1]); err != nil {
  fmt.Fprintln(os.Stderr, err)
  os.Exit(1)
 }
}

程序要求传入完整的主机与端口，IPv6 地址应使用标准的方括号形式。ServerName 取地址中的主机，保留系统根证书校验，不设置 InsecureSkipVerify。私有 CA 场景应将组织批准的 CA 配置进 RootCAs；域名不匹配则修复 ServerName、连接目标或服务证书，不能用跳过验证掩盖。

示例的八秒上下文限制拨号与握手等待，五秒拨号超时限制网络建立。实际通信阶段还需独立的读写期限或高层客户端超时。调用方应使用自己有权访问的服务进行尝试；本文没有连接任何目标，也没有把预期协商结果冒充已执行的输出。

服务端通过证书配置与 NextProtos 声明能力，若使用 GetConfigForClient 返回另一份 Config，应确认真正被握手采用的那份配置包含正确列表。配置投入使用后不要并发修改 NextProtos 的底层切片；需要变更时构造新的配置并按照服务的生命周期规则切换。

5. 边界情况：空结果、回退和代理终止

示例把空协议作为业务错误返回，这是一个明确的诊断策略，不是声称所有 TLS 客户端都必须拒绝空值。如果业务允许没有 ALPN 时使用历史协议，应把回退条件写在应用层；如果自定义协议强制要求 ALPN，则空值就应终止，不能继续猜测。

存在反向代理或负载均衡时，客户端协商的是它实际连接到的 TLS 终止点。代理到 Go 服务可能又建立另一条连接，使用不同 ALPN，甚至是明文内部连接。此时应按连接段分别记录协议，不能用后端 ConnectionState 推断终端客户端的原始协商。

如果正在使用 net/http 的高层 Transport 或 Server，应优先按该组件的 HTTP 协议配置方式处理。手动替换 TLS 配置或自定义拨号逻辑，可能影响高层自动配置行为，具体取决于所用工具链和传输配置。仅修改 NextProtos 不能保证原有 HTTP 栈拥有对应实现，也不能据此跨版本承诺行为完全一致。

6. 延伸问题：怎样缩小排查范围？

NegotiatedProtocolIsMutual 能作为协商成功依据吗？不能；该字段已经废弃，文档说明它始终为 true，不能代替握手状态和实际协议值。SNI 和 ALPN 是同一功能吗？不是，ServerName 参与服务身份与虚拟主机选择，NextProtos 表达应用协议能力。为什么强制提供 h2 后无法连接？先保留握手错误，再核对当前 TLS 终止点的协议支持，别先去修改证书校验或在应用层尝试不匹配的协议。

对这类问题，我会按“握手是否成功、读取的是哪条连接、有效配置是什么、结果是否有应用实现承接”的顺序收窄范围。接口与空值语义以 crypto/tls 官方文档为依据，不将 ALPN 的选择结果扩大为完整的服务可用性保证。