排查Nginx rewrite死循环需启用debug日志并精准定位：先验证nginx -V含with-debug，再在server/location块中配置error_log debug，用tail+grep监控internal redirection cycle、rewritten data与matched location等关键线索，结合curl -Iv验证跳转链。
排查 Nginx 中因 rewrite 规则冲突引发的重定向死循环，核心是让错误日志“说出真相”——它不靠猜测，而是记录每一步匹配、重写和跳转的真实执行路径。关键不是打开日志，而是让日志输出有效信息，并能快速从中识别循环线索。
确认 debug 日志功能可用
Nginx 默认安装包大多不含 debug 支持，必须先验证：
- 运行
nginx -V 2>&1 | grep -o with-debug，有输出才表示编译时启用了--with-debug - 若无输出，需重新编译 Nginx 并显式添加该参数；生产环境严禁启用 debug 日志
- debug 日志量极大，仅限临时在测试环境使用
精准配置 error_log 并过滤关键行
不要笼统写在 http 块，应在具体 location 或 server 块中单独配置，避免日志淹没：
- 在目标块内加：
error_log /var/log/nginx/rewrite-loop.log debug; - 确保 Nginx 工作用户（如 www-data）对日志路径有写权限
- 实时监控并过滤核心关键词：
tail -f /var/log/nginx/rewrite-loop.log | grep -E "(regex|rewritten|location|internal redirection|break|last)"
从日志里识别死循环信号
真正有效的线索藏在日志细节中，重点关注这几类输出：
-
internal redirection cycle while processing "/xxx"：明确提示已陷入无限内部重定向 - 连续出现多条
using regex "..." rewritten data: "/new/path"→test location: "/new/"→ 又回到同一条 rewrite 规则：说明 last 导致反复匹配同一 location -
rewrite "/path" last后紧跟着matched location: /path：典型闭环，新 URI 又触发了自身 - 反复出现
rewrite phase: 3多次：表示 rewrite 阶段被反复进入，而非一次完成
结合 curl 验证日志结论
日志只告诉你“发生了什么”，curl 告诉你“客户端看到什么”，二者交叉才能闭环验证：
- 用
curl -Iv https://example.com/path查看实际跳转链和响应头中的Location - 对比日志中 rewrite 的目标路径与 curl 返回的 Location 是否一致
- 若日志显示已重写为
/api/v2/user，但 curl 却收到Location: /login，说明后端又生成了一次跳转，问题不在 Nginx rewrite，而在后端根路径配置
不复杂但容易忽略：死循环往往不是规则写得多，而是 break 和 last 用反了，或 if 块里嵌套 rewrite 导致逻辑失控。盯住日志里的 “last”、“break”、“internal redirection” 这几个词，基本就锁定了病灶位置。
