Nginx因多层location嵌套与rewrite配置不当引发重写死循环，表现为反复匹配、重写、再匹配，触发“rewrite or internal redirection cycle”错误；需通过error日志定位、debug日志追踪执行路径，并用break/last控制流程或改用proxy_pass等替代方案修复。
遇到因多层 location 嵌套引发的重写死循环，本质是 Nginx 在匹配和执行 rewrite 时反复跳转、无法终止。关键不是“嵌套本身违法”，而是嵌套结构 + rewrite 配置不当，导致请求被反复捕获、重写、再匹配，最终触发 rewrite or internal redirection cycle 错误（HTTP 500 或日志报错）。
看错误日志定位循环源头
Nginx 日志（尤其是 error log）会明确记录循环细节。开启详细日志：
error_log /var/log/nginx/error.log notice;
复现请求后，搜索关键词：
-
rewrite or internal redirection cycle—— 直接确认死循环发生 - 连续出现相同 URI 多次匹配同一 location 块 —— 比如
"GET /api/v1/xxx" repeated 10 times - 日志中 rewrite 动作（
using regex、rewritten data）高频重复
检查 location 块嵌套是否隐式触发多次匹配
Nginx 不支持真正的“嵌套 location”，所谓“嵌套”只是书写缩进或逻辑分组，实际所有 location 是平级匹配的。但以下结构极易误导并引发循环：
- 外层
location /api/ { ... }内部又写了一个location ~ \.php$ { ... }—— 若 rewrite 目标仍落在/api/路径下，且未加last或break控制流程，就可能再次进入外层 location - 用了
rewrite ... ;（无 flag）或rewrite ... redirect;→ 外部重定向虽跳出 Nginx，但若前端代理或浏览器缓存旧地址，可能反复发起相同请求 - 用了
rewrite ... last;但新 URI 又被另一个更宽泛的 location（比如location / { ... }）捕获，而该块里又有 rewrite → 形成跨块循环
用 rewrite_log 和 debug 日志追踪执行路径
临时启用重写调试（需编译时含 --with-debug）：
rewrite_log on; error_log /var/log/nginx/error.log debug;
重启后发起一次请求，查看日志中每一步 rewrite 如何触发、URI 如何变化、最终匹配到哪个 location。重点关注：
- rewrite 执行后是否立即跳出当前 location（
break），还是继续向下执行其他指令（可能再触发 rewrite） - rewrite 后的 URI 是否落入了另一个有 rewrite 的 location 块
- 是否存在
if块内使用 rewrite —— 这类写法本就易出问题，且 if + rewrite 组合在 location 内会放大循环风险
修复建议：精简结构 + 显式控制流程
- 避免“伪嵌套”写法：把不同规则拆到独立、互斥的 location 块，用精确匹配（
=）、前缀匹配（^~）或正则匹配（~）明确边界 - rewrite 后加
break（停止当前 location 内后续处理）或last（重新匹配 location，慎用）—— 大多数内部重写用break更安全 - 用
return或proxy_pass替代冗余 rewrite：例如location /api/ { proxy_pass http://backend; }比rewrite ^/api/(.*)$ /$1 break; proxy_pass ...更清晰、无循环风险 - 测试时用
curl -v观察响应头Location和状态码，确认是否发生意外重定向
