ERR_TOO_MANY_REDIRECTS本质是浏览器陷入重定向闭环，主因包括HTTP/HTTPS协议冲突、www与裸域名跳转逻辑叠加、后端误判协议未透传X-Forwarded-Proto头、CDN与源站跳转策略重复，以及缓存干扰。
重定向过多（如“ERR_TOO_MANY_REDIRECTS”）本质是浏览器在跳转链中陷入循环，而Nginx只是其中一环。问题不在于301或302本身，而在于跳转逻辑是否形成闭环——比如HTTP→HTTPS→HTTP，或www→non-www→www。排查需从请求路径、配置冲突和缓存三方面切入。
看日志确认跳转链是否闭环
启用带关键变量的日志格式，重点观察连续请求的走向：
- $status：客户端最终收到的状态码。若连续多条都是301/302，说明Nginx一直在发跳转响应
- $upstream_status：后端返回的状态码。如果出现302 302 302连发，且$upstream_status始终是302，说明后端也在持续跳转
-
$upstream_http_location：原始Location值。用grep -E "(http://|https://)"提取，看是否在两个地址间来回切换，例如
https://example.com⇄http://www.example.com
检查常见循环配置组合
多数循环源于协议、子域、路径三者未对齐。典型错误包括：
- server块同时存在
return 301 https://$host$request_uri和return 301 https://www.$host$request_uri，但没加if ($host != 'www.example.com')判断 - HTTPS server里用
proxy_pass http://backend，而后端又返回302跳回HTTP地址，造成HTTP↔HTTPS来回跳 - rewrite规则中用了
permanent却没排除已匹配目标路径，导致^/old/(.*)$ → /new/$1 permanent对/new/xxx也生效
验证真实请求路径与缓存干扰
浏览器或CDN可能缓存了某次301响应，导致后续请求根本没到Nginx就自动跳转：
- 用
curl -I -v http://example.com绕过浏览器缓存，观察实际响应头中的Location和状态码 - 对比
curl -H "Host: example.com"和curl -H "Host: www.example.com"结果，确认不同域名是否触发不同server块 - 临时关闭CDN或在请求头中加
Cache-Control: no-cache，排除边缘节点缓存干扰
定位具体触发位置
不是所有重定向都来自顶层server配置。要逐层检查：
- 全局server块的
return或rewrite - location块内嵌套的
return（尤其/、/login等高频路径） - 反向代理场景下，后端应用（如Django、Spring Boot）自身返回的302，Nginx未用
proxy_redirect修正Location头，导致跳转到内网地址，再被另一层规则捕获
