least_conn需置于upstream首行，配合keepalive、max_conns、健康检查及stub_status验证，确保金融业务高可用；Nginx版本不低于1.3.1，禁用ip_hash等互斥策略。
直接在 upstream 块中启用 least_conn 是基础，但保障核心金融业务的高可用，不能只靠这一行指令。它必须嵌入一套稳定、可观测、有兜底的配置体系中。
必须满足的版本与基础结构
Nginx 版本需 ≥ 1.3.1（强烈建议使用 1.20 或更高稳定版），可通过 nginx -v 确认。配置必须严格写在 upstream 块首行：
- 正确写法：upstream finance_api { least_conn; server 10.0.1.10:8443; server 10.0.1.11:8443; }
-
禁止混用：不能同时存在
ip_hash、hash或least_time；weight不影响连接数判断逻辑，仅在连接数相同时起倾向作用 -
四层场景同样适用：金融系统常用四层代理（如数据库、支付网关），可在
stream块中直接使用least_conn
连接池与长连接是 least_conn 发挥作用的前提
若每次请求都新建短连接，活跃连接数始终趋近于 0，least_conn 就退化为随机分发。必须让连接“活”起来：
- 在 upstream 中配置
keepalive 64（每个 worker 缓存最多 64 条空闲连接） - 在 proxy_pass 所在 location 中设置：
proxy_http_version 1.1和proxy_set_header Connection '' - 后端服务需支持 HTTP/1.1 keep-alive，例如 Spring Boot 调整
server.tomcat.connection-timeout，或数据库驱动启用连接复用
防止“假空闲”和单点雪崩的关键加固
金融接口常含长耗时操作（如风控核验、跨行清算），单个慢请求可能长期占用连接，但 least_conn 无法感知其内部卡顿。必须叠加防御机制：
- 为每个 server 设置
max_conns=500（根据压测确定合理值），达到上限即自动剔除调度 - 启用主动健康检查：
max_fails=2 fail_timeout=5s，配合health_check interval=3 rise=2 fall=3（需 Nginx Plus 或 OpenResty） - 设置超时参数：location 中加
proxy_connect_timeout 3s、proxy_read_timeout 30s（略高于 P99 延迟）、proxy_send_timeout 15s
可观测性：验证是否真实按连接压力调度
配置不报错 ≠ 生效。必须通过数据确认行为符合预期：
- 开启
stub_status模块，在 server 块中添加location /nginx_status { stub_status; }，定期采集各 backend 的 active 连接数 - 压测时观察：当某节点因慢查询堆积连接，其余节点 active 数应明显低于它；流量切走后，堆积节点连接数应快速回落
- 结合 Prometheus + nginx-vts-exporter 或 OpenResty 的
shdict实现跨 worker 连接数聚合监控（弥补 Nginx 默认 per-worker 统计偏差）
