last会用重写后URI重新匹配location，break则留在当前location继续执行后续指令；前者适用于交由其他location处理，后者适用于本location内完成服务。
在 Location 块中配置 rewrite 时，last 和 break 的核心差异在于：是否用重写后的新 URI 重新触发 location 匹配流程。这个选择直接影响请求后续走向，稍不注意就会导致 404、500 或后端路径错乱。
last：重写后重启 location 匹配
遇到 last，Nginx 会丢弃当前 location 的匹配结果，拿着改写后的 URI，从 server 块开头重新执行 location 查找——就像内部发起了一次新请求，但浏览器地址栏不变。
- 适合需要交由其他 location 处理的场景，比如 /api/v1/ → /api/v2/，再由专门的 /api/v2/ 块接管
- 配合 alias 使用必须用 last，因为 alias 的路径替换依赖完整的 location 匹配上下文
- 若重写后 URI 又命中含 rewrite 的 location，可能再次触发 last，最多循环 10 次，超限返回 500
- 常见于根路径标准化、前后端分离路由兜底（如前端 history 模式）、多版本 API 路由切换
break：重写后留在原 location 继续执行
遇到 break，Nginx 停止当前 location 内所有后续 rewrite 指令，直接用新 URI 在当前 location 内继续走完剩余流程（如 proxy_pass、root、try_files）。
- 适合路径映射后仍由本 location 完成服务的场景，比如 /static/ → /assets/，且当前 location 已配好 root 或 alias
- proxy_pass 场景下多数用 break，这样重写后的路径会作为相对路径透传给后端（如 rewrite /api/(.*) /v2/$1 break + proxy_pass http://upstream → 实际转发到 http://upstream/v2/user）
- 误用 break 配 alias 容易 404，因为 alias 不会因 URI 改变而自动调整映射逻辑
- 常用于静态资源路径整理、内部代理路径微调、避免 location 重复定义
怎么选？看 URI 后续由谁处理
关键判断点只有一个：重写后的 URI，你希望它被哪个 location 块处理？
- 希望交给另一个 location（比如 /old/ → /new/，且已有独立的 location /new/ {}），就用 last
- 希望仍在当前 location 内完成响应（比如文件服务或代理转发），就用 break
- server 块顶层的 rewrite 中，last 和 break 行为基本一致，可省略 flag；真正需区分的，只在 location 块内
- if 块里用 rewrite，推荐优先用 last，避免因上下文残留引发意料外行为
典型配置对比示例
假设配置如下：
location /old/ {
rewrite ^/old/(.*)$ /new/$1 last;
}
location /new/ {
return 200 "served by /new/";
}
访问 /old/test → 返回 “served by /new/”
若把 last 换成 break，/old/test 会尝试在 /old/ location 内找 /new/test 对应的文件或代理目标，而该 location 未定义任何服务指令，大概率返回 404。
