Nginx的stub_status模块无法按域名统计，仅提供worker进程级全局指标；可在server块中配置location=/nginx-status安全暴露整体状态，推荐用nginx-module-vts实现原生vhost维度监控。
Nginx 的 stub_status 模块不能真正“绑定到某个 Virtual Host 并只统计该域名的流量”，因为它统计的是整个 worker 进程级别的全局指标，与 server_name 或 $host 无关。但你可以在某个 server 块中安全暴露 /nginx-status 接口，用于监控该 Nginx 实例的整体运行状态——这是生产中最常用、最稳妥的做法。
✅ 在 Virtual Host 中启用 stub_status 接口
只需在目标 server 块内添加一个专用 location，例如：
server {
listen 80;
server_name example.com;
# 其他业务配置（root、proxy_pass 等）...
location = /nginx-status {
stub_status on;
access_log off;
allow 127.0.0.1;
allow 10.10.20.50; # 监控服务器 IP
deny all;
}
}- 使用
=精确匹配路径，避免被其他location规则覆盖 -
access_log off防止状态页访问刷爆日志 -
allow/deny必须成对出现，严禁留空或写allow all - 重启生效：
nginx -s reload
访问 http://example.com/nginx-status 即可看到三行文本输出，例如：
Active connections: 42 server accepts handled requests 123456 123456 654321 Reading: 0 Writing: 3 Waiting: 39
? 各字段含义要清楚
-
Active connections：当前所有活跃连接总数（含 Reading/Writing/Waiting） -
accepts：Nginx 启动以来接受的 TCP 连接总数 -
handled：成功处理并关闭的连接数（等于或略小于 accepts） -
requests：实际处理的 HTTP 请求总数（一个连接可发多个请求） -
Reading：正在读取请求头的连接数 -
Writing：正在向客户端发送响应的连接数 -
Waiting：keep-alive 空闲连接数（仅当keepalive_timeout启用时非零）
这些值全部是进程级累加值，不是按域名切分的。
⚠️ 为什么不能按域名独立统计？
-
stub_status是模块级功能，不识别server_name、$host或任何变量 - 所有
server块共享同一个 worker 进程的共享内存统计数据 - 即使你在多个
server块里都配了/nginx-status，返回的数据也完全一样
所以：
❌ 无法通过修改 server 块配置让 stub_status 只统计某个域名
✅ 但可以为不同域名部署独立 Nginx 实例（监听不同端口或用户），各自启用 stub_status
? 更实用的替代方案（推荐）
如果确实需要按域名维度监控：
优先选用
nginx-module-vts
它原生支持vhost_traffic_status on;，自动按server_name统计请求数、响应码、响应时间等，并提供 JSON 和 HTML 页面。配置简单，适合生产环境。结合 access_log + 脚本聚合
开启log_format记录$host $request_time $status，再用awk或 Python 按域名提取趋势数据（适合离线分析或低频统计）。拆实例隔离
关键业务单独跑一个 Nginx 实例（不同pid、conf、user），彻底物理隔离指标来源。
? 安全提醒（必须做）
- 切勿将
/nginx-status暴露在公网，它不支持认证，仅靠 IP 白名单防护 - 不要用
/status、/nginx_status等常见路径，改用_nxs、/healthz等非标准路径降低扫描风险 - 若需人工查看，建议走反向代理 +
auth_basic（如auth_basic "Nginx Status"）加固
不复杂但容易忽略。
