rewrite规则写错引发死循环的本质是nginx处理完rewrite后重新匹配location，再次命中同一条rewrite指令，导致反复跳转；典型表现为err_too_many_redirects或error.log中出现“internal redirection cycle”错误。
rewrite 规则写错引发死循环，本质是 Nginx 在处理完一次 rewrite 后又重新匹配 location，结果再次命中同一条 rewrite，反复跳转不终止。最典型的表现是浏览器报 ERR_TOO_MANY_REDIRECTS，或 Nginx 日志里出现大量重复的 301/302 记录。
判断是否真在循环
先确认问题根源，别急着改配置：
- 打开浏览器开发者工具 → Network 标签页，刷新页面，看重定向链路（Status 列显示 301/302 的请求是否连续出现 5 次以上）
- 查 Nginx error.log，搜索 rewrite or internal redirection cycle，这是 Nginx 自己检测到循环时打出的明确错误
- 临时在对应 location 块里加 rewrite_log on;（需编译时带 --with-debug），再用 nginx -s reload，然后看 error.log 里的详细 rewrite 路径
常见触发死循环的 rewrite 写法
以下写法看着合理，实际极易陷入无限跳转：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
-
无条件 rewrite + 未排除已重写路径：比如
rewrite ^/(.*)$ /index.php?r=$1 last;，但没加if (!-f $request_filename) { ... }或类似判断，导致静态文件（如 /css/app.css）也被重写进 PHP，而 PHP 路由又可能返回 404 或再次触发 rewrite -
正则过于宽泛且未设终止条件：例如
rewrite ^/api(.*)$ /v2$1 permanent;，若 /v2 本身也匹配 ^/api，则下次请求 /v2/xxx 又会被重写成 /v2/v2/xxx - 使用 break 而非 last 时误判执行流程：break 会停止当前 location 内 rewrite，但不跳出 location；last 会停止当前 rewrite 并重新匹配 location —— 若新匹配又落到同一 location，就可能循环
安全写 rewrite 的关键原则
避免循环的核心是“有边界、可退出、不回流”：
- 优先用 return 替代 rewrite 实现简单跳转（如域名跳转、协议跳转），它不触发重匹配，零风险
- rewrite 后加 last 时，确保重写目标 URI 不再匹配当前 location 的规则（比如 location /old/ 就别 rewrite 成 /old/new/）
- 涉及路径替换的，务必前置判断：用
if (-f $request_filename) { break; }放行真实存在的文件，或用try_files $uri $uri/ /index.php?$args;替代手写 rewrite - 测试阶段在 rewrite 后加一个唯一标识参数（如
rewrite ^/test$ /test?_loop=1 last;），再检查日志是否重复出现该参数，快速定位是否二次进入
快速恢复与验证方法
发现循环后，先止损再排查：
- 立刻注释掉疑似 rewrite 行，nginx -s reload 恢复服务
- 用 curl -I 模拟请求，观察 Location 头是否稳定（只跳一次就停）
- 启用 log_format full '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" "$request_time" "$upstream_http_location"';，配合 access.log 查跳转路径
- 上线前用 nginx -t 验证语法，并用小范围流量灰度测试 rewrite 效果
