least_conn算法本身内存开销小，其有效性依赖连接池管理：需精调keepalive（如192）、设max_conns（高性能2400/普通800）、启用主动健康检查、监控连接真实性。
least_conn 算法本身不直接消耗显著内存，但支撑百万级在线连接时，它的有效性高度依赖 upstream 连接池的管理方式——而连接池正是内存开销的主要来源。优化关键不在“改算法”，而在让 least_conn 基于真实、轻量、可控的连接状态做决策。
精调 upstream keepalive 连接池大小
每个空闲 keepalive 连接会占用约 2–3 KB 内存（含 socket、buffer、connection 结构体）。设 10 万活跃后端连接，若每节点平均维持 50 条空闲长连接，仅这部分就超 5 GB 内存。
- 按后端单实例实际并发能力反推：若某服务稳定承载 25 并发，Nginx 有 8 个 worker，则 upstream keepalive 建议设为 192（8 × 24），而非盲目设 1000+
- 配套限制单连接生命周期：keepalive_timeout 30s（避免长空闲占位），keepalive_requests 500（防状态污染）
- 必须开启：proxy_http_version 1.1 和 proxy_set_header Connection ""，否则后端可能主动关闭复用连接，导致池失效并反复建连
用 max_conns 实现容量感知，替代无效连接堆积
least_conn 默认只比“当前连接数”，但一台 32C64G 后端和一台 8C16G 后端，即使都只有 10 个连接，负载能力差 3 倍以上。靠 max_conns 可软性约束接入上限，让算法在“可服务范围内”选最少连接者，避免小节点被误判为空闲。
- 高性能节点设 max_conns 2400，普通节点设 max_conns 800（数值需结合后端最大连接池上限设定）
- 注意：max_conns 是硬限，达到即跳过该节点参与 least_conn 比较，不会排队等待——这反而降低了 Nginx 层连接状态维护压力
- 新节点上线加 slow_start=60s，防止冷启动瞬间建立大量连接，冲击内存与后端
健康检查必须主动且轻量，避免“僵尸连接”干扰统计
被动检查（proxy_next_upstream）无法识别“连接已建立但响应卡死”的节点。这类节点连接数低，least_conn 会持续导流过去，造成连接堆积、内存泄漏式增长。
- 启用 active health check（需商业版或 patch 版）：health_check interval=2s fails=2 passes=3，用 match 验证 HTTP 状态码 + 关键 header（如 X-App-Status: ok）
- 检查接口必须独立、无缓存、免鉴权，路径如 /healthz，严禁复用业务接口
- 若只能用 passive 模式，至少配 proxy_next_upstream error timeout http_500 http_502 http_503 + max_fails=2 fail_timeout=10s，加速异常节点隔离
监控连接状态真实性，而非只看数字
least_conn 是否有效，不能只盯 upstream 的 $upstream_addr 或 $upstream_connect_time，要验证“连接数少”是否等于“能及时处理请求”。
- 采集指标：每秒向各 upstream 节点发起的 active connection 数、sent/request ratio、upstream response time P95
- 重点告警：某节点 active connections 2s ——说明连接挂着但不干活，需立即下线排查 GC 或锁表
- 配合日志：开启 log_format upstream_log ... "$upstream_addr $upstream_connect_time $upstream_header_time $upstream_response_time"，抽样分析慢连接成因
