Revel 框架不处理 HTTPS 证书，必须由 Nginx 等反向代理终止 TLS；其内置 HTTP 服务器缺乏生产级 TLS 能力，且会因缺失 X-Forwarded-Proto 等关键请求头导致会话、重定向和 Cookie 异常。
Revel 框架本身不处理 HTTPS 证书；必须由前置反向代理（如 Nginx）终止 TLS，Revel 只接收解密后的 HTTP 请求。 直接让 Revel 启动 HTTPS 服务不仅绕过最佳实践，还会导致会话、重定向、静态资源路径等逻辑异常——这是新手最常踩的坑。
为什么不能用 revel run -https 或自建 TLS
Revel 的内置 HTTP 服务器基于 Go 标准库 net/http，虽支持 http.ListenAndServeTLS，但：
• 它不具备生产级 TLS 能力：不支持 OCSP Stapling、ALPN 协商优化、SNI 多证书、自动续期；
• Session 依赖 X-Forwarded-Proto 判断协议类型，若 Revel 自己做 TLS，反向代理层缺失该头会导致 revel.Session().Get() 返回空或失效；
• revel run 是开发命令，其 TLS 支持仅用于本地调试，无证书热加载、密钥保护、性能调优机制；
• 若强行启用，Nginx 再套一层 TLS（即 TLS over TLS），会触发协议降级或握手失败。
Nginx 反向代理必须传的四个关键请求头
当 Nginx 终止 HTTPS 后转发请求给 Revel（例如 http://127.0.0.1:8089），以下头字段缺一不可：
-
proxy_set_header Host $host;—— 保证 Revel 路由和生成 URL 时使用原始域名 -
proxy_set_header X-Real-IP $remote_addr;—— 用于日志和限流获取真实客户端 IP -
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;—— 避免多层代理丢失原始 IP 链 -
proxy_set_header X-Forwarded-Proto https;—— 最关键一项，否则 Revel 认为是 HTTP 请求，生成的重定向 URL、CSRF Token、Cookie Secure 标志全错
错误示例：X-Forwarded-Proto http 或完全不设，会导致登录后跳转回 http:// 页面，触发混合内容警告甚至会话劫持。
Let's Encrypt + Certbot 自动续期与 Revel 零耦合
证书管理应完全脱离 Revel 应用生命周期。推荐用 Certbot + systemd timer 实现全自动：
- 证书存放在统一位置，如
/etc/letsencrypt/live/example.com/fullchain.pem和privkey.pem - Nginx 配置中直接引用，无需 Revel 读取或解析证书文件
- Certbot 续期后 reload Nginx：
sudo nginx -t && sudo systemctl reload nginx - Revel 进程完全无感知——它只看到来自
127.0.0.1的普通 HTTP 流量
切勿在 Revel 代码里调用 crypto/tls 加载 PEM，也不要在 app.conf 中配置证书路径。那不是 Revel 的职责边界，反而引入启动失败、权限问题、证书过期静默故障等风险。
真正容易被忽略的是：所有前端资源（CSS/JS/图片）、API 响应中的绝对 URL（比如邮件模板里的重置链接）、以及 revel.RenderArgs["BaseURL"] 的构造，都必须依据 X-Forwarded-Proto 和 Host 头动态生成，而不是硬编码 https://。这点在本地开发（HTTP）和线上环境（HTTPS）共用同一套 Revel 代码时尤为关键。
