应使用 X-Forwarded-Proto 而非 X-Forwarded-SSL，因后者非标准、Nginx 不支持、各中间件解析不一致；需在每级 Nginx 中配置 proxy_set_header X-Forwarded-Proto $scheme;、X-Forwarded-Port $server_port; 和 Host $http_host;，后端据此准确识别 HTTPS 状态。
多级 Nginx 代理中，X-Forwarded-SSL 并非标准 HTTP 头，也不被 Nginx 原生支持或默认识别。它在实际生产中极少使用，主流方案是统一用 X-Forwarded-Proto 标识协议类型（http 或 https），配合 X-Forwarded-Port 补充端口信息。只要这二者配置正确且逐层透传，后端就能准确判断原始请求是否为 HTTPS，避免重定向循环、混合内容警告或鉴权失败。
为什么不用 X-Forwarded-SSL？
该头部未被 RFC 定义，不同中间件（如 Tomcat、Spring Boot、某些 CDN）对其解析行为不一致，部分服务甚至完全忽略。Nginx 本身不生成、不校验、也不推荐设置此头。强行添加反而可能引发后端逻辑误判（例如将 X-Forwarded-SSL: on 错误等价于 TLS 终止在本层）。
必须逐层配置的三项关键头部
每级 Nginx（无论 CDN → 边缘 Nginx → 应用 Nginx）都需显式设置以下三行，不可省略：
-
proxy_set_header X-Forwarded-Proto $scheme; —— 传递原始协议（
http或https），不是硬编码https - proxy_set_header X-Forwarded-Port $server_port; —— 传递原始请求端口（如 443 或 80），便于后端构造绝对 URL
-
proxy_set_header Host $http_host; —— 保留客户端原始 Host（含端口与大小写），比
$host更严谨，避免虚拟主机路由出错
后端如何安全识别 HTTPS 状态？
以常见 Java（Tomcat/Spring Boot）和 Node.js（Express）为例：
-
Tomcat：在
server.xml的Connector中配置protocolHeader="x-forwarded-proto"和secure="true"，并启用RemoteIpValve解析X-Forwarded-For与X-Forwarded-Proto -
Spring Boot：设
server.forward-headers-strategy=framework，自动信任X-Forwarded-*头；或使用ForwardedHeaderFilter -
Express：启用
app.set('trust proxy', true)，框架会自动根据X-Forwarded-Proto设置req.protocol
验证是否生效的实操方法
在最终后端服务中打印请求头，或临时加一个调试 endpoint：
- 发起 HTTPS 请求（如
curl -k https://example.com/test） - 检查后端收到的
X-Forwarded-Proto值是否为https（不是空、不是http） - 确认
X-Forwarded-Port是 443（不是 80 或代理监听端口） - 若任一环节缺失或被覆盖（例如某层 Nginx 没写
proxy_set_header），则值会退化为默认值，说明链路中断
不复杂但容易忽略：多级代理的关键不在“加新头”，而在“每一跳都不丢关键头”。X-Forwarded-SSL 不是解法，标准化透传 X-Forwarded-Proto 才是可靠路径。
