rewrite不直接实现负载均衡，仅用于URL路径重写以标准化请求，为location匹配和upstream分发做前置适配；它需配合proxy_pass使用，不能替代后端分组调度逻辑。
rewrite 指令本身不直接实现负载均衡，它主要用于 URL 重写（修改请求路径），不能替代 upstream 或 proxy_pass 的分发逻辑。但在负载均衡场景中，它可以配合 location 和 proxy_pass，通过改写 URL 路径，使后续匹配更精准、路由更灵活——本质是“为负载均衡铺路”，而非承担分发职责。
rewrite 的核心作用：统一路径结构，适配后端服务约定
很多后端服务对路径格式有硬性要求（如必须以 /v1/ 开头、不允许带版本前缀、需补全子路径等）。若原始请求路径不一致，直接 proxy_pass 可能 404 或路由错位。此时 rewrite 可提前标准化路径，再交由 location 匹配或 upstream 分发。
- 把 /api/user 改写为 /v2/user，再转发给 api-v2 组
- 把带版本号的请求 /v1/order 去掉前缀，变成 /order，供无版本感知的旧服务处理
- 将 /static/img/logo.png 重写为 /assets/img/logo.png，匹配静态资源服务器路径规则
典型配置组合：rewrite + location + proxy_pass
关键在于 rewrite 后触发新的 location 匹配（使用 break 或 last 标志控制流程），从而导向不同 upstream。以下是一个可落地的示例：
注意：rewrite 必须放在 location 块内，且通常搭配 last（终止当前 location，重新匹配）或 break（停止 rewrite，继续本 location 内后续指令）
- 匹配 /mobile/ 开头的请求 → 重写为去掉 mobile 前缀 → 进入新 location 匹配 → 转发到 mobile_backend
- 匹配 /admin/ → 重写为 /internal/admin/ → 触发内部管理路由规则
- 未匹配 rewrite 的请求，走默认后端
配置示意：
upstream mobile_backend { server 10.0.1.10:8080; }
upstream admin_backend { server 10.0.1.20:9000; }
upstream default_backend { server 10.0.1.1:8000; }
<p>server {
location ^~ /mobile/ {
rewrite ^/mobile/(.<em>)$ /$1 last;
}
location ^~ /admin/ {
rewrite ^/admin/(.</em>)$ /internal/admin/$1 break;
proxy_pass <a href="https://www.php.cn/link/a46f93fa4667378d8c6546b4a11520b2">https://www.php.cn/link/a46f93fa4667378d8c6546b4a11520b2</a>;
}
location / {
proxy_pass <a href="https://www.php.cn/link/45050a298f1b880fcadb9085073c6b3f">https://www.php.cn/link/45050a298f1b880fcadb9085073c6b3f</a>;
}
location / {
proxy_pass <a href="https://www.php.cn/link/70607e3a9b9376b3b41ecfc024f2c89c">https://www.php.cn/link/70607e3a9b9376b3b41ecfc024f2c89c</a>;
}
}⚠️ 注意：最后两个 location / 不会同时生效，Nginx 按匹配优先级和顺序取第一个成功匹配的块。实际应避免重复，用更精确的前缀或正则区分。
rewrite 与基于 URL 特征的动态匹配的边界
所谓“动态匹配”，真正起决定作用的是 location 的匹配机制（=、^~、~* 等）和 upstream 分组定义，rewrite 只是前置加工环节。它无法根据查询参数（?a=1&b=2）、请求头或运行时变量做条件跳转——这些需要 map 指令或 Lua（OpenResty）支持。
- ✅ 能做：基于路径字符串特征（如前缀、正则提取、固定替换）做标准化重写
- ❌ 不能做：根据 $arg_token 值选择不同 upstream；根据 $http_user_agent 决定转发目标；实时读取外部配置切换后端
- ? 替代方案：用
map提前将 URL 特征映射为变量，再在 proxy_pass 中引用，例如：proxy_pass http://$backend_group;
实用建议：何时用 rewrite，何时绕过它
不是所有 URL 分发都需要 rewrite。过度重写会增加维护成本和调试难度。优先考虑更清晰、更直接的方式：
- 如果后端路径天然一致（如 /api/users → api-servers，/web/login → web-servers），直接用多个
location+proxy_pass即可，无需 rewrite - 如果只是加/删前缀，且后端能兼容，用
proxy_pass末尾斜杠控制路径拼接（如proxy_pass http://backend/;会剥离 location 路径） - 仅当路径结构差异大、且必须统一格式才能被后端识别时，才引入 rewrite —— 它是“适配器”，不是“调度器”
