必须显式配置proxy_set_header指令传递x-forwarded-proto、host和x-forwarded-for等头部，否则后端无法识别真实协议、域名和客户端ip，导致重定向错误、混合内容警告或日志ip失真。
在 Nginx 作为反向代理时，后端服务（如 Node.js、Django、Spring Boot）常需知道客户端真实请求的协议（http 还是 https）、主机名、IP 地址等。但默认情况下，Nginx 转发请求时不会自动改写或添加这些头字段，导致后端误判为 HTTP 请求，进而生成错误的跳转链接、混合内容警告或登录失效等问题。关键解决方式就是合理使用 proxy_set_header 指令修正协议相关头部。
设置 X-Forwarded-Proto 告知后端真实协议
当 Nginx 后端是 HTTPS 入口（比如用户通过 https://example.com 访问），而 Nginx 到后端是 HTTP（如 http://127.0.0.1:3000），后端若只看 request.scheme 会得到 http，造成重定向到 http:// 等问题。此时应显式传递协议信息：
示例配置：
location / {
proxy_pass http://backend;
proxy_set_header X-Forwarded-Proto $scheme;
}
$scheme 是 Nginx 内置变量，值为 http 或 https，取决于客户端实际使用的协议。后端框架（如 Express 的 trust proxy、Django 的 SECURE_PROXY_SSL_HEADER）会依赖该头判断是否启用 HTTPS 相关逻辑。
补充 X-Forwarded-For 和 Host 头保障链路可信
仅设 X-Forwarded-Proto 不够，还需同步其他关键转发头，避免后端取错来源 IP 或域名：
-
proxy_set_header X-Forwarded-For $remote_addr;：把客户端真实 IP 传给后端（注意：若 Nginx 前还有 CDN 或负载均衡，应改用$http_x_forwarded_for拼接，防止伪造） -
proxy_set_header Host $host;：确保后端收到的Host头与原始请求一致（而非上游地址如127.0.0.1:3000），这对生成绝对 URL、多租户识别很重要 -
proxy_set_header X-Real-IP $remote_addr;：部分框架更倾向读这个头获取源 IP
避免覆盖默认行为：慎用 proxy_set_header 的继承规则
proxy_set_header 在 location 块中定义时，会完全覆盖上级（如 server 或 http 块）中同名头的设置，而非合并。例如：
若你在 http 块写了：proxy_set_header X-Forwarded-For $remote_addr;
又在某个 location 里只写了：proxy_set_header X-Forwarded-Proto $scheme;
那么该 location 下 X-Forwarded-For 将丢失，变成空值或默认值。
正确做法是：每个需要代理的 location 都显式声明所有必要头，或统一在 location 中集中设置，不依赖上级继承。
验证头是否生效的简单方法
调试阶段可在后端加一行日志输出关键头字段，例如 Node.js 中：
console.log('X-Forwarded-Proto:', req.headers['x-forwarded-proto']);
console.log('X-Forwarded-For:', req.headers['x-forwarded-for']);
console.log('Host:', req.headers.host);
也可用 curl 模拟请求并查看 Nginx 转发后的实际头：
curl -H "Host: example.com" https://your-nginx-domain/api/test
再检查后端打印结果是否符合预期。若 X-Forwarded-Proto 仍是空或 http，说明 Nginx 配置未生效或 SSL 终止未正确配置（比如没开 ssl on 或证书未加载）。
