调试 Nginx Rewrite 规则需让重写过程“可见”，核心方法是开启 rewrite_log 并设 error_log 为 debug 级别，结合 return 或 echo 验证命中、厘清作用域与执行顺序，再用 curl 分步验证响应状态码、Location 头及内部 URI 重写结果。
调试 Nginx Rewrite 规则，核心是让重写过程“可见”——不是靠猜，而是看实际发生了什么。最有效的方式是结合日志记录与简单验证手段，快速定位规则是否匹配、是否执行、是否跳转正确。
开启 rewrite_log 查看匹配详情
Nginx 提供 rewrite_log on 指令（需配合 error_log 的 debug 级别），能把每次 rewrite 匹配和执行过程输出到错误日志中。注意：该指令仅在调试时启用，生产环境务必关闭。
- 在
nginx.conf的http或server块中添加：rewrite_log on; - 确保 error_log 级别为 debug：
error_log /var/log/nginx/error.log debug; - 重载配置：
nginx -s reload，然后发起一次请求 - 查看日志：
tail -f /var/log/nginx/error.log | grep rewrite，会看到类似：using configuration "/test" → "/new"或no match for "/old"
用 return 或 echo 验证规则是否命中
当不确定某条 rewrite 是否被触发，可在 location 中临时插入 return 或利用第三方模块（如 echo-nginx-module）直接返回当前 URI 或变量值，避免跳转干扰判断。
- 例如，在目标 location 内加：
return 200 "URI: $request_uri, args: $args"; - 或用 rewrite + break 搭配 return：
rewrite ^/old/(.*)$ /debug?path=$1 break;
再在 /debug location 中 return 输出 $args，就能确认捕获是否正确 - 注意：
break终止后续 rewrite，last会重新匹配 location，行为差异直接影响调试结果
检查 rewrite 执行顺序与作用域
rewrite 规则按书写顺序从上到下匹配，且只在当前作用域生效。location 中的 rewrite 不影响 server 块中的规则，反之亦然。常见误判源于作用域混淆。
- server 块中的 rewrite 在 location 匹配前执行；location 内的 rewrite 在匹配后执行
- 使用
if块内的 rewrite 要格外小心——if 是非标准上下文，嵌套逻辑易出错，优先用 map 或 try_files 替代 - 测试时建议先注释掉其他 rewrite，只留待测规则，排除干扰
用 curl 模拟请求并观察响应头与 body
rewrite 最终效果体现在 HTTP 响应上：状态码（301/302）、Location 头、或内部重写的 URI 是否被正确处理。curl 是最轻量的验证工具。
- 查看重定向：
curl -I http://example.com/old，检查是否有Location:和状态码 - 查看内部重写结果：
curl -v http://example.com/test，对比> GET行与实际访问的后端路径 - 加
-L跟随跳转，但注意这会隐藏中间步骤；调试阶段建议不用 -L，分步观察更清晰
