Stub-Status模块默认未启用，需通过nginx -V确认是否含with-http_stub_status_module；启用后须限制访问IP，其输出中Active connections为当前TCP连接总数，accepts/handled/requests分别表示接收/处理连接数和HTTP请求数，Waiting为keepalive空闲连接数。
Stub-Status 模块是否已启用？先确认再操作
绝大多数编译安装的 Nginx 默认不启用 stub_status 模块，而包管理器安装（如 Ubuntu 的 nginx-full）通常包含它。直接访问 /nginx_status 返回 404 或 403，基本说明模块未启用或未配置 location。运行 nginx -V 2>&1 | grep -o with-http_stub_status_module，若无输出，需重新编译并添加 --with-http_stub_status_module 参数。
如何安全暴露 stub_status 接口？别直接开给公网
Stub-Status 返回的是纯文本指标，无认证、无加密，暴露在公网等于公开服务器实时负载。必须限制访问来源，常见做法是只允许本地采集或内网监控节点：
- 用
allow/deny控制 IP：location /nginx_status {<br> stub_status;<br> allow 127.0.0.1;<br> allow 10.0.1.50;<br> deny all;<br>} - 配合
auth_request做统一鉴权（适合已有内部 OAuth 服务） - 避免使用
localhost字符串——Nginx 中它不等价于127.0.0.1，IPv6 环回地址::1需单独写
解析 stub_status 输出的三行文本：每行代表什么压力维度？
访问成功后返回类似：
Active connections: 23<br>server accepts handled requests<br> 234567 234567 1234567<br>Reading: 0 Writing: 2 Waiting: 21
Active connections 是当前 TCP 连接总数（含 keepalive 空闲连接），不是并发请求数；accepts/handled/requests 三列分别表示：Nginx 接收的总连接数、成功处理的连接数（≈ accepts，除非遇到资源耗尽）、HTTP 请求总数；最后一行中 Waiting 是处于 keepalive 状态的空闲连接数——这个值高，说明客户端复用连接充分，但若持续 >80% 的 Active connections，可能掩盖真实请求积压。
-
Reading高 → 客户端发包慢或请求体大（如上传未完成） -
Writing高 → 后端响应慢或网络出口拥塞 -
Waiting占比异常低 +Active connections持续上涨 → 可能存在连接泄漏或 upstream 超时设置过短
用 curl + awk 实时抓取并计算 QPS？小心时间窗口陷阱
单纯轮询 /nginx_status 得到的是累计值，要算 QPS 必须做差分。但两次请求之间的时间间隔不能靠 sleep 控制——Nginx 自身处理状态页也有延迟，实际间隔可能漂移。更稳的方式是记录响应头中的 Date 时间戳：
curl -s http://127.0.0.1/nginx_status | awk '/^server/{r=$3} /^Active/{a=$3} END{print "req:", r, "active:", a}'
然后在外部脚本中保存上一次的 requests 和时间戳，用当前值减去上一次值再除以秒数。注意：requests 是 32 位整数，约 42 亿次后会回绕，高频服务需考虑溢出判断；另外，如果 Nginx 重启过，该计数归零，监控脚本必须能识别断点并重置差分基线。
真正卡住人的地方往往不是语法，而是把 Waiting 当成“空闲可压榨资源”——它本质是 HTTP/1.1 keepalive 的副产品，不代表系统有余力；而 Active connections 突增时，第一反应不该是扩容，得先看 Writing 是否同步飙升，否则大概率是上游服务拖慢了响应，不是 Nginx 本身扛不住。
