Nginx rewrite循环故障主因是缺少break/last标志或if内误用，触发10次重定向上限报500或“重定向过多”；排查需查error.log中“rewrite or internal redirection cycle”日志，结合curl验证。
当 Nginx 的 rewrite 规则配置不当，最典型的故障就是返回 500 Internal Server Error 或浏览器提示“重定向次数过多”，本质是触发了 Nginx 内置的循环保护机制（默认最多 10 次内部重定向），最终终止并报错。排查核心在于：**确认重写是否反复匹配、是否缺少终止条件、是否在错误上下文中执行**。
查看错误日志定位循环起点
Nginx 默认会在 error.log 中记录循环超限信息，关键线索如下：
- 搜索
"rewrite or internal redirection cycle"—— 这是明确的循环警告，后面会附带具体 URI 和匹配的 location 块名 - 观察连续多行相似的
"*XX rewrite phase: ..."日志，说明同一请求被反复 rewrite - 注意时间戳和请求 ID（如
client: xxx, server: xxx, request: "GET /xxx HTTP/1.1"），可结合 access.log 对齐请求路径
检查 rewrite 规则是否缺少 break 或 last 标志
rewrite 指令末尾的标志决定后续流程，**缺少正确标志是循环主因**：
-
last：停止当前 location 匹配，用新 URI 重新匹配 location —— 若新 URI 又命中同一 rewrite 规则，就会循环 -
break：停止 rewrite 处理，直接使用当前 location 的剩余配置（如 proxy_pass）—— 更安全，适合内部路径改写 -
redirect/permanent：发起 302/301 外部跳转，不会导致内部循环（但要注意浏览器缓存） - 无标志（或仅
if内 rewrite）：默认行为等同于last，极易引发循环，尤其在 root location 或正则 location 中
✅ 正确示例（避免循环）：
location /old/ {<br> rewrite ^/old/(.*)$ /new/$1 break;<br>}
验证 rewrite 是否在 if 块中被重复触发
if 在 location 中是“危险区域”：Nginx 官方明确不推荐在 location 内使用 if + rewrite 组合，因为每次重写后 if 条件可能再次满足。
- 例如：
if ($request_uri ~ ^/v1/(.*)) { rewrite ^/v1/(.*)$ /api/$1; }—— 新 URI/api/xxx不再匹配/v1/，看似安全；但如果 location 是location / { ... }，且没有更精确的匹配，rewrite 后仍落在该 location，if 可能因变量未清空而再次执行 - ✅ 替代方案：用更精准的
location块替代 if，或改用map指令预处理变量
用 curl 模拟请求 + 查看响应头与重定向链
绕过浏览器缓存，直接观察 Nginx 行为：
-
curl -I http://your-domain/path：看是否返回 301/302（外部跳转）或直接 500 curl -v http://your-domain/path 2>&1 | grep -E "(^：跟踪完整重定向过程（对 redirect 类规则有效）- 若怀疑内部循环（无 3xx 响应），需结合 error.log 判断，因为内部 rewrite 不产生 HTTP 跳转头
不复杂但容易忽略：rewrite 循环往往不是规则本身写错，而是规则所处的 location 上下文、标志选择、以及与其他指令（如 alias、root、proxy_pass）的配合出了问题。先看日志，再盯标志，最后换 location 代替 if —— 基本覆盖 90% 的场景。
