Nginx负载均衡优化关键在于匹配流量特征与后端能力：按业务选算法（轮询、加权轮询、ip_hash或least_conn），合理配置长连接（keepalive_timeout、keepalive_requests及upstream keepalive），启用主动健康检查（health_check、slow_start），并叠加限流（limit_conn/req）与故障重试（proxy_next_upstream）实现防雪崩和灰度控制。
直接用 Nginx 优化负载均衡配置，关键不是堆参数，而是让策略匹配真实流量特征和后端能力。重点在算法选对、连接管好、故障能自动响应。
按业务类型选准调度算法
轮询适合三台配置一致的 Web 服务；加权轮询更实用——比如一台 16 核服务器设 weight=5，另一台 8 核设 weight=2，第三台做备用（加 backup 标识），这样流量分配基本贴合实际处理能力。
需要用户始终访问同一台后端时（比如没做 session 共享的老系统），用 ip_hash；但要注意 CDN 或代理环境下真实 IP 会被掩盖，这时得配合 $http_x_forwarded_for 做二次哈希，或改用 hash $cookie_jsessionid 等更稳定的键。
长连接多的场景（如 API 网关、WebSocket 服务），必须启用 least_conn，否则连接会越堆越多，某台机器先卡住再拖垮整个池。
管好长连接，减少握手开销
客户端到 Nginx 这一段，开启 Keep-Alive：
- keepalive_timeout 75s：比后端服务的超时时间略短，避免 Nginx 主动断连而服务还在处理
- keepalive_requests 100：单个连接最多处理 100 个请求，太高易占内存，太低复用率低
Nginx 到后端这一段，要用 upstream 里的 keepalive 参数建连接池：
- 设为 keepalive 32，表示每个 worker 进程最多缓存 32 条空闲连接
- 必须搭配 proxy_http_version 1.1 和 proxy_set_header Connection ""，否则 HTTP/1.1 的 Keep-Alive 不生效
让健康检查真正起作用
光写 max_fails=3 fail_timeout=30s 是被动检测，容易滞后。生产环境建议：
- 每台后端加 health_check interval=5s fails=2 passes=2（需 Nginx Plus 或开源版编译时启用 healthcheck 模块）
- 健康检查路径走独立接口，比如 uri=/health，返回 200 且响应体含 {"status":"ok"}
- 对关键服务，可配置 slow_start=30s，新上线节点逐步承接流量，避免瞬间压垮
防雪崩与灰度控制
大流量下，单靠算法不够，得加保护层：
- 用 limit_conn 和 limit_req 控制单 IP 或全局并发/请求数，防止恶意刷或突发打爆上游
- 蓝绿部署时，把两组后端分别定义为 upstream blue 和 upstream green，再用 map 或变量动态 proxy_pass，切流不重启
- 加 proxy_next_upstream error timeout http_500 http_502 http_503，让失败请求自动转给下一台，而不是立刻报错
