stub_status模块默认已静态编译但需手动配置启用，仅提供基础连接与请求计数，不支持4XX状态码分类；定位4XX需结合自定义log_format与tail+awk实时解析日志。
确认 stub_status 模块是否已启用
绝大多数预编译的 Nginx 二进制包（如 Ubuntu 官方源、CentOS 的 EPEL）默认已静态编译 ngx_http_stub_status_module，但不会自动暴露接口。你需要先验证模块存在：运行 nginx -V 2>&1 | grep -o with-http_stub_status_module，有输出即表示支持。若无输出，说明当前 Nginx 编译时未启用该模块，无法通过配置启用——必须重编译或换用含该模块的发行版（如 nginx.org 官方包）。
配置 stub_status 接口并限制访问范围
该模块只提供基础连接与请求计数（Active connections、server accepts handled requests、Reading/Writing/Waiting），**不包含任何状态码分类数据**，更不区分 4XX。所以直接靠 stub_status 是无法获取 4XX 分布的。你真正需要的是结合 log_format + 实时日志解析，而 stub_status 在这里仅能辅助判断整体请求压力是否异常升高。
典型安全配置示例：
location /nginx-status {
stub_status;
allow 127.0.0.1;
allow 10.0.0.0/8; # 仅允许内网监控机访问
deny all;
}
注意：stub_status 必须位于 location 块内，不能写在 server 或 http 级；且不支持 HTTPS 重定向（它本身无协议感知），若需 HTTPS 访问，确保前端 TLS 终止后流量以 HTTP 到达 Nginx。
用 log_format 提取 4XX 请求并配合 tail + awk 实时统计
要实时看 4XX 分布（比如哪个 URI 导致最多 404、哪个客户端 IP 频繁触发 403），核心是自定义日志格式，把 $status 和关键字段（$request_uri、$remote_addr、$http_user_agent）显式记录，再用流式工具分析。
在 http 块中添加：
log_format detailed_4xx '$status $request_uri $remote_addr "$http_user_agent"'; access_log /var/log/nginx/access.log detailed_4xx;
然后执行实时过滤（需确保日志已滚动且权限可读）：
tail -n 0 -f /var/log/nginx/access.log | awk '$1 ~ /^4[0-9]{2}$/ {count[$1" "$2]++} END {for (i in count) print count[i], i}' | sort -nr
-
$1 ~ /^4[0-9]{2}$/精确匹配所有 4XX 状态码（排除 4000、40000 等非法值） -
count[$1" "$2]按“状态码+URI”聚合，比单纯看状态码更有定位价值 - 该命令无 END 就不会输出——实际应去掉
END，改用{print count[$1" "$2], $1, $2}并加sort -nr | head -20实现持续 top20
为什么不用第三方模块（如 nginx-module-vts）？
像 nginx-module-vts 确实能展示按状态码分组的实时请求数，但它依赖共享内存，统计窗口是周期性采样（默认 1s），**对突发性 4XX 尖峰存在延迟和丢失风险**；且它的“4XX”是总和，不拆解具体 400/403/404/429 类型。真正要定位异常分布，原始日志 + 流式处理仍是更可靠的选择——尤其当你要关联时间戳、IP 地段、User-Agent 特征时，模块提供的维度太窄。
另外，vts 的 JSON 接口返回体积大，高频轮询可能反成 Nginx 负担；而 stub_status 本身无状态、零计算开销，仅适合做“有没有问题”的快速探针，不是“什么问题”的诊断工具。
