Nginx 是监控高防效果的关键观测点，需重点分析清洗后残留异常流量、自身防护拦截指标、高防日志交叉比对及业务可用性基线。
Nginx 本身不直接执行大规模流量清洗（那是专业抗 DDoS 清洗设备或云高防服务的职责），但它作为七层网关，能精准感知和统计被清洗后到达自身的“残余攻击流量”与“合法业务流量”，是监控高防效果的关键观测点。重点不是看清洗设备吞了多少 Gbps，而是看 Nginx 是否收到了不该来的请求、是否触发了防护策略、是否影响了真实用户。
监控清洗后的入口流量特征
高防服务通常将清洗后的流量回注到源站（如 Nginx）。此时应重点关注 Nginx 日志中清洗“残留”的异常模式：
- 统计单位时间内 403、429、503 响应码比例突增——说明高防可能未完全过滤干净，Nginx 正在用限流/封禁兜底
- 对比清洗前后同一时段的 总请求数、平均响应时间、错误率（需高防提供清洗前原始镜像日志或 API 数据）
- 检查 User-Agent、Referer、URI 路径分布是否异常集中，例如大量请求指向 /login 或 /api/v1/submit 且无合理 Referer，可能是 CC 攻击绕过清洗的迹象
跟踪 Nginx 自身防护模块的拦截指标
如果你在 Nginx 层配置了限流、连接限制或 IP 黑名单，这些动作本身就是清洗效果的延伸验证：
- 启用 limit_req_log_level warn 和 limit_conn_log_level warn，在 error.log 中捕获被拒绝的请求详情
- 用 log_format 定制日志字段，记录 $limit_req_status（空=放行，"rejected"=被限流，"delayed"=排队） 和 $limit_conn_status
- 通过 Prometheus + nginx-vts-exporter 或 nginx-module-vts 暴露指标：
nginx_http_request_limit_rejected_total、nginx_http_connection_limit_dropped_total，设置告警阈值（如每分钟拦截超 500 次持续 2 分钟）
关联高防服务的清洗日志做交叉分析
真正有效的监控必须打通高防侧数据。多数云厂商（如阿里云、腾讯云、Cloudflare）提供清洗日志 API 或 SLS/CLS 接入能力：
- 提取高防日志中的 清洗丢弃量（Drop）、重定向量（Redirect）、透传量（Pass），与 Nginx 实际收到的请求量比对：若 Pass 量为 10 万 QPS，但 Nginx 只处理了 8 万，则差额可能意味着网络抖动或 Nginx 自身瓶颈
- 将高防标记的攻击源 IP 段（如 ASN、地理区域）与 Nginx access.log 中高频访问 IP 做交集，验证黑名单同步是否及时
- 关注高防报告中的 攻击类型分布（如 HTTP Flood 占比 72%），再检查 Nginx 的 limit_req_zone 是否针对 /api/ 等路径做了差异化限速
建立业务可用性基线作为最终标尺
所有技术指标都服务于业务。清洗是否有效，最终看用户能不能用：
- 监控核心接口（如首页、下单、支付回调）的 成功率、P95 延迟、首字节时间（TTFB），攻击期间波动不应超过日常均值的 ±20%
- 对比攻击前后同一用户群（如 Cookie 或 Device ID 标识）的 会话留存率、页面跳出率，若清洗后跳出率飙升，可能是误杀正常流量
- 设置 “清洗中” 状态页健康检查：当高防切换至清洗模式时，自动触发对 /healthz 的探测，确认 Nginx 仍可响应且返回 200
