Nginx upstream同一组中仅支持轮询、加权轮询或ip_hash中的一种算法，不可混用；需按业务路径（如/auth用ip_hash、/static用加权轮询）分设upstream并用location精准路由。
不能直接“整合”轮询、权重与ip_hash三种算法——Nginx upstream 在同一组中只允许启用一种调度策略。所谓“统一网关”的弹性，不在于把它们堆在一起，而在于按业务维度分层或分路径精准选用，并通过配置结构实现逻辑统一。
按业务路径拆分策略，而非混用同一upstream
一个真实的企业网关通常面对多种流量：API接口、静态资源、登录态敏感操作、后台管理等。强行要求所有请求走同一个 ip_hash 组，会破坏无状态服务的伸缩性；全用加权轮询又会让购物车、下单流程频繁跳转后端，丢失 session。
- 为需要会话保持的路径（如 /api/order、/auth）单独定义 ip_hash upstream，绑定专用后端池
- 为无状态高吞吐路径（如 /api/v1/log、/static）使用加权轮询 upstream，按机器规格分配 weight
- 在 server 块内用 location 匹配路径，分别 proxy_pass 到不同 upstream 名称
用 weight + max_fails 实现带容错的动态能力适配
权重不是静态数字，而是对后端真实处理能力的表达。比如新上线的 32C64G 节点可设 weight=5，老旧的 8C16G 设为 weight=1；但若该节点因 GC 暂时响应变慢，仅靠 weight 无法规避——必须配合健康检查。
- 每个 server 行显式写 weight=数值 max_fails=3 fail_timeout=30s
- 避免依赖默认值，尤其 max_fails 默认为 1，fail_timeout 默认为 10s，太敏感易误剔
- 若后端支持 HTTP 健康探测（如返回 200 /health），可搭配第三方模块（如 nginx-plus 或 openresty 的 healthcheck）做主动探活
ip_hash 的边界必须清晰，且需前置识别真实客户端IP
ip_hash 看似简单，但极易在 CDN、SLB、NAT 后失效——它哈希的是 $remote_addr，不是用户真实 IP。一旦前端有代理，必须提前用 real_ip_header 和 set_real_ip_from 还原。
- 在 http 块开头配置可信代理段：set_real_ip_from 192.168.0.0/16;（根据实际入口网段调整）
- 声明头字段：real_ip_header X-Forwarded-For; 或 X-Real-IP（与前端负载层约定一致）
- ip_hash upstream 内禁用 backup/server down 等状态标记——它不支持自动故障转移，节点宕机即导致对应 IP 段请求全部失败
统一网关的真正“统一”，在于配置组织与可观测性
把所有 upstream 按用途归类到独立 conf 文件（如 upstream_api.conf、upstream_session.conf），再用 include 引入主配置；同时为每个 proxy_pass 添加 consistent 日志字段（如 $upstream_addr、$upstream_http_x_trace_id），便于链路追踪与问题定界。
- 用 map 指令预判路由意图：map $request_uri $backend_group { ~^/api/order/ "session_pool"; ~^/static/ "static_pool"; default "api_pool"; }
- 结合变量 proxy_pass http://$backend_group; 实现轻量级动态路由
- 所有 upstream 块统一启用 keepalive 32; 并在 location 中配置 proxy_http_version 1.1; proxy_set_header Connection ''; 复用连接提升吞吐
