必须配置proxy_set_header X-Forwarded-Proto $scheme;并确保后端启用解析(如Spring Boot设server.forward-headers-strategy=framework),同时用proxy_redirect或map修正重定向协议,否则后端误判为HTTP导致跳转失败、Secure Cookie失效等问题。

后端应用拿不到客户端真实协议(比如 HTTPS),根本不是 Nginx “没传”,而是它默认不透传协议信息,后端只能看到代理过来的明文 HTTP;必须主动用 X-Forwarded-Proto 头告知原始协议,并确保后端信任该头。
确认 Nginx 是否已正确设置 X-Forwarded-Proto
这是最核心的一步。若缺失或写错,后端永远无法感知原始协议。
- 检查对应
location或server块中是否包含:proxy_set_header X-Forwarded-Proto $scheme; - 确保没有被其他配置覆盖,例如:
误写成proxy_set_header X-Forwarded-Proto http;(硬编码)
或遗漏在某个子 location 中 - 验证
$scheme变量是否生效:HTTPS 请求下应为 https,HTTP 下为 http;可通过access_log打印测试:log_format proto '$remote_addr - "$request" $status "$http_x_forwarded_proto"';
检查后端是否真正读取并信任该头
即使 Nginx 传了,后端若未启用解析逻辑,仍会按自身监听协议判断。
- Spring Boot 应配置:
server.forward-headers-strategy=frameworkserver.tomcat.remote-ip-header=x-forwarded-forserver.tomcat.protocol-header=x-forwarded-proto - Tomcat 需启用
RemoteIpValve,并在server.xml中指定:<Valve className="org.apache.catalina.valves.RemoteIpValve" protocolHeader="x-forwarded-proto" /> - Node.js(Express)需使用
app.set('trust proxy', true),并确保请求经过可信代理 IP
排查响应重定向中的协议降级问题
后端生成 302 跳转时若忽略 X-Forwarded-Proto,会拼出 http:// 地址,导致跳转失败或混合内容警告。
- 在 Nginx 中用
proxy_redirect修复 Location 响应头:proxy_redirect http:// https://; - 更稳妥方式是用
map指令动态重写:map $upstream_http_location $fixed_location { ~^http://(.*) https://$1; default $upstream_http_location; }
再配合more_set_headers "Location: $fixed_location";(需 headers-more 模块) - 也可在后端代码中显式读取
X-Forwarded-Proto构造跳转 URL,避免依赖框架自动识别
验证整条链路是否生效
不要只看日志或单点输出,要端到端确认。
- 修改配置后执行:
nginx -t && nginx -s reload - 用 curl 观察实际响应头:
curl -I https://your-domain.com
确认返回的Location是https://开头 - 在后端打印
request.getScheme()或等效方法,对比X-Forwarded-Proto值是否一致 - 若仍异常,检查上游是否有 CDN/WAF/负载均衡器二次转发——它们可能覆盖或清空了该头,需在其侧也做透传


















