rewrite在proxy_pass前执行，修改URI后转发；proxy_pass末尾有/则剥离匹配前缀再拼接，无/则原样转发；break终止本location内rewrite，last触发重匹配location。
Nginx 中 Rewrite 规则与 proxy_pass 配合使用时，核心在于理解重写发生在代理前还是代理后、路径如何传递给后端，以及 location 匹配与 rewrite 的执行顺序。错误配置常导致 404、重复路径或后端收到异常 URI。
rewrite 在 proxy_pass 前生效，影响发往后端的路径
Nginx 的 rewrite 指令默认在 location 匹配后、进入内部处理流程（包括 proxy_pass）前执行。它修改的是当前请求的 URI，后续 proxy_pass 发送的就是重写后的路径。
- 若
proxy_pass末尾带斜杠（如proxy_pass http://backend/;），Nginx 会丢弃匹配的 location 路径前缀，再拼接 rewrite 后的 URI 路径 - 若
proxy_pass末尾不带斜杠（如proxy_pass http://backend;），则整个原始（或重写后）URI 会被原样转发，location 前缀不会被自动剥离 -
rewrite ... break;终止当前 location 内的 rewrite 处理，但不跳出 location；rewrite ... last;会重新匹配 location，可能触发新规则
常见场景：隐藏 /api 前缀并透传到后端根路径
前端访问 /api/v1/users，希望代理到 http://service/v1/users（即去掉 /api）：
location /api/ {
rewrite ^/api/(.*)$ /$1 break;
proxy_pass http://service/;
}说明：
– ^/api/(.*)$ 捕获 /api/ 后所有内容
– / 变成 /v1/users
– proxy_pass 末尾有 /，所以把重写后的路径直接拼到 http://service/ 后，最终请求后端 http://service/v1/users
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
避免路径重复：用 rewrite + proxy_pass / 替代硬编码路径
当需要将 /admin/xxx 映射为后端 /backend/xxx，不要写死 proxy_pass http://s2/backend/;，而应统一用 rewrite 控制：
location /admin/ {
rewrite ^/admin/(.*)$ /backend/$1 break;
proxy_pass http://s2/;
}这样逻辑清晰，且不依赖 proxy_pass 的路径拼接行为。如果误写成 proxy_pass http://s2/backend/;，又加了 rewrite，极易出现双 /backend/backend/ 类错误。
注意 rewrite last 和 break 的实际影响
下面两段配置效果不同：
# 方式 A（推荐）
location /old/ {
rewrite ^/old/(.*)$ /new/$1 break;
proxy_pass http://upstream/;
}# 方式 B（慎用）
location /old/ {
rewrite ^/old/(.*)$ /new/$1 last;
}
location /new/ {
proxy_pass http://upstream/;
}方式 A 在同一 location 内完成重写和代理，高效可控；方式 B 触发重匹配，多一次查找开销，且若 /new/ 未定义或被其他 location 拦截，会出错。除非需复用多个 location 的 proxy 公共配置，否则优先用 break。
