重定向死循环源于后端无法识别真实HTTPS协议，需Nginx配置proxy_set_header X-Forwarded-Proto $scheme;并确保后端（如Django、Spring Boot、WordPress）启用对应信任机制，否则后端误判为HTTP而强制跳转，形成http↔https闭环。
当 Nginx 作为反向代理或负载均衡器部署在 HTTPS 站点前（例如后端应用只监听 HTTP），若应用框架（如 Django、Spring Boot、WordPress）依赖 X-Forwarded-Proto 判断当前是否为 HTTPS 请求来生成重定向 URL，而 Nginx 未正确透传该头，就极易触发「301/302 重定向死循环」——浏览器不断在 http:// 和 https:// 之间跳转。
为什么会出现重定向死循环
典型场景：用户访问 https://example.com/login → Nginx 终止 SSL 并转发请求到后端 HTTP 服务（如 http://127.0.0.1:8000）→ 后端应用检查到请求协议是 http（因真实连接是 HTTP），又发现用户未登录，于是返回 Location: http://example.com/login → 浏览器跳转到 HTTP 地址 → 若 Nginx 配置了强制 HTTPS 重定向，又跳回 https:// → 循环开始。
根本原因在于：后端应用无法感知原始请求是 HTTPS，因为它只看到 Nginx 发来的 HTTP 请求。必须靠 X-Forwarded-Proto 头告知它原始协议。
正确配置 proxy_set_header X-Forwarded-Proto
在 Nginx 的 location 或 server 块中，确保包含以下指令：
-
proxy_set_header X-Forwarded-Proto $scheme;—— 将原始请求协议（http或https）透传给后端 -
proxy_set_header X-Forwarded-For $remote_addr;—— 可选但推荐，用于传递真实客户端 IP -
proxy_set_header Host $host;—— 确保后端收到正确的 Host 头（尤其多域名场景）
示例配置片段：
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
location / {
proxy_pass http://backend;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header Host $host;
}
⚠️ 注意：$scheme 是 Nginx 内置变量，在 HTTPS server 块中值为 https，HTTP 块中为 http，无需硬编码。
后端应用必须信任并使用该 Header
仅 Nginx 设置还不够。后端需明确启用对 X-Forwarded-Proto 的信任与解析，否则仍会忽略它：
-
Django：设置
SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https')，并确保USE_X_FORWARDED_HOST = True -
Spring Boot：配置
server.forward-headers-strategy=framework（2.2+）或使用TomcatServletWebServerFactory手动添加 RemoteIpValve -
WordPress：在
wp-config.php中添加：if ($_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') { $_SERVER['HTTPS'] = 'on'; } -
Node.js（Express）：启用
app.set('trust proxy', true)，它会自动读取X-Forwarded-Proto
额外排查要点
即使 header 设置正确，仍可能失败，需检查：
- Nginx 是否在多个层级（如 include 文件、多个 location）重复或覆盖了
proxy_set_header，导致最终未生效 - 后端是否运行在容器中（如 Docker），且容器网络未将 Nginx 的请求识别为可信代理（部分框架默认只信 localhost）
- 是否启用了
proxy_redirect且配置不当，导致 Nginx 自行改写后端返回的Location头（此时应设为proxy_redirect off;，让后端自己生成正确跳转） - 浏览器缓存了错误的 301 重定向，测试时用无痕窗口或
curl -I验证响应头
不复杂但容易忽略。关键就是两端对齐：Nginx 要传，后端要认，中间别被覆盖或绕过。
