必须配置proxy_set_header x-forwarded-proto $scheme;并在后端启用对应信任机制，否则后端因仅感知内部http连接而误判协议，导致重定向异常、secure cookie失效等问题；需配合host、x-forwarded-for等头及可信代理校验。
要让后端服务正确识别用户是通过 HTTP 还是 HTTPS 访问，不能只靠 Nginx 与后端之间的连接协议（通常是 HTTP），而必须主动把客户端原始协议透传过去。
配置 proxy_set_header X-Forwarded-Proto
Nginx 需在 location 块中、proxy_pass 之前添加：
-
proxy_set_header X-Forwarded-Proto $scheme;——$scheme自动取值为http或https，取决于用户直连 Nginx 时使用的协议 - 该头字段是后端判断协议的核心依据，必须显式设置，Nginx 不会默认传递
- 若使用了 CDN 或多层代理，确保每一跳都保留或重设此头，避免被覆盖或丢失
后端必须信任并解析该头
Nginx 只负责“发”，后端框架默认仍认为请求是 HTTP（因为 Nginx 与后端之间多为内网 HTTP 通信）。需主动启用解析逻辑：
- Spring Boot：设
server.tomcat.protocol-header=x-forwarded-proto，并开启server.forward-headers-strategy=framework - Flask：用
ProxyFix中间件，指定xff和xproto字段 - Node.js Express：调用
app.set('trust proxy', true)，并确认 Nginx 已透传X-Forwarded-Proto - PHP：读
$_SERVER['HTTP_X_FORWARDED_PROTO']，再判断是否为https
配合可信代理机制防伪造
X-Forwarded-Proto 可被客户端手动构造，因此仅设 header 不够安全。需限制哪些上游可携带该头：
- 在后端 Nginx 的
http或server块中，用set_real_ip_from明确列出可信代理 IP 段（如负载均衡器、CDN 回源地址） - 虽无专门的
real_ip_proto_header，但结合set_real_ip_from+ 后端校验，可大幅降低伪造风险 - 生产环境务必避免
set_real_ip_from 0.0.0.0/0，否则任何请求都能篡改协议标识
验证是否生效
部署后可通过简单方式快速验证：
- 用 curl 发起 HTTPS 请求：
curl -k https://your-domain.com/api/test - 检查后端日志或响应中是否输出
https；若仍显示http，说明头未透传或后端未解析 - 临时在后端打印全部 headers，确认
X-Forwarded-Proto存在且值为https
