error_log的debug级别是定位rewrite规则冲突最直接可靠的手段，需先验证nginx是否含--with-debug编译支持，再在location块中精准配置error_log路径 debug，结合grep过滤“rewrite|regex|location”等关键词分析匹配、跳转及循环问题。
error_log 的 debug 级别是定位 Rewrite 规则冲突最直接、最可靠的手段。它不依赖猜测或外围工具，而是从 Nginx 内部执行流程出发，真实还原每条 rewrite 指令是否匹配、是否执行、是否跳转、是否终止，尤其能暴露 location 嵌套、if 判断、break/last 语义混淆等隐藏冲突。
确认 debug 支持是前提
多数系统默认安装的 Nginx（如 Ubuntu apt 包、CentOS yum 包）不含 debug 日志功能。必须先验证：
- 运行
nginx -V 2>&1 | grep -o with-debug，有输出才表示编译时启用了 --with-debug； - 若无输出，需重新编译 Nginx 并显式添加该参数；
- debug 日志量极大，仅限测试环境短期启用，生产环境严禁开启。
精准配置 error_log 才能捕获重写行为
不是写上 debug 就自动生效，关键在作用域和权限：
- 在具体 location 块内写：
error_log /var/log/nginx/rewrite_debug.log debug;，比放在 http 块更聚焦，避免日志淹没； - 日志路径需确保 Nginx 工作进程用户（如 www-data 或 nginx）有写权限；
- 必须写
debug，不能写debug_http或其他变体（Nginx 1.19+ 已统一为 debug）； - 同一配置块中不要重复定义多个 error_log，否则可能冲突失效。
从日志里识别典型 Rewrite 冲突线索
触发请求后，重点过滤含以下关键词的行：
-
test location: "/xxx"→ 查看 Nginx 实际进入哪个 location，确认是否误入非预期块； -
using configuration "/xxx/"→ 明确当前生效的 location 配置段； -
rewrite phase: 3→ 表示进入 rewrite 执行阶段，后续才是规则真正起效点； -
matched或not matched→ 直接告诉你某条正则是否命中； -
rewrite "/new/path" breakvsrewrite "/new/path" last→ 区分内部重定向是否跳出当前 location； -
internal redirection cycle→ 出现无限重定向，常见于 last 后又匹配回原 location，是典型的规则循环冲突。
结合其他手段交叉验证
单看日志容易断章取义，建议同步操作：
- 用
curl -v http://host/path查状态码与响应头（尤其是 Location），比对是否与日志中 rewrite 动作一致； - 在可疑 location 中临时加
return 200 "in X";，确认请求是否真进入该块； - 把复杂正则拆解：先测
^/api/，再加v\d+，最后加捕获组，逐层缩小问题范围； - 特别注意 if 指令——它在 location 内独立判断，不继承前面 rewrite 修改后的 $uri，日志中会显示
if condition true，需对照观察其执行时机。
