解决Nginx负载均衡请求死循环需分三类处理：一、协议误判型，加proxy_set_header X-Forwarded-Proto $scheme并配置后端信任头；二、多层代理路径劫持，显式设Host头、统一proxy_pass尾斜杠、禁用干扰正则location；三、后端自跳转闭环，用try_files $uri $uri/ /index.html、透传X-Original-URI、接入健康检查。
解决 Nginx 负载均衡下的请求处理死循环，关键在于识别循环类型并针对性切断——常见有三类：协议误判型重定向循环、多层代理路径劫持循环、以及后端自跳转闭环。不靠猜测，要从请求链路逐段验证。
一、协议误判导致的 HTTPS↔HTTP 重定向循环
典型表现：浏览器地址栏在 http:// 和 https:// 间反复跳转，最终报 ERR_TOO_MANY_REDIRECTS。
根本原因：Nginx 终止 HTTPS 后以 HTTP 转发给后端，但未透传原始协议，后端（如 Django、Spring Boot）误判为 HTTP 请求，强制 301 跳转到 HTTP；而 Nginx 又配置了 HTTP→HTTPS 强制跳转，形成闭环。
- 在 server 或 location 块中添加：proxy_set_header X-Forwarded-Proto $scheme;
- 确保后端启用信任机制，例如 Django 需设 SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https')
- 检查是否有多余跳转：HTTPS server 块内 不能再写 return 301 https://...，只应在 HTTP server 块中做跳转
二、多层代理中 Host 头或路径错配引发的转发循环
典型表现：请求进入某域名 → Nginx A 转发至域名 B → 域名 B 的 Nginx 再次解析为域名 A → 循环打转，CPU 暴涨。
常见于宝塔+Docker、网关+Nginx 分层部署场景，尤其当 proxy_pass 使用域名且 Host 头未显式覆盖时。
- 在 proxy_pass 前强制设置 Host 头：proxy_set_header Host "目标后端实际域名";（不要用 $host）
- 确认 proxy_pass URL 结尾斜杠一致性：若 location /api/，proxy_pass 应写为 http://backend/api/（带尾部 /），避免路径拼接错误
- 禁用可能劫持请求的正则 location，例如 location ~ \.(js|css)$ 会优先匹配静态资源，绕过 proxy_pass，造成 404 后又被 error_page 重定向回 /，间接促成循环
三、后端服务自身触发的跳转闭环
典型表现：curl 后端 IP 直连正常，但经 Nginx 访问就反复重定向；日志中可见连续多个 302 Location 响应，目标 URL 在同一域名下微调路径。
原因多为前端 SPA 的 history 模式未正确适配，或后端鉴权逻辑在非预期路径下重复触发登录跳转。
- 对前端应用（Vue/React/Angular），确保 Nginx 使用安全的 try_files：try_files $uri $uri/ /index.html;，且该 location 不与其他 rewrite 或 error_page 404 冲突
- 后端若依赖 Referer 或原始路径做跳转判断，需同步透传：proxy_set_header X-Original-URI $request_uri;
- 检查后端是否暴露健康接口（如 /health），并在 Nginx 主动健康检查中接入，及时剔除“假死”却仍在返回 302 的异常节点
死循环不是配置堆叠的结果，而是某个环节的信任缺失或路径失控。每次修改后，用 curl -I 模拟请求，逐跳观察 Location 响应头和状态码，比看浏览器更准。
