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