直接运行nginx -V 2>&1 | grep -o with-http_stub_status_module，若有输出则已编译启用，否则需重编译或更换含该模块的Nginx包。
如何确认 Nginx 是否启用了 stub_status 模块
直接访问 /nginx_status 返回 404 或 403，大概率是没启用 ngx_http_stub_status_module。这个模块不是默认开启的——即使你用包管理器（如 apt/yum）安装的 Nginx，也得看发行版是否预编译进去了。
验证方式很简单：nginx -V 2>&1 | grep -o with-http_stub_status_module
如果有输出，说明已编译支持；没输出，就得重编译或换包（比如 Ubuntu 的 nginx-full 包通常含该模块，nginx-light 不含）。
配置 /nginx_status 路径时最容易漏掉的三件事
即使模块存在，location /nginx_status 仍可能不生效，常见疏漏包括：
- 没把
stub_status on;放在location块内（放在server或http块里无效） -
allow和deny顺序写反，比如deny all; allow 127.0.0.1;实际会全拒——必须allow在前、deny all在后 - 监听地址绑定错误：如果 Nginx 配置了多个
server块，且都监听80，但/nginx_status只配在其中一个里，而你访问的是另一个 server 的域名，就会 404
curl 访问 /nginx_status 后看到的字段含义
成功返回类似：
Active connections: 12<br> server accepts handled requests<br> 123456 123456 234567<br> Reading: 2 Writing: 5 Waiting: 5
其中：
-
Active connections是当前所有 TCP 连接数（含ESTABLISHED+READING+WRITING+WAITING），不是并发请求数 -
accepts是 Nginx 自启动以来接受的连接总数；handled是成功处理的连接数（两者相等说明没发生过连接拒绝） -
requests是总 HTTP 请求次数；Reading是正在读取请求头的连接数；Writing是正向客户端发送响应的连接数；Waiting是已处理完请求、保持 keepalive 等待新请求的空闲连接数
不用 stub_status 也能粗略估算连接池压力
当无法修改配置或模块不可用时，可结合系统级命令交叉判断：
-
ss -ant 'sport = :80' | wc -l—— 比netstat更快，统计所有 80 端口的 ESTABLISHED 连接 -
ss -ant state established '( sport = :80 or dport = :80 )' | wc -l—— 更精确地过滤出与 Nginx 相关的活跃连接 - 查
TIME_WAIT数量：ss -ant state time-wait '( sport = :80 or dport = :80 )' | wc -l，若持续高于 2000，说明短连接频繁，可能需调优keepalive_timeout或客户端行为
注意：ss 统计的是 socket 级连接，和 stub_status 的 “Active connections” 数值接近但不完全等价——后者包含 keepalive 空闲连接，前者只统计内核 TCP 状态。
真正要盯住的不是绝对数值，而是 Waiting 占 Active connections 的比例：长期低于 10%，说明 keepalive 利用率低；长期高于 80%，可能意味着后端响应慢或客户端发请求太勤，连接卡在 Waiting 状态动不了。
