Nginx反向代理时需手动设置proxy_set_header X-Forwarded-Proto $scheme，因后端默认仅感知内部HTTP连接而误判协议；正确配置后，Django、Flask、Express等框架可据此识别真实客户端协议，避免HTTPS降级、Secure Cookie失效等问题。
当 Nginx 作为反向代理时，后端应用（如 Flask、Django、Node.js）常需知道客户端实际使用的协议（http 还是 https），否则可能生成错误的跳转链接或混合内容警告。默认情况下，Nginx 不会把原始请求的协议信息透传给后端，必须显式通过 proxy_set_header 设置 X-Forwarded-Proto 或 Host 等头字段。
为什么需要手动设置 Scheme？
Nginx 接收客户端请求后，与后端通信通常走内部 HTTP（比如 http://127.0.0.1:8000），此时后端看到的 request.scheme 是 http，而非用户访问的 https。若不修正，会导致：
- 重定向 URL 强制变成
http://，破坏 HTTPS 安全性 - CSRF Token、Session Cookie 的
Secure标志判断出错 - 前端构建的绝对路径（如 API 地址）协议错误
正确配置 proxy_set_header 传递 Scheme
在 location 块中添加以下指令：
proxy_set_header X-Forwarded-Proto $scheme;
其中 $scheme 是 Nginx 内置变量，值为 http 或 https，取决于客户端直连 Nginx 时使用的协议（由 listen 443 ssl 或 listen 80 决定）。
更完整的典型配置示例：
location / {
proxy_pass http://backend;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
后端如何使用 X-Forwarded-Proto？
不同框架处理方式不同，但核心逻辑一致：信任该 Header 并据此覆盖默认 scheme。
-
Django：启用
SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https') -
Flask：使用
ProxyFix中间件，如app.wsgi_app = ProxyFix(app.wsgi_app, x_proto=1) -
Express（Node.js）：设置
app.set('trust proxy', true)，自动识别X-Forwarded-Proto
注意事项与常见陷阱
务必确保安全性与一致性：
- 仅在可信代理链（即 Nginx 是唯一入口）下信任
X-Forwarded-Proto，避免客户端伪造 - 不要在多个代理层中重复设置，否则可能被覆盖或污染
- 若 Nginx 前还有 CDN 或负载均衡器（如 AWS ALB），应使用其实际传递的 Header（如
X-Forwarded-Proto可能已由 ALB 设置），此时 Nginx 应直接透传而非重写 - 检查后端日志或调试输出，确认收到的 Header 值是否符合预期（例如 curl -H "X-Forwarded-Proto: https" 测试可暴露逻辑漏洞）
