TLS MinVersion 设置后旧客户端仍能连接的排查方式

如果 Go 服务端设置了 tls.Config.MinVersion，旧客户端仍然能连上，先不要把结论写成“MinVersion 失效”。它只约束当前 TLS 握手允许的最低协议版本；真正需要确认的是：这次连接是否经过了这份 tls.Config、是否已经建立过连接，以及最终协商出来的版本是什么。

先明确 MinVersion 的参数语义

crypto/tls.Config.MinVersion 描述的是当前配置可接受的最低 TLS 版本。比如把服务端配置为 tls.VersionTLS12，含义是 TLS 1.0 和 TLS 1.1 不应通过这次握手；它并不表示客户端一定使用 TLS 1.2，因为双方仍会在允许范围内协商更高版本。

还要区分“零值默认策略”和“显式设置”。当前 Go 文档说明，MinVersion 为零时默认最低版本为 TLS 1.2，而该包仍支持 TLS 1.0 作为显式配置的最低版本。服务端配置必须在真正创建 TLS 连接前准备好，Config 交给 TLS 函数后也不应再修改。

参数设计：先找到真正的 TLS 终止点

旧客户端能连接时，第一项检查不是继续提高版本号，而是确认连接链路。单体服务通常由 http.Server.TLSConfig 或 tls.NewListener 接受 TLS；如果入口由 Nginx、云负载均衡或网关终止 TLS，客户端协商的是代理配置，Go 后端的 tls.Config.MinVersion 只影响代理到后端的那一段。

服务端配置可以明确写成一个只负责 TLS 策略的对象，再把它交给实际监听器。这样排查时能回答“哪一份配置被挂载到哪一个监听地址”：

package main

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

func tlsServer() *http.Server {
	tlsConfig := &tls.Config{
		MinVersion: tls.VersionTLS12, // 只接受 TLS 1.2 及以上版本
	}

	return &http.Server{
		Addr:      ":8443",
		TLSConfig: tlsConfig, // 确保这份策略挂到实际 HTTPS 入口
		Handler: http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
			if r.TLS == nil {
				// 没有 TLS 状态时，说明请求没有经过当前 HTTPS 终止点。
				http.Error(w, "TLS state is missing", http.StatusBadRequest)
				return
			}
			log.Printf("negotiated=%s", tls.VersionName(r.TLS.Version)) // 记录本次握手版本
			w.WriteHeader(http.StatusNoContent)
		}),
	}
}

这个例子只说明配置关系，证书加载和监听启动代码被省略。真正上线时还要检查是否存在多个 http.Server、多个监听端口或按客户端返回配置的 GetConfigForClient。后者可以为不同的 ClientHello 返回另一份配置，不能只盯着初始化时看到的那份默认配置。

错误模型：用握手结果证明旧客户端是否被放行

“旧客户端仍能连接”至少有两种完全不同的含义：它可能真的完成了低版本 TLS 握手，也可能只是 TCP 建连成功，随后在握手或应用请求阶段失败。对 TLS 版本策略来说，应该记录握手错误，并在成功后读取 ConnectionState.Version。

func reportTLSVersion(conn *tls.Conn) error {
	if err := conn.Handshake(); err != nil {
		// 版本不满足 MinVersion 时，先保留原始握手错误。
		return err
	}

	state := conn.ConnectionState()
	if !state.HandshakeComplete {
		// 没有完成握手就不读取协商版本，避免把未填充状态当成结果。
		return fmt.Errorf("TLS handshake is incomplete")
	}
	log.Printf("TLS version=%s", tls.VersionName(state.Version)) // 记录实际协商结果
	return nil
}

上面的函数需要额外导入 fmt 和 log，这里只突出错误模型。HTTP 服务中更方便的观察点通常是处理器里的 r.TLS.Version；它回答的是“这条已经完成的请求连接使用了什么版本”，而不是“配置文件里曾经写过什么”。

兼容策略：按四类现象排查

把排查对象分成四类，通常比反复修改 MinVersion 更快：

1. 访问了错误监听器。 测试地址可能仍指向旧端口、旧进程或另一台实例。先把监听地址、证书和进程版本对应起来。
2. TLS 在代理处终止。 客户端与代理之间的版本策略不由 Go 后端控制。应分别查看边缘入口和代理到上游的两段配置。
3. 复用了已建立连接。 修改服务端配置不会让已经完成 TLS 握手的连接重新协商。用新建连接的客户端复测，并同时观察服务端记录的协商版本。
4. 实际版本并不旧。 “旧客户端”可能支持 TLS 1.2，只是操作系统或 SDK 较老。此时连接成功与 MinVersion=TLS1.2 并不矛盾。

为了避免把连接复用误判为策略未生效，客户端测试可以显式关闭 Keep-Alive，并让每次请求创建新的传输对象。生产代码不要为了测试而长期关闭连接复用：

func freshClient() *http.Client {
	transport := http.DefaultTransport.(*http.Transport).Clone()
	transport.DisableKeepAlives = true // 测试时强制每个请求建立新连接
	return &http.Client{Transport: transport}
}

如果仍需排除客户端会话缓存，测试时不要复用带有 ClientSessionCache 的自定义 tls.Config。这一步只用于定位问题；最终判断仍以服务端实际握手记录为准。

示例：把配置、错误和结果放进同一张决策表

因此，正确的修复动作通常是补齐真实入口的配置、让监控记录协商版本，或重新设计代理边界，而不是无条件把最低版本继续调高。提高下限会带来兼容性影响，必须先知道被拒绝的确实是目标旧版本。

常见问题

MinVersion 设置为 TLS 1.2 后，TLS 1.3 客户端还能连接吗？

可以。它是最低版本，TLS 1.3 高于这个下限；最终版本由双方共同支持的范围决定。

为什么 TCP 探测成功不能证明 TLS 1.0 被允许？

TCP 建连只说明网络层可达，TLS 版本是在后续握手中协商的。要看握手错误或已完成连接的 ConnectionState.Version。

改完服务端配置后，旧请求为什么还没有立刻失败？

已有 TLS 连接不会因为配置变化自动重新握手。请用新连接复测，并确认请求没有绕过目标 TLS 终止点。