排查 proxy_pass 代理死循环和重定向冲突，关键在于确认 upstream 是否指向本机 Nginx 自身（如 http://127.0.0.1:80），检查 Location 响应头是否被错误重写或含绝对 URL，验证 proxy_redirect、proxy_set_header Host 及 rewrite 规则是否合理，并通过 debug 日志追踪请求流向。
排查 proxy_pass 引发的代理死循环和重定向冲突，关键在于理清请求流向、检查响应头与 Location 重写逻辑，并验证 Nginx 配置中是否无意将请求又打回自身。
确认 upstream 是否指向了本机或本 server
死循环最常见原因是 proxy_pass 指向了当前 Nginx 实例监听的地址（比如 http://127.0.0.1:80 或 http://localhost），而该端口恰好由同一台 Nginx 处理，形成“自己代理自己”。
- 检查
proxy_pass后的 URL：确保它不落在当前 server 的server_name或监听端口范围内 - 若后端是本地进程（如 Node.js、Python），建议改用非 80/443 端口（如
http://127.0.0.1:3000），并确保该端口未被其他 server 块监听 - 使用
curl -v请求上游地址，确认返回内容是否为预期后端响应，而非又跳转回 Nginx 的欢迎页或 50x 页面
检查后端返回的 Location 响应头是否被错误重写
当后端返回 301/302 并带 Location: /path 或 Location: https://example.com/path，Nginx 默认不修改该头；若前端访问路径与后端期望路径不一致，就可能触发外部重定向或跳转到错误域名。
- 用
curl -v http://your-domain/api/login查看完整响应头，重点观察Location字段值是否含绝对 URL（如https://backend.local/redirect）——这会导致浏览器跳转出代理链 - 若后端返回相对路径（如
Location: /dashboard），需确保 Nginx 的proxy_redirect正确重写。例如：
proxy_redirect / /app/; 表示把后端返回的/dashboard改成/app/dashboard - 禁用自动重写可加
proxy_redirect off;，再自行用add_header Location ...或 rewrite 控制，但需谨慎避免覆盖原始语义
验证 rewrite 和 proxy_set_header 是否干扰原始 Host 与路径
不当的 rewrite 规则或缺失/错误的 proxy_set_header 可能导致后端误判请求来源，从而生成错误重定向。
- 务必设置
proxy_set_header Host $host;（或更安全的$http_host），否则后端收到空 Host 或默认值，可能拒绝服务或返回 301 跳转到 canonical 域名 - 避免在
location块里无条件rewrite ^/(.*)$ /$1 break;类规则——看似无害，实则可能破坏原始 URI 结构，影响后端路由匹配 - 若用了
rewrite ... redirect或permanent，要确认它不在proxy_pass所在 location 内意外触发
开启日志快速定位循环起点
Nginx 默认 access log 不体现内部跳转细节，需借助 error log 和自定义日志格式抓取真实流向。
- 在对应 server 或 location 块中临时启用：
error_log /var/log/nginx/debug.log debug;（注意磁盘空间，排查完及时调回 info/warn） - 添加日志变量记录关键信息：
log_format debug '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" "$upstream_addr" "$upstream_http_location"'; - 查看日志中是否出现反复相同 IP → 同一 upstream 地址 → 又返回 302 → 再次命中本 location 的链式记录，即为死循环证据
