nginx路径处理不直接决定负载均衡，但可基于uri、请求头等变量构建哈希键实现业务感知调度；支持路径哈希、前缀加权、组合标识及防倾斜策略，提升一致性与可控性。
Nginx 对请求路径的处理本身不直接参与负载均衡决策，但路径特征可作为负载分发的关键依据，通过 hash 策略实现精细化、业务感知的流量调度。这不是简单的“路径转发”，而是将 URI、请求头、参数等变量转化为稳定哈希键，让同类请求始终落到同一后端，兼顾一致性与负载可控性。
路径哈希（hash $request_uri）实现业务级分流
当后端服务按资源类型或功能模块做了物理隔离（如静态资源、用户中心、订单服务分别部署），可基于路径做定向分发：
-
配置示例：
upstream static_backend { hash $request_uri consistent; server 192.168.1.20:8080; server 192.168.1.21:8080; } upstream api_backend { hash $request_uri consistent; server 192.168.1.30:8080; server 192.168.1.31:8080; } location ~ ^/(images|css|js)/ { proxy_pass http://static_backend; } location /api/ { proxy_pass http://api_backend; } consistent启用一致性哈希，增减节点时仅少量请求重映射，避免缓存雪崩或会话抖动。注意：
$request_uri包含查询参数，若需忽略参数（如/product?id=123和/product?id=456应归为同一类），改用$uri（不含 query string）。
基于路径前缀的加权分组调度
对同一路径下的不同版本或灰度环境，可用 map 指令提取路径特征并映射权重：
-
示例：将
/v2/开头的请求按 7:3 权重分到新旧集群：map $uri $backend_group { ~^/v2/ "new_cluster"; default "old_cluster"; } upstream new_cluster { server 192.168.1.40 weight=7; server 192.168.1.41 weight=3; } upstream old_cluster { server 192.168.1.50; } location / { proxy_pass http://$backend_group; } 这种方式无需修改应用代码，适合灰度发布、AB测试等场景。
路径+Header 组合哈希提升会话稳定性
单一路径可能不足以区分用户上下文（如多租户 SaaS 系统），建议组合关键标识：
- 使用
$http_x_tenant_id（租户头） +$uri构建复合键：upstream tenant_backend { hash "$http_x_tenant_id:$uri" consistent; server 192.168.1.60; server 192.168.1.61; } - 租户内相同路径请求始终落在同一节点，利于本地缓存复用和状态聚合。
- 若 header 缺失，Nginx 默认哈希空字符串，可能导致所有无租户标识请求集中到一个节点——建议配合
proxy_set_header X-Tenant-ID $host;补全兜底值。
避免路径处理引发的负载倾斜
路径哈希虽精准，但易因 URL 分布不均导致后端压力失衡：
- 常见风险点：
- 大量请求集中在
/health、/favicon.ico等高频短路径，造成单节点过载； - 日志类路径（如
/log/upload）突发流量未做限流，挤占核心服务连接；
- 大量请求集中在
- 应对措施：
- 对监控、探针类路径单独配置
upstream并限制连接数（max_conns=10）； - 使用
limit_req针对特定路径限速，防止爬虫或误调用冲击； - 定期用 access log 分析
$uri访问频次分布，识别长尾路径并优化路由逻辑。
- 对监控、探针类路径单独配置
路径不是负载均衡的起点，而是业务语义的入口。合理利用它，能让流量分配从“机械轮转”升级为“有理解的调度”。
