应配置 Nginx 的 proxy_redirect 将 Location 头中的 http:// 替换为 https://，并设置 X-Forwarded-Proto $scheme 等头信息，确保后端生成跳转地址时使用真实协议。
要解决后端返回 302 重定向时协议被降级为 HTTP 的问题，核心是让 Nginx 主动将 Location 响应头中的 http:// 替换为当前请求的实际协议（通常是 HTTPS），同时确保后端生成跳转地址时也知晓真实协议。
明确问题根源：为什么协议会降级？
后端服务（如 Next.js、Spring Boot）在构造 302 的 Location 头时，常依据原始请求的协议或自身配置。若它未读取 X-Forwarded-Proto，或 Nginx 未传递该头，就可能默认生成 http://example.com/path —— 即使用户正通过 HTTPS 访问，也会被跳转到不安全的 HTTP 地址，触发浏览器混合内容警告甚至拦截。
关键配置：用 proxy_redirect 升级协议
在对应 location 块中添加以下指令（顺序必须在 proxy_pass 之后）：
-
proxy_redirect http:// https://;—— 将所有以http://开头的 Location 地址，统一替换为https:// - 若需更精确控制（例如只改特定域名），可写成：
proxy_redirect http://example.com/ https://example.com/; - 支持变量动态适配（Nginx ≥ 1.11.8）：
proxy_redirect ~^http://([^/]+)(/.*)?$ https://$1$2;
必须同步设置的请求头
仅靠 proxy_redirect 是治标；配合以下头信息才能治本，防止后端源头就生成错误协议：
-
proxy_set_header Host $host;—— 保证后端看到的是真实域名，而非内部地址 -
proxy_set_header X-Forwarded-Proto $scheme;—— 显式告知后端当前是http还是https，Next.js 等框架会据此生成正确跳转地址 -
proxy_set_header X-Forwarded-For $remote_addr;—— 辅助日志与安全策略识别真实客户端 IP
验证是否生效
用 curl -I 检查实际响应头：
- 访问你的 HTTPS 地址（如
https://myapp.com/login） - 确认返回的
Location头已变为https://myapp.com/...，且不含http://或内网地址 - 若仍出现 HTTP，检查
proxy_redirect是否写在proxy_pass后、是否遗漏分号、是否匹配了完整协议前缀（包括斜杠）
