nginx 无内置安全监控报表，但可通过健康检查、状态暴露、日志审计与可视化模块构建可观测闭环；需配置主动探测应用层健康接口、暴露结构化状态页、嵌入响应码/延迟/安全头等安全维度，并生成节点健康、异常响应、安全头合规三类日报。
配置主动健康检查，确保节点真实可用
仅靠连接通断（如 max_fails）无法识别应用层异常（比如服务假死、/health 返回 200 但业务已卡住）。必须对接后端真实状态接口：
- 使用
nginx_upstream_check_module（推荐编译进 OpenResty 或自定义 Nginx），在upstream中明确探测路径和语义规则：
upstream app_cluster {
server 10.0.1.10:8080;
server 10.0.1.11:8080;
check interval=5 rise=2 fall=3 timeout=2 type=http;
check_http_send "GET /actuator/health HTTP/1.1\r\nHost: localhost\r\n\r\n";
check_http_expect_alive http_2xx;
}
说明：每 5 秒发一次 GET 请求；连续 2 次收到 2xx 才恢复上线，连续 3 次失败才下线；超时严格设为 2 秒，避免拖慢整体响应。
暴露结构化健康状态页，供人查与程序采
不要只依赖命令行或日志翻找。应提供统一、机器可读的状态入口：
- 启用
vhost_traffic_status（VTS 模块）或ngx_http_upstream_jdomain_module，它们能直接输出 JSON/HTML 格式，含每个后端的active、fails、down、status等字段； - 若不想引入第三方模块，可用最小成本复用 Nginx 自带能力：
→ 开启stub_status查整体连接情况；
→ 配合自定义日志格式记录 upstream 响应码（$upstream_http_content_type、$upstream_status），再用脚本聚合分析；
示例 VTS 配置：
location /status {
vhost_traffic_status_display;
vhost_traffic_status_display_format html;
allow 127.0.0.1;
allow 10.10.0.0/16;
deny all;
}
访问 /status 即得表格化集群视图，含实时活跃连接、请求速率、各 backend 的健康标记（✅/❌）及失败计数。
嵌入安全维度：响应码、延迟、异常头检测
真正的安全监控需识别非崩溃类风险，例如：
- 后端返回大量 401/403（疑似认证绕过或权限配置错误）；
- 平均响应时间突增（可能遭遇慢速攻击或资源耗尽）；
- 响应头中缺失
Content-Security-Policy或含危险字段（如X-Powered-By: PHP/5.2）；
实现方式：
- 在
log_format中加入$upstream_response_time、$upstream_status、$upstream_http_x_powered_by等变量； - 用
map指令标记高危响应（如map $upstream_status $is_suspicious { ~^[45] 1; default 0; }），再通过日志过滤或 Prometheus exporter 抓取； - 配合 Lua 脚本（OpenResty）在响应阶段做 header 审计，记录违规行为到独立日志文件。
生成可落地的安全监控报表
报表不是炫技，要能驱动动作。建议每日自动生成三类简明摘要（可用 cron + shell + awk 实现）：
-
节点健康日报：列出过去 24 小时内被标记
down超过 3 次的后端，附首次/末次 down 时间； -
异常响应TOP5：统计 4xx/5xx 响应占比、高频路径（如
/login出现 95% 的 401）、平均延迟增幅； -
安全头合规清单：检查各 backend 是否返回
Strict-Transport-Security、X-Content-Type-Options等关键头，标出缺失项。
这些结果可邮件发送、写入 Markdown 文件托管在内部 Wiki，或接入 Grafana 作为看板基础数据源。
