“重定向次数过多”本质是Nginx配置中循环路径起点与终止条件缺失。需通过access.log定位请求链，排查try_files隐式循环、rewrite/return重复匹配及后端Location头未修正三类主因。
浏览器报“重定向次数过多”（ERR_TOO_MANY_REDIRECTS），基本是 Nginx 配置中某处 302 跳转反复触发，形成闭环。排查核心不是找“哪个 return 或 rewrite 写错了”，而是定位**循环路径起点 + 终止条件缺失**。
看 access.log 快速锁定循环请求链
打开 /var/log/nginx/access.log，执行：
awk '$9 ~ /^(301|302)$/ {print $7, $9, $13}' /var/log/nginx/access.log | tail -20
重点关注三列：
- $7：原始请求路径（如 /login）
- $9：返回状态码（确认是否连续出现 302）
- $13（即 $upstream_http_location）：实际跳转目标（如 /login、https://example.com/login 或 http://localhost:8080/）
如果看到类似这样的序列：
/login 302 /login/login 302 /login/login 302 /login
说明请求在同一个 location 内自我跳转；若出现 http://127.0.0.1:8080/login → https://example.com/login → http://127.0.0.1:8080/login，则是 Nginx 与后端协议/路径不一致导致的跨层循环。
检查 try_files 是否隐式触发内部重定向循环
这是最隐蔽也最常见的原因。当 try_files 的回退项（如 /index.html）本身不真实存在，又没有独立 location 拦截，Nginx 会再次用同一块配置处理该路径，从而循环。
错误写法示例：
location / {<br>
root /var/www/html;<br>
try_files $uri $uri/ /index.html;<br>
}
若 /index.html 不存在，且无 location = /index.html，Nginx 就会重新匹配 location /，再次执行 try_files —— 无限循环。
修复方式：
- 确保 /index.html 文件真实存在；
- 或添加显式拦截：location = /index.html { root /var/www/html; }；
- 或改用 return 302 显式终止流程，避免依赖 try_files 回退逻辑。
验证 rewrite 和 return 是否被重复匹配或覆盖
rewrite 默认行为是 last（内部重定向），若写在非末尾位置且未加 break 或 last，可能触发多轮 location 匹配；而 return 302 虽立即返回，但如果所在 location 被多个规则命中（比如泛匹配 location / 和更具体的 location /api/ 同时生效），也可能因顺序问题误入循环分支。
排查建议：
- 运行 nginx -T | grep -A5 -B5 "your_path" 查看最终生效的完整配置；
- 在疑似 location 中加临时日志：access_log /var/log/nginx/debug.log main if=$request_uri;，确认请求是否真的只进一次；
- 避免在 if 块里写 rewrite，Nginx 官方明确提示其行为不可靠，易引发意外重入。
排除后端返回的 302 干扰（反向代理场景）
如果你用 Nginx 做反向代理，后端应用（如 Spring Boot、Django）返回的 Location 头若含内网地址、错协议（HTTP 而非 HTTPS）或漏路径前缀，Nginx 若未修正，浏览器就会反复跳到错误地址，再被 Nginx 拦下、再转发、再跳……形成外部循环。
关键动作：
- 确保透传 X-Forwarded-Proto $scheme，让后端知道当前是 HTTPS；
- 加 proxy_redirect 主动改写响应头，例如：proxy_redirect ~^http://[^/]+(/.*)$ $scheme://$host$1;；
- 若后端返回相对路径（如 Location: /admin），且你部署在子路径（如 /app/），则加：proxy_redirect / /app/; 补上前缀。
