nginx rewrite死循环会导致日志数秒内暴增并写满磁盘，典型表现为密集同大小log文件及access.log中同一ip路径指数级重复记录，状态码多为301/302或500；需通过curl -i检测跳转、debug日志定位、nginx -t语法检查及dry-run测试验证，运行中可reload停用配置、truncate清空日志、lsof查幽灵文件快速止损；长期应强制使用break/last/redirect、优先return替代rewrite、关键路径限流、日志独立分区。
配置 Nginx 的 rewrite 规则时，若逻辑存在自引用或无终止条件，极易触发请求重写死循环——每次循环都会生成一条 access 日志，高并发下几秒内就能写满磁盘。这不是日志轮转没配好，而是请求本身在“自我复制”。
死循环 rewrite 的典型表现
最直接的信号是：日志目录中突然出现大量时间戳高度密集、大小几乎一致的 .log 文件（比如每秒新增 10+ 个），同时 access.log 里同一 IP 对同一路径的记录呈指数级重复，且状态码多为 301/302 或直接 500。
常见错误写法示例：
-
rewrite ^/old/(.*)$ /new/$1 permanent;—— 若/new/路径又匹配了同一条规则，就会跳回/old/，形成闭环 -
if ($request_uri ~* ^/api/) { rewrite ^(.*)$ /v1$1 break; }—— 没加锚点或路径约束，/v1/api/可能再次命中该 if 块 - 多个 server 块或 location 块中分别配置 rewrite，未统一判断入口条件，导致跨块重写嵌套
上线前必须做的三道检查
别等报警才排查。每次修改 rewrite 后，执行以下验证：
-
用 curl 模拟单次请求，加 -v 参数观察 Location 响应头是否反复跳转：
curl -I http://your-domain/old/test，若返回多个 301 且 Location 值来回切换，说明已循环 -
临时开启 debug 日志级别，在 nginx.conf 中加入：
error_log /var/log/nginx/rewrite-debug.log debug;，并启用rewrite模块调试：error_log /var/log/nginx/rewrite-debug.log notice;（注意仅限测试环境） - 用 nginx -t 验证语法后，再跑一次 dry-run 测试：启动一个最小化测试实例，用 ab 或 wrk 发 10 个请求，立即检查 access.log 行数是否异常膨胀
运行中快速止损操作
一旦发现日志暴涨，优先保服务，再查原因：
- 立即停用可疑的 rewrite 配置段，执行
nginx -s reload生效（不中断连接） - 若磁盘已满，先清空正在疯狂追写的日志文件内容（非删除）：
truncate -s 0 /var/log/nginx/access.log，避免影响句柄和写入 - 用
lsof -nP +D /var/log/nginx | grep DELETE查看是否有被 rm 但未释放空间的“幽灵日志”，有则重启 nginx 进程释放 inode
长期防护建议
防患于未然比救火更重要：
- 所有 rewrite 规则必须带明确的
break、last或redirect标志，禁用隐式行为 - 在 location 块中使用 rewrite 时，优先用
return替代，语义更清晰、无重写开销 - 对高频路径（如 /、/api）的 rewrite，加
limit_req限流，防止单个恶意请求拖垮整站 - 把 access.log 写入独立小分区（如
/mnt/nginx-logs），避免波及系统根分区
