break 终止当前 location 内 rewrite 并继续执行后续指令，last 则用新 URI 重新匹配 location；server 块中二者行为趋同；proxy_pass 场景下 break 直接转发，last 需匹配新 location 否则 404。
break 和 last 都会让 Nginx 停止执行当前 rewrite 指令块中后续的 rewrite 规则，但它们对重写后 URI 的处理路径完全不同。
break：留在当前 location，继续往下走
rewrite 带 break 标志时：
- 立即终止本 location 内剩余所有 rewrite 指令
- 不重新匹配 location，也不跳转上下文
- 继续执行当前 location 中 rewrite 后面的指令（如 proxy_pass、root、try_files、return 等）
- 最终响应基于重写后的新 URI，在当前 location 内完成
适合静态资源内部路径调整，比如把 /img/logo.png 改成 /static/logo.png，然后由当前 location 直接提供文件。
last：用新 URI 重新发起一次内部请求
rewrite 带 last 标志时：
- 同样终止当前 rewrite 指令集的后续规则
- 丢弃当前 location 上下文，用重写后的新 URI 从头开始匹配：先 server 块 rewrite（如有），再重新 search 所有 location
- 相当于一次“内部重请求”，浏览器地址栏不变，客户端无感知
- 若新 URI 匹配不到任何 location，会 fallback 到默认 root 或返回 404
适合需要多层路由逻辑的场景，比如将 /api/v1/user/123 重写为 /index.php?r=user/view&id=123，再交由 PHP 处理的 location 接管。
linux-sysadmin
下载
Linux系统管理专家，覆盖12大模块：用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词：useradd、sudo、sshd_config、chmod、SEL...
server 块里写 rewrite，break 和 last 差别不大
在 server 块顶层（location 外）使用 rewrite 时：
- 两者都只终止本组 rewrite 指令
- 都会自然进入 location 匹配阶段（这是 server 处理完 rewrite 后的必经流程）
- 真正需要区分行为的，是 rewrite 出现在 location 块内部时
所以 server 级 rewrite 通常可省略 flag，或仅在强调语义时加 last。
proxy_pass 场景下表现差异最明显
当 rewrite 和 proxy_pass 共存于同一 location 时：
- break：重写后 URI 直接透传给后端。若 proxy_pass 带路径（如 proxy_pass http://b/api/;），Nginx 会去掉原始匹配前缀再拼接；若不带路径（如 proxy_pass http://b;），则原样转发完整 URI
- last：重写后先重新匹配 location。如果没配对应 location，请求直接 404，proxy_pass 根本不会执行；如果匹配到了另一个含 proxy_pass 的 location，则由它来转发
典型踩坑：在 location /api/ 中写 rewrite ^/api/(.*)$ /v2/$1 last;，但没定义 location /v2/，结果请求失败。
