排查Nginx rewrite中last与break混用导致的死循环，关键在于理解last会重启location匹配而break仅终止当前块内后续rewrite，混用时若last重写后仍命中含last规则即触发循环；需开启rewrite_log分析重复匹配日志，检查条件终结性，避免重写后URI仍落入同location，并辅以curl和详细access_log验证。
排查 Nginx rewrite 中 last 与 break 混用引发的死循环，核心是理解两者对请求处理流程的影响差异，并结合日志与配置逻辑逐层验证。
明确 last 和 break 的行为差异
last 会终止当前 location 块内的后续指令，重新匹配 URI（即发起一次内部重定向），从 server 块开始新一轮 location 查找；break 则只停止当前 rewrite 指令之后的 rewrite 执行，不重启匹配，后续仍按当前 location 继续处理（如 proxy_pass、root 等）。
混用时若 last 触发的新匹配又命中了同一条或另一条含 last 的 rewrite，且条件始终满足，就可能形成无限重写循环。
启用并分析 rewrite 日志定位循环点
在 nginx.conf 的 http 或 server 块中开启调试级 rewrite 日志：
rewrite_log on; error_log /var/log/nginx/rewrite.log notice;
注意：rewrite_log 需要 nginx 编译时启用 --with-debug，且日志级别设为 notice 或更低才可见 rewrite 过程。查看日志中重复出现的 rewrite 行，例如：
2024/05/10 14:22:03 [notice] 12345#0: *1 "^(.*)$" matches "/api/v1/users", client: 127.0.0.1 2024/05/10 14:22:03 [notice] 12345#0: *1 rewritten data: "/v1/users", client: 127.0.0.1 2024/05/10 14:22:03 [notice] 12345#0: *1 "^(.*)$" matches "/v1/users", client: 127.0.0.1 2024/05/10 14:22:03 [notice] 12345#0: *1 rewritten data: "/v1/users", client: 127.0.0.1
连续两行匹配相同 pattern 且重写结果未改变，基本可判定进入死循环。
检查 rewrite 条件是否具备“终结性”
常见错误是 rewrite 规则缺少前置条件限制，导致每次重写后仍满足匹配。应确保：
- 使用
if ($request_uri ~ ^/old/)而非if ($uri ~ ^/old/)，避免重写后 $uri 变化但 $request_uri 未变造成误判 - 对
last规则，目标 URI 应落在一个不再触发 rewrite 的 location 中（例如静态文件 location 或带 proxy_pass 的专用块） - 避免在同一个 location 内对同一路径反复使用
last，尤其当 rewrite 后 URI 仍落入该 location 时 - 用
return 404或return 301替代部分last，更可控且无重匹配风险
用 curl + -v 和 access_log 辅助验证
在测试环境用带头信息的请求观察真实跳转链路：
curl -v http://localhost/api/v1/users
同时在对应 server 块中临时添加详细 access_log：
log_format full '$remote_addr - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent" '
'rt=$request_time uct="$upstream_connect_time" uht="$upstream_header_time" urt="$upstream_response_time"';
access_log /var/log/nginx/access-full.log full;观察响应状态是否为 500（Nginx 内部重写超限默认报错）、或响应时间异常增长、或 upstream 时间字段持续为空——这些都暗示 rewrite 循环已触发，Nginx 在内部重试中耗尽资源。
