Nginx 本身不内置安全事件自动报警能力，需通过“日志分析 + 指标采集 + 外部告警系统”三级联动实现精准识别与实时通知：从 error.log 捕获 Connection refused、SSL_do_handshake() failed 等攻击信号；在 access.log 中匹配高频 403/404、敏感路径、恶意 UA；并用 Prometheus+Alertmanager 统一告警。
Nginx 本身不内置安全事件的自动报警能力，但可通过“日志分析 + 指标采集 + 外部告警系统”三级联动，实现对暴力扫描、恶意请求、配置异常等典型安全风险的精准识别与实时通知。关键不是堆功能，而是把日志和状态变成可判断的信号。
从错误日志中捕获真实攻击行为
Nginx 错误日志（/var/log/nginx/error.log）是安全监控的第一手信源，比访问日志更直接反映异常——比如连接被拒绝、上游不可达、SSL握手失败等。 - 开启 warn 或 error 级别日志：`error_log /var/log/nginx/error.log warn;`（避免 debug 级别产生海量无效日志） - 重点匹配以下关键词并触发告警：• `connect() failed (111: Connection refused)` → 后端服务宕机或端口未监听，可能被主动探测或已失陷
• `no live upstreams` 或 `upstream queue is full` → 负载过载或 max_conns 配置不合理，存在拒绝服务风险
• `client intended to send too large body` → 可能是文件上传攻击试探，结合 `client_max_body_size` 限制可交叉验证
• `SSL_do_handshake() failed` 或 `TLS alert write` → 异常 TLS 握手行为，常见于扫描器或中间人尝试
可用 filebeat + Elasticsearch 实时过滤，或用简单脚本每分钟 grep 统计频次：
grep -c "Connection refused" /var/log/nginx/error.log | awk '$1 > 5 {print "ALERT: Too many connection refusals"}'用访问日志识别高频恶意模式
访问日志虽不报错，但暴露大量攻击指纹。需在 `log_format` 中保留关键字段（如 `$status`, `$request`, `$http_user_agent`, `$remote_addr`），再做规则匹配： - 单 IP 在 1 分钟内触发 ≥20 次 403/404 → 可能是目录爆破或 SQLi/XSS 扫描 - 请求路径含 `phpinfo`, `wp-admin`, `.git/config`, `/etc/passwd` 等敏感字符串 → 明确攻击意图 - User-Agent 包含 `sqlmap`, `nmap`, `gobuster`, `dirsearch` → 工具化探测行为 - 非法 HTTP 方法（如 `PUT`, `DELETE`, `TRACE`）出现频次突增 → 可能绕过防护或准备漏洞利用建议用 logrotate 按小时切分日志，并配合轻量脚本定时分析（例如用 awk + sort + uniq -c），超过阈值即调用 curl 发送企业微信 webhook。
监控 Nginx 自身运行状态防配置失效
安全配置若未生效，等于形同虚设。需定期验证核心防护项是否处于激活状态： - 检查 `server_tokens off;` 是否生效：`curl -I https://yoursite.com | grep Server`，若返回 `nginx/1.22.0` 就说明没关 - 验证 `limit_req` 是否起作用：模拟高频请求（如 `for i in {1..10}; do curl -s -o /dev/null -w "%{http_code}\n" http://yoursite.com/; done`），观察是否稳定返回 503 - 确认 `stub_status` 已启用且可访问：`curl http://localhost/nginx_status`，若失败则监控链断裂 - 检查 SSL 协议版本：`openssl s_client -connect yoursite.com:443 -tls1_1 2>/dev/null | grep "Verify return code"`，返回非零说明 TLS 1.1 被拒，符合安全策略这类检查可写成 shell 脚本，每天 cron 执行一次，失败时发邮件或钉钉提醒。
对接 Prometheus + Alertmanager 做统一告警中枢
当环境规模上升，建议收敛到专业可观测体系： - 部署 nginx-prometheus-exporter，将 stub_status 和自定义指标（如 4xx/5xx 错误率、恶意 UA 计数）暴露给 Prometheus - 在 Prometheus 中配置 recording rules，例如： ```yaml groups: - name: nginx-security-rules rules: - record: nginx:bad_requests_per_ip:rate5m expr: sum by (ip) (rate(nginx_http_request_total{status=~"4..|5.."}[5m])) > 10 ``` - 在 Alertmanager 中设置通知路由，按严重等级分流：高危（如 503 突增）发短信+电话，中危（如扫描行为）仅推钉钉群这种方式支持去重、静默、分级响应，避免告警疲劳，也便于后续关联分析（比如某 IP 触发 403 后又出现大量 503，可能是攻击后导致后端崩溃）。
不复杂但容易忽略
