选last还是break取决于重写后uri的处理主体：需交由另一location处理则用last，否则用break；last触发重新匹配location，适合php入口转发等场景；break终止重写链并在当前location执行后续指令，常用于proxy_pass路径调整。
选 last 还是 break，关键看重写后的 URI 该由谁来处理：要交给另一个 location 处理，就用 last；想留在当前 location 里直接服务或转发，就用 break。
需要重新匹配 location → 用 last
当 rewrite 后的路径逻辑上属于别的处理模块时，比如把 /api/v1/xxx 改成 /index.php?r=xxx，就得让这个新 URI 再走一遍 location 匹配，才能进到 PHP 处理的 location 块里。
- last 会丢弃当前匹配结果，用新 URI 从 server 块开头重新 search location
- 适合配合
alias使用——因为 alias 的路径替换依赖 location 的完整匹配上下文，只有 last 能触发重匹配来激活它 - 常见于根路径标准化、API 版本路由跳转、PHP 入口统一转发等场景
想在当前 location 内继续执行 → 用 break
如果重写只是内部路径调整，后续仍由当前 location 的 proxy_pass、root 或 try_files 处理，那就用 break，避免多一次匹配开销和潜在循环风险。
- break 终止 rewrite 指令链后，直接用新 URI 执行当前 location 后续指令
- proxy_pass 场景下常用 break：URI 改写后作为相对路径透传给后端，例如
rewrite ^/old/(.*)$ /new/$1 break;+proxy_pass http://backend;→ 实际发往http://backend/new/xxx - 注意别在 alias 下误用 break，容易因路径对齐失败导致 404
server 块里基本不用纠结
server 块顶层的 rewrite，无论加 last 还是 break，行为几乎一样：都终止后续 rewrite，然后自然进入 location 匹配阶段。所以通常可以省略 flag，或只加 last 来明确语义。
- 真正需要区分 last/break 的，99% 发生在 location 块内部
- if 块中建议优先用 last，因为 if 本身不构成独立匹配上下文，last 更符合“重走流程”的直觉
避坑提醒
两个典型错误配置后果很直接：
- 该用 last 却写了 break：新 URI 留在原 location，可能 proxy_pass 多拼了一级路径（如
/api/v2/变成/api/api/v2/），后端 404 - 该用 break 却写了 last：重写后反复匹配不到对应 location，触发内部重定向循环，Nginx 返回 500 并报错 “rewrite or internal redirection cycle”
