X-Forwarded-Proto是解决反向代理下HTTPS重定向错误的关键头，Nginx需配置proxy_set_header X-Forwarded-Proto $scheme;，后端框架（如Spring Boot、ASP.NET Core、Django）必须启用对应中间件并信任该头，否则应用将误判协议导致跳转降级、混合内容或认证失败。
Web 应用在反向代理后把 HTTPS 请求当成 HTTP，重定向跳转出错、混合内容警告、认证失败——根源往往就卡在 X-Forwarded-Proto 没配对。
为什么 X-Forwarded-Proto 是关键头
反向代理（如 Nginx）终止 TLS 后，把解密后的 HTTP 请求转发给后端应用。此时原始协议信息（HTTPS）已丢失，必须靠 X-Forwarded-Proto 显式告诉后端：“这个请求本来是 HTTPS 来的”。否则 ASP.NET Core、Spring Boot、Django 等框架默认按 http:// 构建 URL，导致登录回调地址错误、API 前缀不安全、CSRF 校验失败等问题。
Nginx 侧必须写的三行配置
以下配置需放在 location 块内，且必须启用：
-
proxy_set_header Host $host;—— 透传原始域名，避免后端生成错误 Host -
proxy_set_header X-Real-IP $remote_addr;—— 提供真实客户端 IP（基础安全与日志需要） -
proxy_set_header X-Forwarded-Proto $scheme;—— 核心项：$scheme 自动取值http或https，确保协议信息准确传递
⚠️ 注意：$scheme 的值取决于 Nginx 当前监听的 server 块协议。若你同时配置了 80 和 443 端口，两个 server 块都应包含该行；若只开 443（强制 HTTPS），$scheme 就恒为 https，但依然要写，不能省略。
后端应用必须做的对应处理
仅 Nginx 设置还不够，后端必须信任并使用该头：
-
ASP.NET Core：必须启用
ForwardedHeadersMiddleware，并在Program.cs中明确指定解析X-Forwarded-Proto -
Spring Boot：设置
server.forward-headers-strategy=framework，并确保TomcatServletWebServerFactory配置了setRemoteIpHeader("X-Forwarded-For")和setProtocolHeader("X-Forwarded-Proto") -
Django：启用
SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https')，且SECURE_SSL_REDIRECT才能正常工作
所有框架都要求：该中间件/配置必须在路由、静态文件、认证等中间件之前注册，否则协议信息来不及生效。
多层代理或 CDN 场景下的防坑要点
当请求经过 CDN → WAF → Nginx → 应用时，X-Forwarded-Proto 可能被中间层覆盖或伪造。此时需：
- 在最外层代理（如 CDN）确保只设一次
X-Forwarded-Proto，后续层禁止重复设置 - Nginx 若作为内层代理，应配置
proxy_pass_request_headers off;并只保留自己信任的头，或用map指令校验来源可信性 - 避免直接信任
X-Forwarded-For全链，配合set_real_ip_from+real_ip_header X-Forwarded-For提取最左合法 IP，同样逻辑可延伸至协议头校验（需自定义模块或 Lua 脚本）
