唯一可靠做法是直接在Nginx的location或server块中配置proxy_set_header X-Forwarded-Proto $scheme;并确保后端框架主动信任该头，否则将引发重定向死循环、Secure Cookie失效及CSRF校验失败；$scheme动态取值http或https，必须置于proxy_pass前且不可被覆盖。
直接在 Nginx 的 location 或 server 块中写入 proxy_set_header X-Forwarded-Proto $scheme;，并确保后端框架主动信任该头——这是唯一可靠的做法。硬编码 https 或漏配都会导致重定向死循环、Secure Cookie 失效、CSRF 校验失败等典型问题。
必须用 $scheme 动态透传，不能写死
$scheme 是 Nginx 内置变量，值自动为 http 或 https，取决于客户端实际连接协议（由 listen 80 或 listen 443 ssl 决定）。这一行必须放在 proxy_pass 之前，且不能被其他配置覆盖。
- ✅ 正确：
proxy_set_header X-Forwarded-Proto $scheme; - ❌ 错误：
proxy_set_header X-Forwarded-Proto https;（HTTP 访问也会被标记为 HTTPS） - ❌ 错误：
proxy_set_header X-Forwarded-Proto $http_x_forwarded_proto;（若上游未传，该变量为空，后端收不到值）
多层代理时建议加 map 兜底
当请求经过 CDN（如 Cloudflare、阿里云全站加速）时，CDN 通常已设置 X-Forwarded-Proto。可优先复用，再 fallback 到 $scheme：
- 在
http块中定义：
default $http_x_forwarded_proto;
"" $scheme;
}
- 在
location中使用：proxy_set_header X-Forwarded-Proto $real_scheme;
配套转发头不能少
仅传 X-Forwarded-Proto 不足以还原原始请求上下文。以下头部需同步配置：
立即学习“前端免费学习笔记（深入）”；
-
proxy_set_header Host $host;（剥离端口，避免生成example.com:443这类错误跳转地址） -
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;（保留完整 IP 链，兼容多级代理） -
proxy_set_header X-Forwarded-Host $host;（显式透传原始域名） -
proxy_set_header X-Forwarded-Port $server_port;（尤其在非标准 HTTPS 端口如 8443 时关键）
后端必须主动信任并读取该头
Nginx 设置了头，后端不认等于没设。不同框架启用方式如下：
-
Django：设置
SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https')，并开启USE_X_FORWARDED_HOST = True -
Flask：使用
ProxyFix中间件，例如app.wsgi_app = ProxyFix(app.wsgi_app, x_proto=1) -
Spring Boot：配置
server.forward-headers-strategy=framework -
Express/Node.js：调用
app.set('trust proxy', true)
验证是否真正生效
别只改配置，要动手验证：
- 在后端加日志打印
req.headers['x-forwarded-proto']（或对应字段） - 分别用 HTTP 和 HTTPS 访问，确认输出值分别为
http和https - 检查重定向 Location 是否始终使用正确协议，Secure Cookie 是否正常携带
Secure标志
