必须配置 proxy_set_header X-Forwarded-Proto $scheme，否则后端无法识别客户端真实协议（HTTP/HTTPS），导致重定向错误、Secure Cookie 失效、CSRF 校验失败等问题；还需配合 Host、X-Forwarded-For 等头，并确保后端框架信任该代理头。
在 Nginx 反向代理中配置 proxy_set_header X-Forwarded-Proto，主要是为了让后端应用（如 Flask、Django、Node.js 等）能正确识别客户端发起的是 HTTP 还是 HTTPS 请求，尤其当 Nginx 前端使用 HTTPS，而与后端通信走 HTTP 时，这个头至关重要。
为什么要设置 X-Forwarded-Proto
后端服务默认只能看到 Nginx 转发过来的请求（通常是内部 HTTP），无法感知原始请求协议。如果不显式传递，可能导致：
- 重定向链接变成
http://（即使用户访问的是https://） - CSRF 校验失败、安全 cookie（
Secure）被拒绝设置 - URL 构造错误，影响 API 返回的资源地址或跳转逻辑
标准配置写法
在 location 或 server 块中添加如下指令：
proxy_set_header X-Forwarded-Proto $scheme;
其中 $scheme 是 Nginx 内置变量，值为 http 或 https，自动匹配当前客户端请求的协议。
完整典型示例：
WebChat Voice Proxy
下载
⚠️ 已弃用 — 该技能已拆分为两个独立技能，以提升模块化程度：**webchat-https-proxy**（HTTPS/WSS 反向代理）和 **webchat-voi...**
location / {
proxy_pass http://127.0.0.1:8000;
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;
}注意代理链中的多层情况
如果请求路径是：客户端 → CDN（如 Cloudflare）→ Nginx → 后端，则：
- Nginx 默认收到的是 CDN 的 HTTP 请求（CDN 终止 HTTPS），此时
$scheme是http - 但真实原始协议可通过 CDN 设置的头（如
X-Forwarded-Proto或X-Forwarded-Ssl）获取 - 这时应改用：
proxy_set_header X-Forwarded-Proto $http_x_forwarded_proto; - 并确保 CDN 已开启转发协议头（Cloudflare 默认开启；阿里云 SLB 需手动勾选“透传 X-Forwarded-Proto”）
验证是否生效
可在后端打印请求头，或用 curl 测试：
curl -k -I https://your-domain.com
查看响应头中是否包含 X-Forwarded-Proto: https（需在 Nginx access_log 或后端日志中确认实际转发到后端的请求头）。
也可临时加一条日志便于调试：
log_format with_proto '$remote_addr - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent" "$http_x_forwarded_proto" "$scheme"';不复杂但容易忽略，设对了才能让后端“看清”用户真实访问方式。
