https请求头重写失效主因是rewrite未置于listen 443 ssl块内、未透传x-forwarded-proto $scheme、未修正后端返回的location降级，且需用curl验证真实响应链。
HTTPS 配置后请求头重写失效，通常不是 rewrite 本身没运行，而是重写逻辑被覆盖、协议判断出错，或重写后的请求没被正确传递给后端。关键要确认：重写是否真在 HTTPS 流量中生效？重写后协议和路径是否保持完整？后端能否识别原始 HTTPS 上下文？
检查 rewrite 是否落在正确的 server 块里
很多失效源于 rewrite 写在了监听 80 的 server 块中，而监听 443 的块里空着或只配了证书。HTTPS 请求根本不会进入 80 的块，自然不触发任何重写。
- 确保需要对 HTTPS 请求生效的 rewrite（比如去除前缀、跳转内部路径）明确写在
listen 443 ssl的 server 块内 - 避免在 443 块里误写
return 301 http://...，这会把 HTTPS 主动降级，浏览器直接拦截 - 如果用 if 判断做条件重写，必须包含
$scheme = https或类似判断，否则 HTTP 和 HTTPS 共用一块配置时容易误触发
确认重写后未丢失协议与 Host 信息
rewrite 只改请求 URI，不自动更新请求头。若重写后 proxy_pass 到后端，但没同步透传协议和域名，后端就无法生成正确的跳转或 Cookie。
- 必须设置
proxy_set_header X-Forwarded-Proto $scheme;，让后端知道原始是 HTTPS - 推荐用
proxy_set_header Host $host;，而不是$http_host，避免携带 :443 端口导致后端解析异常 - 若 rewrite 改写了路径（如
rewrite ^/api/(.*)$ /$1 break;），末尾一定要加break，否则可能触发二次匹配或跳转
处理后端返回的 Location 头降级问题
即使 Nginx 正确接收 HTTPS 并重写路径，后端仍可能返回 Location: http://...，导致浏览器跳到不安全地址。
- 用
proxy_redirect http:// https://;直接替换响应头中的协议前缀 - 更稳妥的方式是配合 map 指令动态修正：
map $upstream_http_location $fixed_location { ~^http://(.*) https://$1; default $upstream_http_location; }
再在 location 中加more_set_headers "Location: $fixed_location";（需启用 headers-more 模块） - 检查后端是否启用了“信任 X-Forwarded-*”机制，例如 Spring Boot 要设
server.forward-headers-strategy=framework
用 curl 验证，别依赖浏览器
浏览器缓存 301、自动补全协议、跳过不安全提示，会掩盖真实行为。必须用命令行验证原始响应链。
- 执行
nginx -t && nginx -s reload确保配置已加载 - 用
curl -I https://yourdomain.com/path查看返回的 Status 和 Location - 加
-v参数观察完整跳转过程：curl -v https://yourdomain.com/login，确认每一步协议是否始终为 https
