直接用router.RunTLS()失败主因是端口权限：非root用户无法绑定443端口，应改用8443开发或Nginx反代；证书需PEM格式、私钥600权限、路径绝对，且HTTP重定向须独立监听而非Gin内判断。
为什么直接用 router.RunTLS() 会失败
很多人一上来就写 r.RunTLS(":443", "cert.pem", "key.pem")，结果 panic 报错：listen tcp :443: bind: permission denied。这不是证书问题，而是 Linux/macOS 下非 root 用户无法绑定 1024 以下端口（443 就在此列）。Windows 虽不强制限制，但生产环境仍应避免直接监听 443。
- 开发阶段可用
:8443替代，绕过权限检查 - 生产环境必须用反向代理（如 Nginx）监听 443，再把流量转发到 Gin 的内部端口（如
:8080或:8443） -
RunTLS()内部调用的是http.ListenAndServeTLS()，它不支持自动重定向 HTTP → HTTPS，需自行加中间件或依赖反代完成
证书怎么生成才被浏览器信任
自签名证书在浏览器会显示“不安全”，除非手动导入根证书——这在测试环境可接受，但上线前必须换正式证书。本地快速验证可用 mkcert：
mkcert -install mkcert localhost 127.0.0.1 ::1
它会生成 localhost-key.pem 和 localhost.pem，这两个文件才能被 Chrome/Firefox 无警告加载。别用 OpenSSL 手动生成的证书，除非你同步部署了私有 CA 到所有客户端。
- 证书路径必须是绝对路径，相对路径在 daemon 化后容易失效
- 私钥文件（
key.pem）权限应设为600：chmod 600 key.pem - 证书链要完整：如果用了 Let’s Encrypt 的
fullchain.pem，就不能只传cert.pem
如何让 Gin 正确识别 HTTPS 请求来源
当 Nginx 做反向代理时，Gin 收到的永远是 http:// 请求（因为代理和后端走内网），但业务逻辑可能需要判断是否来自 HTTPS。靠 c.Request.TLS 为空，必须依赖头信息：
- 确保 Nginx 配置里加了：
proxy_set_header X-Forwarded-Proto $scheme; - Gin 中用
c.Request.Header.Get("X-Forwarded-Proto") == "https"判断 - 更稳妥的做法是启用 Gin 的
gin.ForwardedByClientIP并设置可信 IP 段：r.SetTrustedProxies([]string{"127.0.0.1"})，之后c.ClientIP()和c.IsWebsocket()等行为才可靠
HTTP 自动跳转 HTTPS 的坑
别在 Gin 里写重定向逻辑来“补救”HTTP 请求。常见错误写法：
if c.Request.TLS == nil {
http.Redirect(c.Writer, c.Request, "https://"+c.Request.Host+c.Request.RequestURI, http.StatusMovedPermanently)
}
这段代码在反向代理场景下永远不生效（c.Request.TLS 总是 nil），且暴露了后端端口（如 https://localhost:8443/...）。真正该做的只有两件事：
- Nginx 层配置 80 → 443 重定向（最干净）
- 或在 Gin 启动时单独起一个 HTTP server，只做 301 跳转：
go http.ListenAndServe(":80", http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { http.Redirect(w, r, "https://"+r.Host+r.URL.String(), http.StatusMovedPermanently) })) - 注意：这个 HTTP server 必须监听
:80，且不能和主 TLS server 共用同一个http.Server实例
单机 HTTPS 的关键不在证书本身，而在请求链路中每一层的信任传递——从 Nginx 的 X-Forwarded-Proto 头，到 Gin 的 SetTrustedProxies，再到应用层对协议的判断逻辑，漏掉任意一环都会导致混合内容、重定向循环或鉴权失败。
