Go tls.VerifyConnection 为什么在恢复会话时仍会执行

VerifyConnection 在恢复会话时仍执行是 Go 的明确设计：TLS 恢复可能跳过常规的证书重新验证，但应用自定义的连接约束不能因此被绕过，所以 Go 会在恢复握手分支再次调用这个回调。可以通过 ConnectionState.DidResume 判断本次连接是否来自会话恢复。

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

• VerifyConnection 覆盖普通连接和恢复连接。
• VerifyPeerCertificate 不会在恢复连接上调用。
• 回调按 TLS 连接执行，不是按每个 HTTP 请求执行。

恢复握手为什么还要经过回调

完整握手会处理对端证书并执行常规证书校验；恢复握手复用先前建立的会话状态，通常不会重新走同一套证书消息处理路径。如果自定义策略只依赖完整握手中的证书回调，恢复连接就可能绕开这项策略。

Go 因此把 VerifyConnection 定义为“每个连接都执行”的策略入口。官方源码在恢复分支中也显式调用该回调，并注明恢复连接不会重新验证证书，需要继续执行连接级验证。回调返回非空错误时，本次握手立即失败。

用 DidResume 观察回调边界

下面的配置只记录回调次数和恢复标记，同时保留 Go 默认的证书链与主机名校验。第一次连接通常是完整握手；后续新连接是否恢复，取决于客户端缓存、服务端票据、协议版本和服务端是否接受恢复等条件。

var verifyCount atomic.Int64

cfg := &tls.Config{
    ServerName:         "api.example.com",               // 中文注释：参与主机名校验
    ClientSessionCache: tls.NewLRUClientSessionCache(8), // 中文注释：客户端保存可恢复会话
    VerifyConnection: func(cs tls.ConnectionState) error {
        n := verifyCount.Add(1)
        // 中文注释：DidResume 只表示本次 TLS 连接是否成功恢复
        log.Printf("verify=%d resumed=%t", n, cs.DidResume)

        // 中文注释：默认校验开启时应存在经过验证的证书链
        if len(cs.VerifiedChains) == 0 {
            return errors.New("没有可用的已验证证书链")
        }
        return nil
    },
}

这里没有设置 InsecureSkipVerify，所以标准验证仍在。若你的回调用于证书公钥约束、SCT 检查或其他安全策略，应让普通握手和恢复握手返回一致的决策。

观察实验要强制建立新 TLS 连接

我在排查这类问题时，最容易误判的是 HTTP keep-alive：第二个请求可能复用第一条 TLS 连接，根本没有新握手，自然也不会再次调用回调。为了观察会话恢复，可以在实验客户端中关闭 keep-alive，让每次请求建立新连接；生产环境通常不应为了观测而长期关闭连接复用。

transport := &http.Transport{
    TLSClientConfig:   cfg,
    DisableKeepAlives: true, // 中文注释：仅实验时强制每次请求创建新连接
}
client := &http.Client{
    Transport: transport,
    Timeout:   10 * time.Second, // 中文注释：限制连接和握手等待时间
}

for i := 0; i 

按现象定位没有恢复或没有再次调用

如果业务不允许会话恢复，可设置 SessionTicketsDisabled；但多数场景更适合保留恢复，并让 VerifyConnection 对完整握手与恢复握手执行同一套连接策略。

常见问题

VerifyConnection 会对每个 HTTP 请求执行吗？

不会。它跟随 TLS 握手执行。多个请求复用同一条 keep-alive 连接时，不会为每个请求重新握手。

恢复连接上应该改用 VerifyPeerCertificate 吗？

不应该。官方文档明确说明 VerifyPeerCertificate 不在恢复连接上调用；需要覆盖恢复场景时应使用 VerifyConnection。