Nginx中rewrite_log仅在≤1.18.x版本有效，需同时配置rewrite_log on和error_log ... notice；≥1.19.0版本已移除，须改用error_log ... debug并确认编译含--with-debug。
在 Nginx 的 http 块中启用 rewrite_log 并不能直接“调试全局重写规则”——因为 Nginx 本身没有“全局重写规则”的概念，所有 rewrite 指令都必须写在 server、location 或 if 块内。所谓“全局”，实际是指将重写逻辑统一放在 http 块下的多个 server 或共用 location 中，便于集中维护。而 rewrite_log 的作用，是让这些分散位置的重写行为在日志中可追溯、可比对。
先确认是否真能用 rewrite_log
该指令仅在 Nginx ≤1.18.x 版本中有效，且需满足两个硬性前提：
- 执行
nginx -v：输出为nginx/1.18.0或更低才支持 - 执行
nginx -V 2>&1 | grep -o with-debug：必须有输出，否则 debug 日志模块未编译，rewrite_log彻底无效
若版本 ≥1.19.0（如当前主流的 1.20+），rewrite_log 已被移除，必须改用 error_log ... debug 配合过滤。
旧版（≤1.18.x）：在 http 块中正确开启 rewrite 日志
仅写 rewrite_log on; 不会输出任何内容。必须同步配置：
- 在
http块顶部或任意靠前位置添加：rewrite_log on; - 在同一
http块中添加：error_log /var/log/nginx/rewrite.log notice; - 注意：日志级别必须是 notice；设成
info、debug或warn均不生效 - 确保该
error_log作用域覆盖所有含rewrite的server和location（放在http块即满足）
重启后，触发请求，日志会出现类似行：
2026/05/12 05:15:22 [notice] 1234#1234: "^/api/v(\d+)/(.+)$" matches "/api/v1/users", client: 127.0.0.1新版（≥1.19.0）：用 debug 日志替代，信息更全
等效能力由 error_log ... debug 提供，但要求更严：
- 确认已编译
--with-debug（同上验证） - 在
http块中配置：error_log /var/log/nginx/debug.log debug; - 重启后，每条重写动作都会记录，例如：
"using regex "^/old/(.*)$" rewritten data: "/new/$1""
"test location: "/new/" matched location: /new/" - 实时聚焦关键信息：
tail -f /var/log/nginx/debug.log | grep -i "rewrite\|regex\|location"
配合 log_format 和 curl 定位真实执行路径
单看 rewrite 日志容易误判哪条规则最终生效，建议联动验证：
- 用
curl -v http://localhost/path查状态码、响应头、重定向跳转链 - 对照日志中同一时间戳 + 相同连接符（如
*12345）的多行记录，还原完整匹配与重写流 - 在
http块定义自定义格式：log_format debug_log '$remote_addr "$request" $status "$request_uri" "$uri" "$args"';
再启用：access_log /var/log/nginx/access_debug.log debug_log;
可清晰对比原始请求路径与重写后$uri值，避开 debug 日志的密集滚动干扰
