调试Nginx rewrite需分三步：先验证是否生效，再确认改写结果，最后检查是否被拦截或循环；依赖rewrite_log与error_log日志逐条分析匹配、替换及flag执行，严格区分last（重新匹配location）与break（当前location内继续），注意Windows下正则转义、&实体写法及大小写敏感问题。
调试和修复 Nginx 请求路径 rewrite，核心在于“先验证是否生效、再确认改成了什么、最后看是否被拦截或循环”。不靠猜，靠日志和分步验证。
用 rewrite_log + error_log 定位匹配与替换过程
Nginx 不提供交互式调试器，但 rewrite_log 是最直接的“回放录像”。它会逐条记录每条 rewrite 是否命中、原始 URI、替换结果和 flag 执行动作。
- 在 server 或 http 块中加入：rewrite_log on; 和 error_log logs/rewrite.log notice;
- 重启 Nginx（
nginx -s reload），然后发起一次测试请求（如curl -I http://localhost/article/123.html） - 查看
logs/rewrite.log：若看到类似rewrite ^/article/(\d+)\.html$ /index.php?m=article&id=$1 last using regex，说明规则已加载且匹配成功；若无输出，说明未命中（正则写错、路径不对、location 未覆盖） - 注意：rewrite_log 默认只在
notice及以上级别输出，debug级别会更详细，但需编译时启用--with-debug
区分 last 和 break —— 避免 location 重匹配陷阱
rewrite 后的行为差异，常导致 404 或无限循环，关键就在 flag 选错。
-
last：重写后丢弃当前 location，用新 URI 重新匹配所有 location 块。适合内部路径标准化（如把
/api/v1/xxx→/v1/xxx后交由location /v1/处理） - break：重写后仍在当前 location 内继续执行后续指令（如 proxy_pass 或 try_files）。适合 rewrite + proxy_pass 组合，避免二次匹配引发循环
- 典型错误：在
location /中写rewrite ^/old/(.*)$ /new/$1 last;，而location /new/不存在 → 新 URI 匹配不到任何 location → 返回 404 - 安全做法：内部重写优先用
break；需跨 location 路由时才用last，并确保目标 location 存在且能处理新路径
检查正则与特殊字符转义（Windows 下尤其关键）
Windows 环境下，配置文件解析和路径处理更敏感，两点必须核对：
- 点号
.、问号?、加号+、括号()等在正则中是元字符，必须加反斜杠转义。例如匹配.html要写成\.html，否则.html会匹配任意字符 + “html” - URI 中的
&必须写成&（不是&），因为 nginx.conf 按类 XML 方式解析，&会被当作实体开始符，导致配置校验失败（nginx -t报错） - 路径开头的
/不能省略：Nginx 匹配的是完整请求路径（如/article/123.html），正则必须以^/开头，否则无法命中 - 大小写问题：Windows 文件系统不区分大小写，但 Nginx 正则默认区分。如需忽略大小写，正则前加
(?i)，例如rewrite ^(?i)/ARTICLE/(\d+)\.html$ /index.php?m=article&id=$1 break;
快速验证 rewrite 是否生效的三步法
不用等上线、不依赖浏览器跳转，三步即可闭环验证：
-
第一步：用 return 拦截输出。在目标 location 内临时加一行：
return 200 "URI: $request_uri, ARGS: $args";。访问路径，看返回内容是否已是 rewrite 后的结果 -
第二步：用 curl 查状态码和 Location 头。如果用了
redirect或permanent，运行curl -I http://host/old，观察响应头中是否有Location:且值正确 -
第三步：检查后端是否收到改写后的路径。若搭配
proxy_pass，在 upstream 服务日志或抓包中确认接收到的 path 是否为 rewrite replacement 的结果，而非原始路径
