rewrite_log 要生效需四点对齐：版本适配（≤1.18.x可用，≥1.19.0废弃）、编译含--with-debug、日志级别设为notice（旧版）或debug（新版）、作用域覆盖实际rewrite的location。

要让 rewrite_log 真正帮上忙，不能只写一句 rewrite_log on 就完事——它只是“开关”，日志能不能出来、内容是否清晰，取决于版本适配、编译支持、日志级别和作用域这四点是否全部对齐。

先确认你的 Nginx 版本和 debug 支持

执行这两条命令：

• nginx -v —— 若显示 nginx version: nginx/1.18.0 或更早，rewrite_log 可用；若 ≥ 1.19.0，该指令已废弃，必须改用 error_log ... debug
• nginx -V 2>&1 | grep -o with-debug —— 无输出说明未编译 debug 模块，rewrite_log（旧版）或 debug 日志（新版）都无效，需重编译并加 --with-debug

旧版本（≤1.18.x）：开启 notice 级 rewrite 日志

在 http 或对应 server 块中添加：

• rewrite_log on;
• error_log /var/log/nginx/rewrite.log notice; —— 注意：必须是 notice 级别，info 或 debug 会静默失效
• 确保该 error_log 指令的作用域覆盖到实际执行 rewrite 的 location（建议直接放在 http 块）

重启后触发请求，日志中会出现类似：
2026/05/01 08:45:22 [notice] 1234#1234: "^(.*)$" matches "/api/v1/users", client: 127.0.0.1

新版本（≥1.19.0）：用 debug 日志替代 rewrite_log

启用方式更严格但信息更全：

• 确认已编译 --with-debug
• 配置：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"

配合 curl 和 log_format 定位真实执行路径

单看日志容易误判哪条规则真正生效，建议三步联动：

• 用 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; 记录原始请求与重写后变量值，比对差异