vts 提供实时细粒度流量指标，需结合差分计算、多维聚合与基线比对识别异常流量，并联动日志分析、限流及防火墙实现闭环响应。
在 Nginx 中识别异常流量突发，关键不是单纯看总请求数，而是结合来源 IP、User-Agent、URI 模式、响应状态等维度做实时聚合与对比。Vhost-Traffic-Stat（简称 VTS）本身不直接检测“异常”，但它提供了高精度、低开销的按虚拟主机（vhost）、上游（upstream）、甚至按状态码/请求方法细分的实时流量指标，是构建异常流量感知体系的基础数据源。
启用 VTS 并暴露细粒度指标
VTS 的核心价值在于它把原本需日志分析才能获得的维度（如每个 server_name 下每秒 404 数、每个 upstream 的失败率）变成可实时抓取的 JSON 接口。务必开启以下配置：
- 在 http 块中加载模块：
load_module modules/ngx_http_vhost_traffic_status_module.so;（路径依编译方式而定） - 添加 vhost_traffic_status_zone 指令，例如：
vhost_traffic_status_zone;（使用默认共享内存区）或自定义大小：vhost_traffic_status_zone size=1m; - 配置一个专用 location 暴露指标，例如：
location /status { vhost_traffic_status_display; vhost_traffic_status_display_format json; } - 确保该 location 不被外部随意访问，建议加 IP 白名单或 basic auth
聚焦关键维度识别突发源头
直接看 /status 的全局汇总意义有限。要定位异常源，需主动拉取并解析其嵌套结构：
-
按 server_name 分组：检查哪个域名 QPS 突增（如
data.vhosts["api.example.com"].request.counter近 60 秒值 vs 历史基线） -
按 upstream 分组：若后端有多个集群（如
upstreams.backend-v1,upstreams.backend-v2），对比各组 active、5xx、response time 是否失衡 -
按 code 和 method 维度：突发大量
403或HEAD请求常指向扫描器；突增POST /login且 429 飙升可能为暴力破解 -
结合 request.time 和 bytes_sent：高 QPS 但平均
bytes_sent极低（如
用轻量脚本实现基线比对与告警
VTS 不带分析逻辑，需外部工具消费其 JSON。一个实用做法是用 Python + requests 每 30 秒抓一次 /status，缓存最近 10 分钟数据，计算滑动窗口标准差：
- 提取每个
vhosts.*.request.counter的增量（当前值 - 上次值），得到每 30 秒请求数 - 对每个 vhost 维护一个长度为 20 的队列，计算均值 μ 和标准差 σ
- 当新周期增量 > μ + 3σ，且该 vhost 的
codes.4xx或codes.5xx同步上升，则触发告警 - 进一步可关联
vhosts.*.upstreamZones.*.responses.5xx，确认是客户端问题还是后端崩了
与日志和限流联动提升响应能力
VTS 提供“发现”，后续动作需配合其他机制：
- 一旦发现某 vhost 的 UA 出现高频
sqlmap、nuclei字样（需在 log_format 中记录 $http_user_agent），可动态更新 geo 或 map 模块，将该 UA 前缀加入黑名单 - 对突发的特定 URI（如
/wp-login.php），用 limit_req_zone 基于 $binary_remote_addr + $request_uri 创建二级限流，避免误伤正常用户 - 将 VTS 中识别出的恶意 IP 段，同步写入 ipset，由 iptables 快速丢弃后续连接（绕过 Nginx 解析开销）
不复杂但容易忽略：VTS 的计数器是累计值，必须做差分才能得到速率；它的数据刷新频率取决于 Nginx worker 处理请求的节奏，不是严格定时，所以监控脚本要容忍小幅抖动。
