rewrite_log指令用于开启nginx重写过程的详细日志（仅1.18.x及以下版本支持），需配合error_log notice级别使用；1.19.0+须用--with-debug编译后配置error_log debug，并结合access_log与curl验证实际转发路径。

rewrite_log 指令本身不直接修复问题，而是让转发逻辑“可看见”——它把 Nginx 内部重写匹配、变量替换、location 重匹配等隐式行为逐行打印出来，是定位转发异常的第一手证据。但它的作用高度依赖版本、编译支持和配置协同，不能单独启用就生效。

先确认是否能用 rewrite_log

不是所有环境都支持 rewrite_log：

• 版本 ≤ 1.18.x 才有效；1.19.0 及以上已彻底移除，必须改用 error_log debug
• 执行 nginx -V 2>&1 | grep with-debug，无输出说明未编译 debug 模块，rewrite_log（旧版）或 debug 日志（新版）都会静默失效
• Ubuntu/Debian 的 apt 包、CentOS 的 yum 包默认不含 --with-debug，需自行源码编译

旧版本（≤1.18.x）：正确开启 rewrite 日志

仅写 rewrite_log on; 不会输出任何内容。必须三者对齐：

• 在 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: "^/api/v1/(.*)$" matches "/api/v1/users", client: 127.0.0.1
这说明正则成功捕获了路径，后续还会显示重写结果、是否 break/last、新 URI 是否触发 location 重匹配等关键信息。

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

rewrite_log 已废弃，但 debug 日志提供的信息更全、更结构化：

• 确保已编译 --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"

结合 access_log 和 curl 定位真实执行路径

单看 rewrite 日志容易误判哪条规则真正生效，尤其当存在多层 if、嵌套 location 或 last/break 干扰时：

• 用 curl -v http://host/path 查看响应状态码、Location 头、是否跳转，确认行为是否符合预期
• 在 http 块定义精细日志格式：
  log_format debug_log '$remote_addr "$request" $status "$request_uri" "$uri" "$args"';
  再配 access_log /var/log/nginx/access_debug.log debug_log;
  可清晰比对原始请求 URI、重写后 $uri、参数是否丢失等
• 对照 debug.log 中同一时间戳 + 相同连接符（如 *12345）的多行记录，还原完整执行流