Nginx upstream通过least_conn、严格重试控制、主动健康检查和前置限流来防控雪崩：优先调度连接数少的节点，禁用非幂等操作重试，定期探活隔离故障节点，并在proxy_pass前限流防压垮后端。
upstream 模块本身不直接“解决”雪崩，而是通过合理配置把雪崩风险控制在可接受范围。关键不是堆节点或加权重，而是让 Nginx 主动识别压力、及时规避故障、拒绝无效重试。配置不当反而会放大负载，把一次超时变成三次打满。
用 least_conn 替代轮询，从源头减少连接堆积
轮询算法只看顺序，不管后端真实负载。当某台机器因 GC、锁竞争或慢查询导致连接堆积时，轮询仍会继续分发新请求，加速其崩溃。least_conn 则优先选当前活跃连接数最少的节点，天然适配高并发、长连接场景（如 WebSocket 网关、实时 API）。
- 必须配合 keepalive 复用连接：在 upstream 块中加 keepalive 32，并在 location 中启用 HTTP/1.1 和 Connection 头
- 避免和 ip_hash 或 weight 冲突：least_conn 是独立策略，启用后就不要混用 ip_hash
- 验证是否生效：用 curl -I 多次请求，再查 Nginx access_log 的 $upstream_addr 字段，确认请求确实落在连接数更少的节点上
严格限制重试行为，防止错误被复制放大
重试是雪崩最常见的推手。一次失败的 POST 请求若盲目重试 3 次，等于向后端集群注入 3 倍压力，尤其在数据库写入、模型推理等资源密集型操作中极易连锁崩溃。
- 设 proxy_next_upstream_tries 1 彻底禁用重试，适用于订单提交、支付回调等非幂等操作
- 若必须重试（如 GET 查询），设 tries 3 + proxy_next_upstream_timeout 10s，确保总耗时不超预期（例如单次正常响应约 3 秒）
- 只对真正可重试的错误开启：显式列出 error timeout http_502 http_503 http_504，禁用 http_500（业务异常重试无意义）和所有 4xx
配置主动健康检查，别等请求失败才反应
靠 proxy_next_upstream 被动换节点，等于等病人倒下再抬走；而主动健康检查是定期巡房，提前发现高 CPU、满连接、假存活节点并隔离。
- 在 upstream 块中加：health_check interval=3 fails=2 passes=2;
- 检查路径必须真实反映服务可用性，例如 check_http_expect_alive 2xx 3xx;，避免用返回 200 的空 /health 接口
- 搭配 max_fails=2 fail_timeout=30s 做双重保障：既防偶发抖动，也兜底健康检查失效场景
- fail_timeout 别设过长（如 60s），否则节点已挂却还要参与转发十几秒
设置连接与请求级限流，给后端留出喘息空间
upstream 不提供限流能力，但可通过 proxy_pass 上游前的 location 级限流，避免突发流量直接压垮集群。
- 在 http 块定义限流区：limit_req_zone $binary_remote_addr zone=perip:10m rate=10r/s;
- 在对应 location 中启用：limit_req zone=perip burst=20 nodelay;
- 对关键接口（如导出、搜索）单独限流，避免一个慢接口拖垮整个 upstream 组
- 结合 proxy_buffering off; 和 proxy_request_buffering off; 防止大请求体在 Nginx 层积压内存
