要让 Nginx 暴露性能监控接口，需启用原生 stub_status 模块：确认编译时含 with-http_stub_status_module，配置本地 server 块并限制访问，返回 Active connections、accepts/handled/requests 三组累加值及 Reading/Writing/Waiting 连接状态，结合日志与系统指标实现闭环监控。
要让 Nginx 暴露可用的性能监控接口，核心是启用并安全配置 stub_status 模块——它不依赖第三方工具，轻量、实时、原生支持，是运维最常用的状态入口。
启用 stub_status 接口
该模块必须在编译时已开启（主流发行版和源码编译默认包含），确认方式：nginx -V 2>&1 | grep -o with-http_stub_status_module。若无输出，需重新编译并添加 --with-http_stub_status_module 参数。
在 nginx.conf 的 http 块或某个 server 块内添加如下配置：
- 推荐放在本地回环 server 中，避免暴露公网：
server {<br> listen 127.0.0.1:80;<br> location /nginx_status {<br> stub_status on;<br> access_log off;<br> allow 127.0.0.1;<br> deny all;<br> }<br>} - 如需远程访问（例如监控系统拉取），可将
allow改为指定内网 IP 段，例如allow 10.0.0.0/24;，严禁开放allow all - 接口返回纯文本，无需 JSON 解析，直接 curl 即可获取原始指标：
curl http://127.0.0.1/nginx_status
理解返回指标含义
访问 /nginx_status 后会看到三行输出，每行代表一类关键状态：
- Active connections: 当前活跃连接总数（含 Reading/Writing/Waiting），反映瞬时并发压力
-
server accepts handled requests —— 三个累加值：
• 第一个数：Nginx 自启动以来接受的 TCP 连接总数
• 第二个数：成功处理的连接数（accepts ≥ handled，差值代表因资源不足被丢弃的连接）
• 第三个数：已处理的 HTTP 请求总数（一个连接可承载多个请求，尤其启用了 keepalive） -
Reading/Writing/Waiting —— 当前各阶段连接数：
• Reading：正在读取客户端请求头的连接数
• Writing：正在向客户端发送响应的连接数
• Waiting：已处理完请求、保持 keepalive 等待新请求的空闲连接数（即处于 idle 状态的连接）
配合日志与系统级指标协同观测
stub_status 提供的是“连接层”快照，要形成完整监控闭环，需结合其他数据源：
- 将
access_log格式设为main或自定义字段（含$status、$request_time、$upstream_response_time），便于统计错误率、慢请求、TOP 资源等 - Linux 下用
ss -s或netstat -an | grep :80 | wc -l验证实际 ESTABLISHED 连接数，与 Active connections 对比判断是否存在连接堆积 - Windows 环境可搭配 Perfmon，采集
\Process(nginx)\% Processor Time和\TCPv4\Connections Active，与 stub_status 时间点对齐分析 CPU 瓶颈是否由连接激增引发 - 定期检查
error.log的 warn/error 级别日志，常见如 “accept() failed (24: Too many open files)”，提示需同步调优系统文件句柄限制（ulimit -n和/etc/security/limits.conf）
验证与日常巡检建议
配置生效后务必验证，且纳入例行检查项：
- 执行
nginx -t确认语法无误，再nginx -s reload热重载 - 用
curl -I http://127.0.0.1/nginx_status检查返回状态码是否为 200，排除权限或防火墙拦截 - 写一个简单脚本每分钟抓取一次指标，记录到本地文件或推送至 Prometheus（通过 nginx-exporter 中转更佳）
- 重点关注
handled与accepts的差值持续增大，或Waiting长期接近worker_connections上限，这两者常是连接泄漏或后端响应延迟的早期信号
