nginx不同业务负载分流核心是“请求特征识别+路由分发”：按uri路径（如location ^~ /api/）、host域名（server_name或map $host）、请求头/参数（map $http_x_client_type）等维度精准匹配，各自指向语义化upstream，确保流量隔离与策略独立。
在 Nginx 中实现不同业务的负载分流，核心是通过 请求特征识别 + 路由分发，将流量按业务类型（如 API、静态资源、后台管理、移动端接口等）导向不同的上游服务集群。这不是简单的轮询或哈希，而是基于 URI、Host、Header、参数甚至客户端 IP 等维度做精细化路由。
按业务路径（URI）分流
最常用也最直观的方式。例如把 /api/v1/user 分给用户服务，/static/ 分给 CDN 或静态文件服务器，/admin/ 分给后台管理系统：
- 使用
location块匹配路径前缀或正则，配合proxy_pass指向对应 upstream - 注意匹配顺序：Nginx 按最长前缀或正则优先级匹配，建议把精确或高优先级规则放前面
- 示例：location ^~ /api/ { proxy_pass http://backend_api; }（
^~表示前缀匹配且不继续正则检查）
按 Host 或域名分流
适用于多租户或多业务共用同一 IP 的场景。比如 shop.example.com 走电商服务，blog.example.com 走内容服务：
- 在
server块中用server_name区分，每个 server 块内独立配置 upstream 和转发逻辑 - 可结合
map指令预定义变量，简化配置。例如：map $host $upstream_backend { shop.example.com backend_shop; blog.example.com backend_blog; default backend_default; }，再在 location 中引用$upstream_backend
按请求头或参数识别业务类型
适合灰度发布、AB 测试或客户端类型区分（如 H5 vs App）。例如通过 X-Client-Type: app 或 version=2.0 参数路由到新版本集群：
- 用
map指令提取 Header 或 Query 参数，映射为 upstream 名称 - 配合
if（慎用）或proxy_set_header透传上下文，便于后端识别 - 注意：
if在 location 外不可用，且部分指令（如 proxy_pass）不能直接写在 if 内，推荐优先用 map + 变量方式
组合条件与兜底策略
真实场景中往往需要多个条件叠加判断，并确保未匹配请求有合理归宿：
- 可用
map嵌套或联合变量，比如 map "$host:$arg_version" $upstream { "shop.example.com:3.0" backend_shop_v3; ... } - 所有 location 都应有明确的
proxy_pass，避免 fallback 到默认 server 或返回 404 - 建议设置统一的
upstream兜底组（如backend_default），并在最后的 location 中捕获未匹配路径
