Stub-Status模块不是默认启用的，需通过nginx -V检查是否含with-http_stub_status_module；配置必须在location块中，配合access_log off和allow/deny访问控制；返回三行纯文本，含Active connections、accepts/handled/requests及Reading/Writing/Waiting状态。
Stub-Status模块是否默认启用
Nginx的stub_status模块不是默认编译进核心的，得看你的Nginx是否带了它。执行nginx -V 2>&1 | grep -o with-http_stub_status_module，如果没输出，说明没启用——这时候光配配置也没用，会报unknown directive "stub_status"错误。
常见场景是用包管理器（如apt/yum）装的Nginx，通常已含该模块；但自己源码编译时漏掉了--with-http_stub_status_module参数，就得重编译或换二进制包。
如何正确配置location暴露监控端点
不能直接在server块里写stub_status on——这个指令只在location上下文中有效，且必须配合access_log off和allow/deny做访问控制。
推荐配置如下：
location /nginx-status {
stub_status on;
access_log off;
allow 127.0.0.1;
allow ::1;
deny all;
}
-
/nginx-status路径可自定义，但别用/status这种太通用的，避免被扫描 - 必须显式关闭
access_log，否则每秒刷一条日志，磁盘和I/O压力不小 -
deny all要放在allow之后，否则全被拦掉 - 若需远程访问（比如Prometheus拉取），把
allow改成对应内网IP段，别开0.0.0.0/0
解析Stub-Status返回的原始数据
访问/nginx-status返回的是纯文本，三行内容，格式固定：
Active connections: 12 server accepts handled requests 123456 123456 234567 Reading: 0 Writing: 3 Waiting: 9
关键指标含义：
-
Active connections：当前TCP连接总数（含idle、reading、writing状态） -
accepts：Nginx启动后总共接受的TCP连接数 -
handled：成功处理的连接数（≈ accepts，除非达到连接上限或资源不足） -
requests：总共处理的HTTP请求数（一个连接可发多个请求） -
Reading：正在读取请求头的连接数（通常极小） -
Writing：正在向客户端发送响应的连接数 -
Waiting：空闲等待请求的keepalive连接数（= Active − Reading − Writing）
注意：Active connections不等于并发请求数，它包含长连接空闲态；真正反映负载的是Writing + Reading之和。
用curl或Exporter自动采集时的坑
直接用curl http://127.0.0.1/nginx-status拿数据没问题，但集成到监控系统时容易出错：
- 如果Nginx启用了gzip，
stub_status响应也会被压缩，部分旧版curl或脚本没处理Content-Encoding: gzip，导致解析失败 - Prometheus的
nginx-exporter默认用/basic_status路径，而官方Stub-Status是/nginx-status，路径不匹配就收不到数据 - 某些容器化部署中，Nginx监听在localhost，但Exporter跑在另一个容器里，网络不通，得确认
hostNetwork或service mesh配置 - 返回内容无HTTP状态码标识（始终200），靠文本解析，一旦Nginx配置变动（比如加了额外
add_header），可能破坏三行结构
最稳的方式是写个轻量shell或Python脚本，用grep或正则提取字段，并加超时和重试逻辑——别指望原始输出永远“干净”。
