Nginx反向代理HTTPS时需透传X-Forwarded-Proto头以告知后端原始协议，否则后端误判为HTTP导致重定向错误、Cookie Secure异常等问题；同时应设置Host头并配合proxy_redirect或map重写Location响应头。
当 Nginx 以 HTTPS 接收客户端请求，再反向代理到后端（尤其是 HTTP 或未正确透传协议信息的 HTTPS 后端）时，后端应用常误判为 HTTP 请求，导致跳转地址错误、资源加载失败、Cookie Secure 属性异常等问题。核心在于后端无法识别原始请求是 HTTPS，需通过 Nginx 主动透传协议标识。
设置 X-Forwarded-Proto 头
这是最直接有效的做法。Nginx 需在 proxy_pass 前明确告诉后端“原始请求走的是 HTTPS”：
- 在 location 或 upstream 对应的代理块中添加：proxy_set_header X-Forwarded-Proto $scheme;
- $scheme 在 HTTPS 请求下值为 https，HTTP 下为 http，自动适配
- 后端框架（如 Spring Boot、Django、Express）普遍依赖该 Header 判断协议，用于生成绝对 URL 或设置 Cookie 安全策略
确保 Host 头准确传递
Host 头不仅影响虚拟主机路由，也关系到后端对请求上下文的判断：
- 若后端校验 Host 或基于其生成重定向，应显式设置：proxy_set_header Host $host;（用原始 Host）或 proxy_set_header Host your-backend-domain.com;（固定后端期望的域名）
- 避免使用
$http_host，它可能携带端口（如 example.com:443），而部分后端不接受带端口的 Host 值 - 配合 proxy_http_version 1.1; 可减少因 HTTP/1.0 导致的 Host 丢失风险
处理后端重定向中的协议降级
某些后端在生成 301/302 跳转时，会忽略 X-Forwarded-Proto，直接拼接自身监听的协议（如写死 http://）：
- 可在 Nginx 中用 map 指令重写 Location 响应头：
map $upstream_http_location $fixed_location {
~^http://(.*) https://$1;
default $upstream_http_location;
} - 再在 location 块中添加：proxy_redirect ~^http://(.*) https://$1; 或更稳妥地用 more_set_headers "Location: $fixed_location";（需安装 headers-more-nginx-module）
检查后端是否启用 TLS 终止感知
部分服务（如某些 Java 应用或 API 网关）需额外配置才能信任 X-Forwarded-* 头：
- Spring Boot：设 server.forward-headers-strategy=framework 并确认 trusted-proxies 包含 Nginx IP
- Nginx 自身若作为 TLS 终止点，应关闭后端的 SSL 验证冗余（如 proxy_ssl_verify off），避免因协议不一致引发握手失败
- 若后端强制要求 HTTPS 且拒绝 HTTP 入口，确保它已配置为“信任来自 Nginx 的 X-Forwarded-Proto”而非仅看自身连接协议
