Linux怎么查看Nginx当前的连接池状态

排查 Nginx 连接池状态，最直接的路径就是检查 /nginx_status 这个端点。但很多时候，你兴冲冲地配置好，一访问却给你返回 404 或 403，一脸懵。问题大概率出在两个地方：要么 Nginx 本身就没编译 ngx_http_stub_status_module 这个模块，要么就是配置细节上踩了坑。

验证模块是否启用，其实一行命令就能搞定：直接运行 nginx -V 2>&1 | grep -o with-http_stub_status_module。有输出，说明模块已就位；没输出，那你就得考虑重编译 Nginx，或者换个包——比如 Ubuntu 下，用 nginx-full 通常就带着这个模块，而轻量级的 nginx-light 则没有。

假设模块确认存在，配置也写了，但还是不行？那多半是下面这三个细节里，至少有一个被忽略了。

配置 /nginx_status 时最容易漏掉的三件事

第一，stub_status on; 这个指令，必须放在 location 块里面才有效。你把它写在 server 块或者 http 块里，Nginx 会直接忽略它。第二，访问控制的 allow 和 deny 顺序千万不能搞反。如果你写成了 deny all; allow 127.0.0.1;，那结果就是所有人都被拒了，因为 Nginx 是按顺序逐条检查规则的。正确的做法是，allow 在前，deny all 在后。第三，要检查一下你的监听地址。很多服务器上跑了多个 server 块，都监听着 80 端口。如果你只在其中一个块里配置了 /nginx_status，而你访问的域名恰恰命中了另一个块，那自然就是 404。

好，配置搞定，来看看通过 curl 访问 /nginx_status 后返回的信息到底说了什么。

看懂 status 页面上的几个关键数值

成功的话，你大概会看到类似这样的输出：

Active connections: 12
server accepts handled requests
 123456 123456 234567
Reading: 2 Writing: 5 Waiting: 5

这里面，Active connections 是当前所有活跃的 TCP 连接数——它包含正在读请求头的、正在写响应的、以及正在发呆等新请求的，可不是单纯的并发请求数。而 accepts 和 handled 这两个数值，分别代表 Nginx 启动以来接受的连接总数和成功处理的连接数。如果这两个数相等，说明 Nginx 从来没拒绝过连接，这是个不错的迹象。

下面三行则更具实时性：Reading 表示 Nginx 正在读取请求头的连接数，Writing 是它正在往客户端发送响应的数量，Waiting 则是最容易被忽视的——那些已经处理完请求、还在 keepalive 里等着下一个请求的空闲连接。这三个数字，能直接反映你当前连接池的“心跳”节奏。

不用 stub_status，也能看个大概

当然，有些场景下你没法改配置，或者模块就是装不上。这时候，系统级的命令也能帮你粗略估算一下压力。比如用 ss -ant 'sport = :80' | wc -l 来统计 80 端口上的 ESTABLISHED 连接，速度比 netstat 快得多。也可以更精确地过滤出与 Nginx 相关的连接：ss -ant state established '( sport = :80 or dport = :80 )' | wc -l。

另外，TIME_WAIT 的数量值得特别关注。用 ss -ant state time-wait '( sport = :80 or dport = :80 )' | wc -l 瞧一眼，如果这个数字长期高于 2000，说明短连接过于频繁，就需要考虑调优 keepalive_timeout 或者看看客户端是不是有问题了。

这里必须说一点：ss 统计的是内核级的 TCP 状态，和 stub_status 里的 Active connections 虽然接近，但并不完全等价。因为 stub_status 还包含了那些处于 keepalive 空闲状态但尚未断开的连接，而 ss 只看内核里实实在在的状态。

其实，盯连接池压力，最重要的并不是盯着某个绝对数值，而是关注比例。真正有价值的是 Waiting 占 Active connections 的百分比。如果这个比例长期低于 10%，说明你的 keepalive 基本上没起作用，连接一用完就断，白白浪费了握手开销。如果长期高于 80%，那问题可能更大——要么是后端响应太慢，请求都在排队；要么是客户端发请求太频繁，导致大量连接卡在 Waiting 状态动弹不得。这才是需要警惕的信号。