提高Nginx集群调度稳定性需算法选对+健康兜底+真实指标反馈：依后端特性选加权轮询、ip_hash或least_conn；配置max_fails/fail_timeout与backup实现自动容灾；透传X-Real-IP并启用HTTP/1.1 keepalive；最后通过curl和stub_status验证实效。
提高 Nginx 集群中请求调度的稳定性，关键不是让单次分发“更快”，而是让流量分配更可预期、更抗干扰、更贴合后端真实负载状态。轮询看似简单，但裸用极易导致节点失衡或会话中断；真正稳定的调度，是算法选对 + 健康兜底 + 真实指标反馈的组合结果。
选对调度算法，匹配业务特征
默认轮询只保证“次数均等”，不等于“负载均衡”。必须根据后端服务特性动态适配：
- 后端性能差异大（如新旧机器混部）→ 改用加权轮询，例如新机 weight=5、旧机 weight=2，避免旧机 CPU 长期超 90%
- 存在登录态、购物车等内存级会话 → 必须启用ip_hash或 sticky cookie，防止用户反复跳转丢失上下文
- 请求耗时差异大（如含文件上传、报表导出）→ 切换为least_conn，优先将新请求导向当前活跃连接最少的节点，防堆积
- 短连接洪峰场景（如秒杀、抢券）→ least_conn 比轮询更能缓解瞬时打爆风险
配置健康检查与自动容灾
没有健康检查的负载均衡，等于把请求盲发给可能已宕机的节点。稳定调度的前提是“只往活节点发”：
- 在 upstream 中为每个 server 显式设置：max_fails=3 fail_timeout=30s，连续失败 3 次即剔除，30 秒后重试
- 搭配 backup 标记备用节点，主集群异常时自动切流，无需人工干预
- 长连接场景（如 WebSocket）建议加主动健康检查：health_check interval=3 fails=1 passes=1，更快感知异常
确保真实链路信息透传与连接复用
调度稳定不仅靠分发逻辑，还依赖上下游协同。两个常被忽略但影响深远的配置：
- proxy_set_header X-Real-IP $remote_addr：让后端能识别真实客户端 IP，支撑限流、风控、日志归因，避免所有请求都显示为 Nginx 内网地址
- proxy_http_version 1.1; proxy_set_header Connection ''; + keepalive_timeout 15s; keepalive_requests 100：复用后端连接，显著降低 TCP 握手开销，尤其对高频短连接场景效果明显
验证调度是否真生效，而非仅看配置
配置写完不等于跑稳。必须通过实际流量验证调度行为：
- 用循环命令快速发起请求：for i in {1..6}; do curl http://your-domain/; echo; done
- 观察返回头中的 Server 字段或后端日志时间戳，确认是否严格按预期顺序（A→B→C→A…）或连接数分布（least_conn 下应倾向低连接节点）
- 配合 stub_status 或 nginx-module-vts 实时查看各 upstream 节点的请求计数、失败数、当前连接数，及时发现倾斜或异常
