Go crypto/tls 怎样为 TLS 客户端配置 ALPN

Go 的 crypto/tls 客户端通过 tls.Config.NextProtos 声明 ALPN（应用层协议协商）候选，切片顺序就是客户端偏好顺序。连接完成 TLS 握手后，再从 ConnectionState.NegotiatedProtocol 读取最终协议。要注意：没有共同协议时握手会失败；如果客户端没有填写候选，或者对端不支持 ALPN，握手可以成功，但最终协议字段会是空字符串。

这篇只讨论标准库客户端的配置和判断，不把 ALPN 当作加密套件，也不把空字符串误判成 HTTP/2。示例保留 ServerName，让证书校验仍然按正常流程工作。

把协议偏好写进 tls.Config

客户端先准备一个 tls.Config，把希望支持的协议放入 NextProtos。例如服务端可能同时支持 HTTP/2 和 HTTP/1.1，客户端可以把 h2 放在前面，把 http/1.1 作为兼容候选：

package main

import "crypto/tls"

func clientTLSConfig() *tls.Config {
	return &tls.Config{
		// 先尝试 h2，服务端没有共同协议时再由业务决定是否回退。
		NextProtos: []string{"h2", "http/1.1"},
		// 保留域名用于证书校验和 SNI，不要用 InsecureSkipVerify 绕过校验。
		ServerName: "api.example.com",
	}
}

NextProtos 不是“强制使用某个协议”的开关，而是客户端支持的应用层协议列表。只有双方都提供 ALPN 且存在交集，才会选出其中一个；列表顺序用于表达客户端偏好。若业务只能接受 h2，就不要悄悄把 http/1.1 放进候选，否则连接成功并不代表使用了 HTTP/2。

让 TLS 连接完成握手

使用 tls.DialWithDialer 时，配置会参与 TLS 客户端握手。握手可能由第一次读写自动触发，也可以显式调用 Handshake；为了让判断点更清楚，下面直接显式握手：

package main

import (
	"crypto/tls"
	"net"
	"time"
)

func dialTLS() (*tls.Conn, error) {
	dialer := &net.Dialer{Timeout: 5 * time.Second}
	conn, err := tls.DialWithDialer(dialer, "tcp", "api.example.com:443", clientTLSConfig())
	if err != nil {
		// 拨号或握手失败时没有可用的协商协议，交给上层决定重试或回退。
		return nil, err
	}
	if err := conn.Handshake(); err != nil {
		// 显式握手让协议判断发生在一个明确的错误边界上。
		_ = conn.Close()
		return nil, err
	}
	return conn, nil
}

这里的 ServerName 应该与目标证书和 SNI 场景匹配。不要为了让示例“更容易连通”而把 InsecureSkipVerify 设为 true；官方文档明确说明这会接受任意证书和主机名，生产客户端应继续使用正常证书验证或实现经过设计的自定义验证。

读取最终协议并区分边界

握手完成后，调用 ConnectionState 读取 NegotiatedProtocol。读取时至少区分三种情况：

package main

import (
	"crypto/tls"
	"fmt"
)

func useNegotiatedProtocol(conn *tls.Conn) error {
	defer conn.Close() // 处理完成后释放底层连接。

	state := conn.ConnectionState()
	switch state.NegotiatedProtocol {
	case "h2":
		// h2 表示 ALPN 已选中 HTTP/2，后续协议栈必须按 h2 使用连接。
		fmt.Println("selected: h2")
		return nil
	case "http/1.1":
		// 这是明确的兼容协议，不要把它当成 HTTP/2。
		fmt.Println("selected: http/1.1")
		return nil
	case "":
		// 空值表示没有完成 ALPN 选择，不能据此宣称启用了 h2。
		return fmt.Errorf("ALPN was not negotiated")
	default:
		// 只接受业务已知协议，避免把未知值传给错误的上层实现。
		return fmt.Errorf("unsupported negotiated protocol: %q", state.NegotiatedProtocol)
	}
}

空值不等于失败：如果对端没有 ALPN，TLS 连接本身仍可能成功。相反，双方都支持 ALPN 但没有共同协议时，crypto/tls 会在握手阶段返回错误，程序根本不应该继续读取应用层数据。也就是说，判断点分别是“握手错误”和“握手成功后的空协议”。

把 ALPN 失败纳入客户端回路

工程上可以把策略写成一张小表：

最小可记住的做法是：用 NextProtos 表达能力和偏好，用 Handshake 固定判断时机，用 NegotiatedProtocol 决定后续协议。不要只看连接是否成功，也不要只因为配置中出现了 h2 就认为服务端一定选择了它。

常见问题

NextProtos 只写一个协议是不是强制协商？

它表示客户端只支持这一项；若服务端没有共同协议，握手会失败。它不是绕过服务端能力的强制开关。

NegotiatedProtocol 为空时连接一定失败吗？

不一定。对端不支持 ALPN，或者客户端没有提供候选，都可能让 TLS 握手成功但字段为空；是否允许继续要由上层协议决定。

为什么不能用 InsecureSkipVerify 解决 ALPN 问题？

它只改变证书和主机名验证，不能让双方产生共同的 ALPN 协议，还会削弱连接安全性。