Go 1.7+ 必须显式设 Renegotiation: tls.RenegotiateNever，此前版本无该字段，无法处理服务端重协商请求；正确配置需在tls.Config中设Renegotiation为tls.RenegotiateNever，并搭配MinVersion等安全参数。
Go 1.7+ 必须显式设 Renegotiation: tls.RenegotiateNever
Go 1.7 起才真正支持可控的重协商策略，此前版本（如 1.6）压根没有 Renegotiation 字段，任何“绕过”尝试都会让连接在服务端发起 HelloRequest 时静默卡住或报 tls: server requested renegotiation。这不是配置问题，是结构体缺失导致的硬性限制。
正确做法是直接在 tls.Config 中设置：
cfg := &tls.Config{
Renegotiation: tls.RenegotiateNever,
MinVersion: tls.VersionTLS12,
}
-
RenegotiateNever是唯一推荐值：客户端既不发起、也不响应重协商，彻底切断该路径 - 不要用
RenegotiateOnceAsClient：它只允许一次响应，但服务端可能发多次HelloRequest，第二次仍会失败 - 绝对避免
RenegotiateFreelyAsClient：已被 Go 官方标记为不安全，且 TLS 1.3 已移除重协商机制
为什么不能靠降级 TLS 版本或调密码套件来规避？
有人试过把 MinVersion 设成 tls.VersionTLS10，或开启 PreferServerCipherSuites = true，结果发现照样失败。因为这些参数只影响初始握手阶段的协商逻辑，而重协商是独立触发的协议行为——服务端只要发送 HelloRequest，旧版 Go 就没代码去处理它。
- 抓包可见：服务端发了
Handshake: HelloRequest (0)，客户端 TCP 层保持 ESTABLISHED，但 TLS 层无任何响应 - 错误日志往往缺失：不是 panic 或明确 error，而是后续读写超时或
i/o timeout，容易误判为网络问题 - 即使服务端用了 TLS 1.3，若后端代理（如 Nginx）配置了
ssl_renegotiation on，仍可能向下透传重协商信号
Go
别折腾自定义 crypto/tls 补丁或 hook —— 这类方案要么破坏标准库稳定性，要么在升级后引发兼容性断裂。现实中的可行路径非常窄：
立即学习“go语言免费学习笔记（深入）”；
- 升级 Go 版本：这是最干净、最可持续的选择；1.7 发布已十年，主流发行版和 CI 环境都早已支持
- 协同服务端关闭重协商：比如 Nginx 加
ssl_renegotiation off;，OpenSSL 3.x 配置Options = -NoRenegotiation；注意不是所有中间件都暴露该开关
硬要客户端侧“修复”，只会把问题从 TLS 层推到应用层：比如强制短连接、加重试逻辑、甚至改用 HTTP/2（其帧机制天然不依赖重协商），但这些都治标不治本，还可能放大资源消耗。
禁用重协商本身是现代 TLS 安全基线
TLS 重协商早在 2011 年就被 CVE-2011-1473 暴露严重中间人风险，虽然“安全重协商”（RFC 5746）打了补丁，但实际部署中仍存在大量未正确实现的服务器。Go 选择默认禁用，并要求显式开启，是符合当前最佳实践的。
真正容易被忽略的是：这个设置必须在创建 http.Transport 或 http.Server 之前完成，且一旦赋值就不可修改。比如 srv.TLSConfig = cfg 必须在调用 srv.ListenAndServeTLS 前执行，否则等于没设。
