nginx通过location匹配路径并用proxy_pass转发至预定义upstream实现路由分发；需注意proxy_pass末尾斜杠对路径重写的影响，优先使用明确location块而非复杂正则以保障可维护性。
Nginx 中通过 location 块匹配请求路径，再结合 proxy_pass 指令将请求转发给不同的 upstream 服务器组，是实现路由分发的核心方式。关键在于路径匹配规则的准确性、proxy_pass 后 URL 的写法（影响路径重写），以及 upstream 的定义是否清晰。
定义多个 upstream 服务器组
在 http 块中预先定义好不同用途的上游服务，例如 API 服务、静态资源服务、后台管理服务：
upstream api_backend {
server 192.168.1.10:3000;
server 192.168.1.11:3000;
}
upstream static_backend {
server 192.168.1.20:8080;
}
upstream admin_backend {
server 192.168.1.30:8000;
}
用 location 精确匹配或前缀匹配路径
每个 location 块负责一类请求，匹配成功后通过 proxy_pass 转发到对应 upstream。注意末尾斜杠和路径传递逻辑：
-
匹配 /api/ 开头的请求 → 转发到 api_backend：
location /api/ { proxy_pass http://api_backend/; }
（末尾带/表示截掉/api/，再拼接后端路径） -
匹配 /static/ 开头的请求 → 转发到 static_backend：
location /static/ { proxy_pass http://static_backend/; } -
精确匹配 /admin/ → 转发到 admin_backend：
location = /admin/ { proxy_pass http://admin_backend/; }
（=表示严格等于，优先级最高）
避免常见路径转发错误
路径转发出错往往是因为 proxy_pass 后 URL 的斜杠处理不当：
-
proxy_pass http://backend;（无路径）→ 原始 URI 完整透传 -
proxy_pass http://backend/;（有结尾斜杠）→ 当前 location 匹配前缀被截掉，再拼接 -
proxy_pass http://backend/api;→ 会把匹配到的路径替换成/api，容易引发重写混乱，一般不推荐 - 若需改写路径，可配合
rewrite指令，但应优先用proxy_pass斜杠控制简化逻辑
补充：支持正则匹配与变量转发
复杂路由可使用正则 location ~，甚至结合 $1 捕获组动态选择 upstream（需配合 map 或 if，但 if 在 location 中慎用）：
map $uri $upstream_host {
~^/v1/(.*)$ api_v1_backend;
~^/v2/(.*)$ api_v2_backend;
default api_backend;
}
server {
location ~ ^/(v1|v2)/ {
proxy_pass http://$upstream_host;
}
}
不过 map + 变量方式适合规则较多场景；简单分流建议坚持用明确的 location 块，更直观、易维护。
