least_conn算法只依据tcp连接数选后端，不感知数据库连接池状态，导致连接池满时仍持续分发请求引发级联超时；排查需聚焦应用日志与连接池指标，而非nginx错误日志。
Nginx 的 least_conn 算法本身不感知数据库连接池状态，它只看上游服务的活跃 TCP 连接数。所谓“因后端数据库连接池满导致的级联超时”，本质是：应用层已无法获取 DB 连接 → 响应变慢或卡死 → Nginx 统计到该后端连接数持续偏高 → least_conn 仍将其视为“可用”而继续分发请求 → 请求堆积 → 触发 proxy_read_timeout → 返回 504 → 用户侧感知为“Nginx 超时”。排查必须穿透 Nginx，聚焦在应用与数据库之间。
后端应用日志是第一排查入口
不要查 Nginx error.log，它只会记录“upstream timed out”或“no live upstreams”，掩盖真实原因。
直接查看应用进程日志（如 Java 的 stdout、Spring Boot 的 logback 输出），搜索以下关键词：
-
Connection is not available, request timed out after（HikariCP） -
Unable to acquire JDBC Connection（Hibernate/JPA） -
waited for connection或connection pool exhausted -
No operations allowed after connection closed（说明连接被 DB 主动断开，但应用未正确处理）
确认是否在超时发生前，已有大量同类报错集中出现——这是连接池打满的明确信号。
验证数据库连接池实际使用情况
登录应用所在服务器，用 JMX、Actuator 或命令行工具检查实时连接池指标：
- Spring Boot Actuator
/actuator/metrics/datasource.hikaricp.connections.active和.idle - JVM 进程内执行
jcmd <pid> VM.native_memory summary</pid>辅助判断内存压力是否影响连接分配 - 直连数据库执行
SHOW PROCESSLIST;（MySQL）或SELECT * FROM pg_stat_activity;（PostgreSQL），观察是否有大量Sleep状态连接，或长时间运行的慢查询阻塞线程
若发现 active = maxPoolSize 且 idle ≈ 0，基本可判定连接池已饱和。
检查 Nginx 是否错误地“保护”了问题节点
least_conn 在连接池满但应用未崩溃时，会持续把新请求导向该节点——因为它的 TCP 连接仍存活，健康检查未失败。需验证：
-
proxy_next_upstream是否包含timeout http_504？若缺失，Nginx 默认不重试 504，请求直接失败，无法触发 failover -
max_fails=2 fail_timeout=15s是否配置在每个server行？被动检查依赖后端返回错误码（如 502/503），但连接池满时应用常返回 500 或直接 hang 住，需额外加http_500 - 主动健康检查是否启用？例如
health_check interval=3 fails=2 passes=2 match=http_2xx;—— 若后端/health接口能主动探测连接池水位（如返回{"db": "unavailable"}），则可提前摘除
若只有被动检查且后端不返回显式错误，least_conn 就会把“慢但活着”的节点当成正常节点长期使用。
对齐超时参数，避免掩盖真实瓶颈
proxy_read_timeout 设得过大（如 300 秒），会让 Nginx 等待一个早已卡死的请求，拖累整个 worker；设得太小（如 10 秒），又可能误杀正常长耗时请求（如报表导出）。合理做法是：
-
proxy_read_timeout应略大于业务最长预期耗时（如普通接口设 60 秒，报表接口单独 location 设 600 秒） - 同时确保后端
connectionTimeout（如 HikariCP 的connection-timeout: 30000） proxy_read_timeout，否则 Nginx 等到超时才中断，而应用还在等 DB 连接 -
keepalive_timeout（客户端侧）和upstream keepalive（后端侧）需独立设置，避免长连接空闲期混淆响应延迟归因
验证 least_conn 是否真在起作用
光看配置没用，要验证连接分布是否符合预期：
- 开启
stub_status，访问/nginx_status，观察Active connections下各 upstream server 的数值是否随压测动态变化 - 在
log_format中加入$upstream_addr $upstream_connect_time $upstream_response_time，分析日志中连接建立耗时与响应耗时的分布是否匹配“最少连接”逻辑（例如连接数低的节点响应时间反而更长，说明它正在积压） - 在后端机器上执行
ss -tan | grep :8080 | grep ESTAB | wc -l，对比 Nginx 统计的活跃连接数是否一致——若差异大，说明 keepalive 复用未生效或连接泄漏
不复杂但容易忽略
