必须在每级Nginx的proxy_pass配置中显式设置proxy_set_header X-Forwarded-Proto $scheme，以确保后端应用获取准确的客户端协议；否则多级代理下该头易被覆盖或丢失，引发HTTPS重定向循环。
当应用部署在多级反向代理（如 CDN → Nginx → 应用服务器）后，若后端应用依赖 X-Forwarded-Proto 或 HTTPS 环境变量做重定向判断，而代理链中某一级未正确透传或覆盖协议信息，就极易触发 301/302 重定向循环——比如 HTTP 请求被反复跳转到 HTTPS，或 HTTPS 被错误降级为 HTTP。
核心问题：Proto 信息在多级代理中被覆盖或丢失
Nginx 默认不会自动设置 X-Forwarded-Proto；上游代理（如 CDN）可能已设该头，但下游 Nginx 若未显式透传或重置，后端收到的值可能仍是上一跳的原始值（甚至为空），导致应用误判客户端真实协议。尤其当 Nginx 自身监听 HTTPS，却把请求以 HTTP 转发给后端时，必须主动声明“客户端实际用的是 HTTPS”。
关键配置：在每级 Nginx 的 proxy_pass 上游块中设置 proto 头
在对应 location 或 server 块内，添加以下指令：
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
-
明确设置
X-Forwarded-Proto：用$scheme变量确保与当前 Nginx 接收请求的协议一致proxy_set_header X-Forwarded-Proto $scheme; -
避免头字段叠加：Nginx 默认会追加而非覆盖同名 header，因此需确保没有其他地方重复设置该头（如其他
proxy_set_header指令或第三方模块） -
配合其他转发头使用更稳妥：
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;<br>proxy_set_header X-Forwarded-Host $host;<br>proxy_set_header X-Forwarded-Port $server_port;
验证与调试方法
在后端应用日志或临时调试接口中打印接收到的请求头，确认 X-Forwarded-Proto 值是否符合预期（例如客户端通过 HTTPS 访问 CDN，最终到达应用时该值应为 https）。也可用 curl 模拟多级链路：
- 直接访问 Nginx（绕过 CDN）：
curl -H "X-Forwarded-Proto: http" http://your-nginx/，观察响应头和重定向行为 - 检查 Nginx access log 是否记录了正确的
$scheme和$http_x_forwarded_proto - 启用 Nginx debug log（
error_log /path/to/log debug;）可追踪 header 设置过程
进阶注意：与 real_ip 模块和 SSL 终止协同
若 Nginx 是 SSL 终止点（即监听 443 并解密 TLS），必须设置 X-Forwarded-Proto https；若只是透传 TLS（如使用 proxy_pass https://...），则通常由上游决定该头值。同时，若启用了 set_real_ip_from 和 real_ip_header，确保 X-Forwarded-For 解析不受干扰——proto 头不参与 IP 识别，但两者共同构成可信代理链元数据。
