Go TLSTLS 版本限制导致老客户端连接失败怎么办

老客户端连不上 Go 的 TLS 服务时，先不要直接把证书校验关掉，也不要只盯着服务端配置。TLS 版本必须由客户端允许范围和服务端允许范围共同决定：客户端的 MaxVersion 太低，或者服务端的 MinVersion 太高，都会在握手阶段失败。

本文只处理“版本限制导致握手失败”这一类问题。证书链、SNI、密码套件和代理改写也会产生相似错误，若版本证据对不上，就应转向这些方向排查。

官方资料：https://pkg.go.dev/crypto/tls

先把客户端和服务端的版本范围放在一起

tls.Config 的 MinVersion 和 MaxVersion 是边界，不是“强制使用某个版本”的单独开关。连接成功的前提是双方允许范围存在交集。例如客户端最多只接受 TLS 1.1，而服务端最低要求 TLS 1.2，握手就没有可选版本。

排查时把两端的配置同时列出来，尤其检查是否在自定义客户端或 Transport 中写过 MaxVersion，以及服务端是否在专用监听器上提高了 MinVersion。没有显式配置时，还要结合当前 Go 版本的默认行为判断，不能用旧项目的经验代替文档。

从握手错误中确认是不是版本问题

可以先用一个显式的客户端配置记录握手结果。下面的示例不跳过证书校验；InsecureSkipVerify 不是版本兼容修复手段。

package main

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

func main() {
    transport := &http.Transport{
        TLSClientConfig: &tls.Config{
            MinVersion: tls.VersionTLS12, // 只接受 TLS 1.2 及以上，按服务端能力调整
            MaxVersion: tls.VersionTLS13, // 上限过低时，可能排除服务端唯一可用版本
            ServerName: "api.example.com", // 显式指定 SNI，避免把域名问题误判成版本问题
        },
    }
    client := &http.Client{Transport: transport}

    resp, err := client.Get("https://api.example.com/health") // 先用最小请求触发握手
    if err != nil {
        fmt.Printf("TLS 请求失败：%v\n", err) // 记录原始错误，不用跳过证书校验来掩盖原因
        return
    }
    defer resp.Body.Close() // 请求成功后释放响应体，避免连接复用异常

    state := resp.TLS // HTTPS 响应携带实际协商状态
    if state != nil {
        fmt.Printf("协商版本：%s，密码套件：%s\n",
            tls.VersionName(state.Version), tls.CipherSuiteName(state.CipherSuite))
    }
}

如果失败发生在 client.Get 的握手阶段，且两端范围没有交集，版本方向成立；如果已经协商出版本后才报证书错误，就不要继续调整版本。成功后的 resp.TLS.Version 是复查证据，不能把预设的 Min/Max 当成实际结果。

兼容旧客户端时只放宽专用边界

先确认老客户端实际支持的最高版本，再决定是否需要调整服务端。若它能支持 TLS 1.2，优先修正客户端的 MaxVersion 或升级客户端；只有确实存在必须兼容的旧协议时，才在独立入口使用更窄的配置，并记录风险、调用方和退出时间。

package main

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

func legacyTLSConfig() *tls.Config {
    return &tls.Config{
        MinVersion: tls.VersionTLS12, // 兼容入口也保持现代最低版本，先不要盲目降级
        MaxVersion: tls.VersionTLS12, // 用窄范围隔离特殊客户端，避免放宽所有连接
    }
}

func main() {
    mux := http.NewServeMux()
    mux.HandleFunc("/health", func(w http.ResponseWriter, r *http.Request) {
        w.WriteHeader(http.StatusOK) // 用固定探针确认入口仍能提供服务
    })

    server := &http.Server{
        Addr:      ":8443",
        Handler:   mux,
        TLSConfig: legacyTLSConfig(), // 只绑定到经过评估的专用服务，不修改全局客户端
    }
    log.Fatal(server.ListenAndServeTLS("server.crt", "server.key")) // 证书文件按部署环境提供
}

示例把兼容范围写成专用配置，是为了让放宽或收紧的影响面可见。若确需支持更老版本，应先查当前 Go 版本和部署策略是否允许，并把它限制在隔离入口；不要用全局共享的 tls.Config 让所有服务跟着改变。

用实际协商版本做最后确认

修复后至少确认三件事：老客户端可以完成握手；普通客户端仍使用预期的最低版本；服务端日志没有把证书错误、SNI 错误和版本错误混在一起。对 Go 客户端，查看 resp.TLS.Version；对服务端，可在处理器中读取 r.TLS.Version，但不要把协商版本当成安全策略本身。

一句话总结：先证明是版本范围不相交，再调整真正造成冲突的一端；兼容旧客户端要收敛到专用配置，并用实际协商结果复查。

常见追问

为什么把 MaxVersion 设置成 TLS 1.2 仍然可能失败？

因为服务端可能只允许 TLS 1.3，或者中间设备要求另一组密码套件。MaxVersion 只是客户端上限，必须与服务端的完整握手条件一起看。

InsecureSkipVerify 能解决老客户端连接失败吗？

它影响证书验证，不会让双方凭空获得共同的 TLS 版本；如果根因是版本不相交，关闭校验也不能提供可靠修复。