Nginx HTTPS反向代理必须配置Host、X-Real-IP、X-Forwarded-For三项基础头部，并补充X-Forwarded-Proto（设为$scheme）、X-Forwarded-Host及WebSocket所需的Upgrade/Connection头，多级代理需逐级继承X-Forwarded-Proto，避免协议误判和重定向死循环。
HTTPS 环境下 Nginx 反向代理的 header 配置，核心是让后端服务准确识别客户端真实信息和当前协议状态。如果只照搬 HTTP 场景配置，容易出现重定向死循环、静态资源加载失败（Mixed Content）、IP 获取为空等问题。
必须设置的三项基础 header
无论是否启用 HTTPS，这三项都应始终存在，它们构成反向代理的“可信链路”基础：
-
Host：用
$host或更严谨的$http_host（保留原始端口），确保后端路由、多租户识别不丢失原始域名； -
X-Real-IP：设为
$remote_addr，直接传递最外层可信代理（如 CDN 或用户直连 Nginx）的 IP； -
X-Forwarded-For：必须用
$proxy_add_x_forwarded_for，它会在已有值后追加真实 IP，避免伪造或覆盖，比直接写$remote_addr更安全可靠。
HTTPS 场景不可省略的关键补充
当 Nginx 终止 SSL（即前端 HTTPS → Nginx → 后端 HTTP），后端若依赖 X-Forwarded-Proto 判断协议，就必须显式透传：
-
X-Forwarded-Proto：设为
$scheme，Nginx 会自动填入https或http，防止后端误判并错误跳转回 HTTP； -
X-Forwarded-Host：设为
$host，尤其在泛解析或多域名共用同一后端时，可让后端生成正确的绝对 URL（比如重定向地址、资源链接）； - 若后端提供 WebSocket 接口（如 /ws 路径），还需同时添加：
proxy_set_header Upgrade $http_upgrade;proxy_set_header Connection "upgrade";
缺一不可，否则连接会被降级为普通 HTTP。
多级代理下的特殊处理
一级 Nginx 做 HTTPS 终结，二级 Nginx（或更多层）仅走内部 HTTP 时，$scheme 在二级中恒为 http，直接使用会导致协议误传：
- 应在一级代理中设置
proxy_set_header X-Forwarded-Proto $scheme;； - 后续每一级代理都需继承该头，并用
$http_x_forwarded_proto判断上游协议，例如在二级 location 中：
if ($http_x_forwarded_proto = "") {
set $forwarded_proto $scheme;
}
proxy_set_header X-Forwarded-Proto $forwarded_proto;
常见错误要避开
这些写法看似简洁，实则隐患明显：
- 手动写死
proxy_set_header Host example.com;—— 所有子域名、端口、路径请求都会被强制改写，后端无法区分不同入口； - 在 http/server/location 多处重复定义同一 header —— Nginx 仅生效最后一处，容易因层级覆盖导致调试困难；
- 用
$http_x_forwarded_for替代$proxy_add_x_forwarded_for—— 前者完全依赖客户端输入，可被篡改，后者在可信链路上追加，更符合安全实践。
