Nginx stub_status 是开箱即用的实时健康仪表盘，启用后可通过 /nginx_status 查看 Active connections、accepts、handled、requests 及 Reading/Writing/Waiting 等关键指标，结合趋势分析和监控集成可提前发现服务异常。
直接上干货：Nginx 的 stub_status 不是摆设，它是一套开箱即用的实时健康仪表盘。只要正确开启并理解每行输出的含义，你就能在服务异常前发现苗头，而不是等用户投诉才去查日志。
怎么打开 Status 页面
这个模块默认编译进大多数 Nginx 安装包（可用 nginx -V 2>&1 | grep -o with-http_stub_status_module 验证），无需额外安装。只需在 server 或 http 块中加一段配置：
- 推荐路径：
location /nginx_status { stub_status on; access_log off; allow 127.0.0.1; deny all; } - 生产环境务必限制访问 IP，比如只允许监控服务器或内网运维机访问
- 如需公网临时调试，可加
auth_basic "Restricted"; auth_basic_user_file /etc/nginx/.htpasswd; - 改完执行
nginx -s reload生效，然后 curl http://localhost/nginx_status 就能看到原始数据
Status 输出字段逐行解读
访问后返回类似这样的纯文本：
server accepts handled requests
16630948 16630948 31070465
Reading: 5 Writing: 179 Waiting: 107
- Active connections：当前 TCP 连接总数（ESTABLISHED + SYN-ACK 等），不是并发请求数。持续高于 worker_connections 的 70% 就该警惕
- accepts：Nginx 自启动以来接受的总连接数；handled：成功处理的连接数。二者相等说明没发生连接丢弃；若 handled 明显小于 accepts，可能是 worker 过载或主动拒绝连接
- requests：已处理的 HTTP 请求总数。用它除以时间可算 QPS，再结合响应时间判断吞吐是否达标
- Reading：正在读取客户端请求头的连接数（通常极小，>5 可能说明前端发包慢或网络延迟高）
- Writing：正向客户端发送响应的连接数（高峰期正常偏高，但长期 >80% 说明后端响应慢或带宽打满）
- Waiting：已处理完请求、保持长连接等待新请求的空闲连接数（Keep-Alive 连接）。这个值高是好事，说明复用充分；但如果 Active connections 居高不下而 Waiting 占比低，可能连接没及时释放
从数字里看出问题苗头
单看一次输出意义有限，关键在于趋势和组合判断：
- Active connections 持续上涨 + Waiting 比例下降 → 可能后端响应变慢，连接堆积
- Writing 长期接近或等于 Active connections → 所有连接都在发数据，大概率是响应体过大或带宽瓶颈
- accepts 增长但 requests 几乎不涨 → 大量连接建立后没发请求（SYN Flood？或客户端异常断连）
- requests 增速远低于流量增长 → 可能大量静态资源走 CDN，或存在大量 304/206 分块响应
让 Status 真正发挥作用
别只靠浏览器刷新看一眼。把它接入日常运维闭环：
- 用 curl + shell 脚本每 10 秒抓一次数据，写入本地时间序列文件，画趋势图
- Python 脚本解析后推送到 Prometheus（配合 nginx-vts-exporter 更佳），设置告警规则，比如 “Active connections > 90% worker_connections 持续 2 分钟”
- 结合 upstream 模块状态（需启用 ngx_http_upstream_module），当某台后端的失败连接数突增，自动触发下线脚本
- 把 /nginx_status 加到健康检查探针里，作为负载均衡器或 Kubernetes readiness probe 的依据
