Nginx 上游服务偶发 502？一次从连接池耗尽到 Keepalive 配置缺失的排查实践

线上经常会遇到这样的问题：Nginx 本身运行正常，后端服务也没有宕机，但业务偶尔出现大量 502 错误。

查看错误日志：

tail -f /var/log/nginx/error.log

日志中可能出现：

connect() failed (111: Connection refused) while connecting to upstream

或者：

upstream prematurely closed connection

很多运维人员会优先排查应用日志，但实际上问题可能出现在 Nginx 与后端之间的连接管理。

查看当前连接情况：

ss -ant | grep ESTAB | wc -l

查看后端服务连接数：

ss -ant | grep :8080 | wc -l

如果发现连接数量持续增长，而后端服务 QPS 并不高，就需要关注连接复用问题。

例如典型配置：

upstream api_backend {

    server 10.0.0.11:8080;

    server 10.0.0.12:8080;

}

对应代理：

location / {

    proxy_pass http://www.landui.com_backend;

}

这种配置虽然能正常工作，但 Nginx 每次请求都会重新建立 TCP 连接。

假设：

10000 QPS

则每秒需要创建：

10000 次 TCP 握手

10000 次 TCP 挥手

后端服务会产生大量：

TIME_WAIT

CLOSE_WAIT

状态连接。

查看：

ss -s

输出可能类似：

TCP:

    estab 200

    timewait 85000

优化方式是在 Upstream 中开启 Keepalive：

upstream api_backend {

    server 10.0.0.11:8080;

    server 10.0.0.12:8080;

    keepalive 200;

}

同时增加：

location / {

    proxy_http_version 1.1;

    proxy_set_header Connection "";

    proxy_pass http://www.landui.com_backend;

}

验证连接复用：

ss -ant | grep :8080

正常情况下连接数量会保持稳定。

很多人只配置：

keepalive 200;

却忘记：

proxy_http_version 1.1;

导致连接仍然无法复用。

查看 Nginx 状态页：

location /nginx_status {

    stub_status;

}

访问：

curl http://www.landui.com/nginx_status

输出：

Active connections: 500

Reading: 2

Writing: 8

Waiting: 490

Waiting 数量较高通常说明 Keepalive 正常工作。

另一方面，还需关注后端服务连接池限制。

例如 Java 应用：

server.tomcat.max-connections=10000

数据库连接池：

spring.datasource.hikari.maximumPoolSize=50

如果数据库连接池仅有 50 个连接：

Nginx 连接正常

Tomcat 连接正常

数据库连接耗尽

最终仍然会返回 502。

查看应用线程状态：

jstack PID | grep WAITING

或者：

jstack PID | grep BLOCKED

可以发现线程是否被数据库连接阻塞。

对于高并发场景，还应调整 Nginx 超时参数：

proxy_connect_timeout 3s;

proxy_send_timeout 30s;

proxy_read_timeout 30s;

避免默认超时过长导致连接堆积。

查看当前 Worker 连接数限制：

nginx -T | grep worker_connections

例如：

worker_connections 10240;

理论最大连接数：

worker_processes × worker_connections

如果：

worker_processes auto;

worker_connections 10240;

8 核服务器理论支持：

8 × 10240 = 81920

个连接。

同时确认系统文件句柄：

ulimit -n

推荐：

65535

以上。

生产环境中大量 502 并不一定意味着后端服务故障。很多时候只是因为 Nginx 与上游之间没有启用连接复用，导致连接建立和释放成本过高，最终耗尽应用资源。合理配置 Keepalive、连接池以及超时参数，往往比单纯扩容服务器更能解决问题。