stub_status仅支持server或根路径location配置，无法按业务路径隔离统计；应使用log_format+access_log实现模块粒度日志记录，或选用nginx-module-vts等增强模块进行可视化监控。
直接在 location 块中启用 stub_status 是不可行的，因为 stub_status 是 Nginx 的内置模块（ngx_http_stub_status_module）提供的一个**全局状态接口**，它只能配置在 server 或 location /（且路径必须为 / 或以 / 开头的精确匹配）下，不支持按业务路径做“统计隔离”，也不能绑定到某个具体业务模块的 location 中。
stub_status 本身只提供基础连接和请求计数
stub_status 输出的是整个 worker 进程或 server 级别的聚合指标，例如：
- Active connections：当前活跃连接数
- server accepts handled requests：接受/处理/请求总数（累计值）
- Reading/Writing/Waiting：各阶段连接数
它**不区分 URI、不按 location 分组、不支持标签化统计**，因此无法直接用于“某个业务模块（如 /api/order）的请求量”监控。
替代方案：用 log\_format + access\_log 实现业务模块粒度统计
要统计特定业务模块（如 /api/user、/v2/pay）的请求量，推荐使用 Nginx 日志结合条件记录的方式：
- 定义带模块标识的
log_format，例如在http块中：
log_format module_log '$remote_addr - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent" '
'module="$module_tag";- 在对应业务
location中设置变量并启用独立日志：
location ^~ /api/user/ {
set $module_tag "user_api";
access_log /var/log/nginx/user_api.log module_log;
proxy_pass http://backend_user;
}这样所有匹配该 location 的请求都会写入专属日志文件，后续可用 awk、goaccess 或接入 Prometheus（配合 nginxlog_exporter）做实时聚合统计。
进阶：用 nginx-module-vts 实现可视化模块级监控
如果需要类似 stub_status 的实时页面，但支持按 location / upstream 分组，可编译安装第三方模块 nginx-module-vts：
- 启用后可通过
location /status查看每个upstream或server的请求数、响应时间、状态码分布 - 配合
map指令将 URI 映射为 upstream 名称，即可间接实现“模块维度”统计 - 支持 JSON 接口，便于对接 Grafana/Prometheus
小结：stub_status 不是业务监控工具
stub_status 适合快速查看 Nginx 自身运行健康状况，比如是否积压连接、QPS 是否突增；但业务层的请求量统计，必须依赖日志分析或增强型监控模块。别试图把它“塞进某个 location”去实现业务隔离——Nginx 架构上就不支持这种用法。
