实现复杂负载均衡需按业务约束组合基础能力：会话一致性用ip_hash、静态资源用独立轮询upstream；异构环境用动态权重与健康检查；通过map变量实现灰度发布等智能路由。
实现复杂负载均衡配置，关键不在于堆砌功能，而在于根据业务真实约束组合基础能力——比如会话一致性、性能差异、故障恢复和流量治理需求。Nginx 本身不提供“一键复杂”，但通过 upstream 模块的灵活编排，能把轮询、权重、哈希、健康检查、备份节点、慢启动等机制有机组合，形成贴合生产环境的策略。
按业务状态做精准分流
当后端服务存在有状态与无状态混合部署时，不能只用一种算法。例如用户登录态依赖本地 session（未接入 Redis 共享），但静态资源又希望均匀分发：
- 用 ip_hash 保证同一用户始终落到同一台应用服务器，避免登录态丢失
- 对 /static/、/images/ 等路径单独配置 location，指向另一个 upstream（仅含轮询策略），专用于静态资源
- 注意：ip_hash 不适用于 CDN 或 NAT 环境，若真实 IP 被代理覆盖，需配合 $http_x_forwarded_for 或 realip 模块还原
应对异构服务器与动态伸缩
新老机器混用、云上自动扩缩容时，固定权重易失效。更稳妥的做法是：
- 为高性能节点设较高 weight（如 weight=5），普通节点设基础值（weight=1–2）
- 加上 max_fails=2 fail_timeout=15s，让 Nginx 主动探测并临时剔除失联节点
- 新增节点时，搭配 down 参数先标记为“下线”，验证后再移除；缩容前加 backup 标记，让其只在其他节点全不可用时才承接流量
构建带健康检查与降级能力的链路
默认被动检查（请求失败才剔除）不够及时。进阶做法包括：
- 启用主动健康检查（需 nginx-plus 或开源版配合第三方模块 nginx_upstream_check）：定期发 HEAD 请求或自定义探针路径
- 设置 slow_start=30s，让新加入的节点逐步承接流量，避免冷启动过载
- 定义 backup server + proxy_next_upstream error timeout http_500，当主池全部异常时，自动切到备用集群或返回友好页面
结合变量与运行时决策
Nginx 支持基于请求特征做条件路由，让负载逻辑更智能：
- 用 map 指令提取 header、cookie 或 URL 参数，生成变量（如 $route_key）
- 在 upstream 内使用 server ... route $route_key（需启用 hash 指令配合）
- 典型场景：灰度发布时，将带特定 cookie 的用户导向 v2 版本集群；或按地域 header 分流至不同机房
