必须显式设置 proxy_set_header x-forwarded-proto $scheme；因为 nginx 不自动添加该头，后端依赖它判断客户端真实协议，错误设置会导致 https 请求被误判为 http，引发重定向回 http、secure cookie 失效等问题。
当使用 Nginx 作为反向代理时，如果后端应用（如 Django、Flask、Rails 或某些 OAuth 流程）依赖 X-Forwarded-Proto 判断当前请求是 HTTP 还是 HTTPS，而该 header 未被正确设置，就容易出现「302 重定向回 HTTP」的问题——比如用户访问 https://example.com/login，后端却跳转到 http://example.com/callback，导致混合内容或重定向失败。
为什么需要显式设置 X-Forwarded-Proto
Nginx 默认不会自动添加 X-Forwarded-Proto。即使你用 proxy_pass https://backend，也只是代理到后端的 HTTPS 端口，不代表客户端访问的是 HTTPS。真正决定“用户看到的是什么协议”的，是客户端与 Nginx 之间的连接（即 $scheme）。所以必须把 $scheme 显式透传给后端：
-
$scheme在 Nginx 中表示当前请求的协议（http或https），由监听套接字和 TLS 终止决定 - 后端应用（尤其是框架中间件）依赖这个 header 生成绝对 URL、判断安全上下文、构造重定向 Location
- 不设或设错（如固定写死
https），会导致后端误判，尤其在本地调试走 HTTP 时出问题
正确配置 proxy_set_header X-Forwarded-Proto
在 Nginx 的 location 或 server 块中添加这一行即可：
proxy_set_header X-Forwarded-Proto $scheme;
⚠️ 注意事项：
安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。
- 不要写成
proxy_set_header X-Forwarded-Proto https;—— 这会强制所有请求都标为 HTTPS，HTTP 请求也会被后端当成 HTTPS，引发 Cookie（Secure）、CSRF、重定向等异常 - 确保它出现在
proxy_pass之前，且没有被其他配置覆盖（例如被 include 的通用 conf 覆盖） - 若使用了多层代理（如 CDN → Nginx → Backend），需确认上一级是否已设置该 header；重复设置一般无害，但应以最靠近客户端的一层为准
配合其他关键转发头一并设置
仅设 X-Forwarded-Proto 往往不够。常见还需同步透传以下 header，让后端能准确还原原始请求上下文：
-
X-Forwarded-For $remote_addr;：传递真实客户端 IP（注意：若经多层代理，需用$proxy_add_x_forwarded_for追加） -
X-Forwarded-Host $host;：避免后端基于Host头生成错误的域名 URL -
X-Forwarded-Port $server_port;：尤其在非标准端口（如 8443）终止 HTTPS 时有用 - （可选）
Host $host;：显式重写 Host 头，防止后端收到的是上游地址（如127.0.0.1:8000）
验证是否生效
配置完成后 reload Nginx（nginx -s reload），然后用 curl 检查后端是否收到预期 header：
curl -I https://your-domain.com/health<br># 查看响应头中是否有：<br># X-Forwarded-Proto: https
更直接的方式是让后端打印或记录收到的请求头（例如 Django 的 request.META.get('HTTP_X_FORWARDED_PROTO')），确认值为 https（HTTPS 访问时）或 http（HTTP 访问时）。
不复杂但容易忽略。只要确保 $scheme 准确透传，再配好 Host 和 For，绝大多数重定向协议回退问题就解决了。
