Go语言API必须强制HTTPS，因HTTP明文传输会使Authorization头、JWT、签名等全被窃取；仅在反代层配TLS存在内网直连绕过、代码无法判断HTTPS环境、合规扫描失败三大风险。
Go语言API接口必须用HTTPS，否则所有认证、签名、敏感字段传输都形同虚设——HTTP明文下，Authorization头、X-Signature-Timestamp、甚至JWT payload全被中间人直接读取。
为什么不能只在反代层配TLS？
很多团队把TLS卸载到Nginx或ALB，后端Go服务仍跑在HTTP上。这看似省事，实则埋下三个隐患：
- 服务内部网络若非完全可信（如多租户K8s集群、混合云VPC），攻击者可能直连Pod IP绕过反代，拿到原始HTTP流量
-
req.TLS为nil，无法在代码中做“仅HTTPS环境允许某功能”类判断（如调试接口、管理端点） - 某些安全扫描工具（如OWASP ZAP、Burp Suite）会将“后端无TLS”标记为高危，影响合规审计结果
net/http.Server 启用TLS的最小可靠配置
别用http.ListenAndServeTLS简单封装——它不支持HTTP/2、无法细粒度控制超时、且证书热更新困难。应显式构造http.Server并传入tls.Config：
server := &http.Server{
Addr: ":443",
Handler: router,
ReadTimeout: 5 * time.Second,
WriteTimeout: 10 * time.Second,
IdleTimeout: 30 * time.Second,
TLSConfig: &tls.Config{
MinVersion: tls.VersionTLS12,
CurvePreferences: []tls.CurveID{tls.CurveP256, tls.X25519},
PreferServerCipherSuites: true,
CipherSuites: []uint16{
tls.TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
tls.TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
tls.TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256,
tls.TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256,
},
},
}
<p>log.Fatal(server.ListenAndServeTLS("cert.pem", "key.pem"))
关键点：
立即学习“go语言免费学习笔记（深入）”；
-
MinVersion: tls.VersionTLS12——禁用TLS 1.0/1.1，这两版已存在POODLE等可利用漏洞 - 显式指定
CipherSuites并按安全强度排序，避免依赖Go默认（可能含弱套件） -
CurvePreferences优先选X25519（更快更安全），再备选P256 - 证书文件必须是PEM格式，私钥不能带密码——Go标准库不支持解密加密私钥
自动重定向HTTP → HTTPS的陷阱
常见做法是在80端口起一个http.Server，收到请求后301跳转到443。但要注意两个实际问题：
- 客户端首次请求若用HTTP，
Authorization头会被浏览器/SDK丢弃（CORS预检或安全策略限制），导致跳转后认证失败 - 若API被iOS App或Android SDK直连，部分旧HTTP客户端不自动跟随301，直接返回错误而非重试
- 更稳妥的做法：在入口网关（如Traefik、Envoy）统一做重定向，Go服务只监听443；或强制客户端使用HTTPS URL（在文档、SDK初始化逻辑里硬编码
https://）
证书热更新与Let’s Encrypt集成
用certbot或acme/autocert自动续期时，别直接替换磁盘文件再调用server.TLSConfig.Reload——Go 1.19+虽支持，但需确保：
- 新证书加载期间，旧连接不受影响（
http.Server本身支持平滑reload） -
autocert.Manager的Cache实现必须线程安全，推荐用autocert.DirCache("/var/cache/certs")而非内存map - 若用自签名证书做测试，客户端必须显式设置
tls.Config.InsecureSkipVerify = true，但上线前必须删掉——这是最常被遗漏的硬编码开关
真正的难点不在配置语法，而在于证书生命周期管理是否和你的部署流程耦合：CI/CD推镜像时证书是否同步更新？滚动发布时新旧Pod是否持有不同证书导致双向校验失败？这些细节比TLSConfig字段本身更容易出问题。
