last重启location匹配，用新URI从server块重新查找；break终止当前rewrite并继续在原location内执行后续指令。

在 Nginx 配置中，rewrite 指令的 last 和 break 标志看似相似，实则触发完全不同的请求处理流程。关键区别在于：是否重新发起内部重写匹配（即是否重启 location 查找）。

last：重写后重启 location 匹配

使用 last 时，Nginx 会：

• 执行完当前 rewrite 规则后，用新 URI 替换旧 URI
• 立即停止当前 location 块内后续的 rewrite 指令
• 根据新 URI 重新搜索匹配最合适的 location 块
• 从新匹配到的 location 块开头重新执行所有指令（包括其中的 rewrite）

这相当于一次“内部重定向”，适合需要切换上下文的场景，比如将 /api/v1/xxx 重写为 /v1/xxx 后交由专门处理 /v1/ 的 location 处理。

break：重写后终止重写阶段，继续当前 location

使用 break 时，Nginx 会：

• 执行当前 rewrite 规则，更新 URI
• 停止当前 location 块中所有剩余的 rewrite 指令
• 不重新匹配 location，直接进入该 location 块的后续处理阶段（如 proxy_pass、root 等）

它更像“URI 本地改写”，常用于路径标准化，例如把 /static/abc.css 改成 /assets/abc.css，仍由同一个静态文件 location 服务。

实际行为差异示例

假设有如下配置：

location /old/ {
    rewrite ^/old/(.*)$ /new/$1 last;
}
location /new/ {
    return 200 "served by /new/";
}

访问 /old/test → 重写为 /new/test → 重新匹配 → 进入 /new/ location → 返回 “served by /new/”。

若把 last 换成 break：

location /old/ {
    rewrite ^/old/(.*)$ /new/$1 break;
    return 200 "served by /old/";
}

访问 /old/test → URI 改为 /new/test，但仍在原 /old/ location 内继续执行 → 直接返回 “served by /old/”，/new/ location 完全不参与。

如何选择：看是否需要切换处理逻辑

选 last 当：

• 重写后应由不同 location（如不同 proxy_pass 或 root）处理
• 需应用新 location 中的 rewrite、access 控制等整套逻辑

选 break 当：

• 只是微调路径，后续仍走当前 location 的常规处理（如 alias、try_files）
• 要避免多轮 location 匹配带来的性能或逻辑干扰