排查Nginx请求头转发致后端重定向死循环，需确认Host、X-Forwarded-Proto等关键头是否正确透传；检查后端是否依赖这些头做301/302跳转；通过curl直连后端、抓包、Nginx日志及最小化测试定位问题。
排查 Nginx 因请求头转发引发的后端重定向死循环，核心在于确认 Nginx 是否错误透传或篡改了影响重定向判断的关键请求头（尤其是 Host、X-Forwarded-Proto、X-Forwarded-Host），导致后端应用反复 301/302 跳转。
检查后端是否依赖 Host 或协议头做重定向决策
很多 Web 框架（如 Django、Spring Boot、Rails）会根据 Host 头或是否为 HTTPS 来强制跳转到规范域名或 HTTPS 地址。若 Nginx 反向代理时未正确设置这些头，后端可能误判当前请求“不合规”，从而持续重定向。
- 查看后端日志，确认重定向响应的
Location头内容（例如总跳回http://example.com，而实际访问是https://example.com） - 用
curl -v直接请求后端服务（绕过 Nginx），对比是否仍有重定向 —— 若没有，则问题大概率出在 Nginx 的头传递上 - 检查后端配置中是否启用了“强制 HTTPS”或“canonical host”逻辑（如 Django 的
SECURE_SSL_REDIRECT、Spring 的server.forward-headers-strategy=framework）
验证 Nginx 是否正确设置了关键代理头
Nginx 默认不会自动设置 X-Forwarded-* 系列头，需显式配置。若缺失或值错误，后端无法识别真实协议和主机名。
- 确保在
location或upstream块中包含以下标准设置：
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;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Port $server_port;
特别注意：
– $scheme 必须为 https（当用户 HTTPS 访问时），否则后端看到 X-Forwarded-Proto: http 就会强制跳转；
– $host 应反映客户端实际访问的域名，而非后端服务地址；
– 若使用了 CDN 或多层代理，需逐级补全 X-Forwarded-*，并确认后端只信任可信代理 IP（防伪造）。
抓包或记录原始请求/响应链路
定位死循环具体在哪一环发生，避免凭空猜测。
- 在 Nginx 中临时开启
log_format，记录入站请求头和上游响应状态码：
access_log /var/log/nginx/debug.log debug;
观察日志中是否出现连续多个 302 + Location 指向同一地址，同时比对 X-Forwarded-Proto 是否始终为 http（即使用户走 HTTPS）。
- 用
tcpdump或ngrep抓 Nginx 与后端之间的明文 HTTP 流量（确保后端未启用 HTTPS）：
确认 Nginx 发给后端的 Host 和 X-Forwarded-* 是否符合预期。
测试最小化复现并隔离变量
构造可控请求，快速验证假设。
- 用
curl模拟不同头组合，直连 Nginx：
再对比去掉 X-Forwarded-Proto 时是否触发跳转 —— 这能直接验证该头是否为关键因素。
- 临时注释 Nginx 配置中所有
proxy_set_header，仅保留Host和X-Forwarded-Proto，逐步放开其他头，观察行为变化 - 若后端支持，临时关闭其重定向逻辑（如 Django 设置
SECURE_SSL_REDIRECT = False），确认是否还有跳转 —— 若消失，即可锁定是头传递 + 后端策略共同导致
