Nginx安全监控与应急预案体系需实现主动防御与快速闭环，覆盖网络层、应用层、进程层、系统层四层监控，并明确自动限流、IP封禁、服务重启三类可执行应急动作。
建立 Nginx 安全监控与应急预案体系，核心是把“被动响应”转为“主动防御+快速闭环”。不能只靠告警邮件来了再查日志，而要围绕攻击链（探测→尝试→突破→横向）预设检测点、固化处置动作、量化恢复能力。
一、安全监控必须覆盖的四个关键层
监控若只看连接数或 502 错误，会漏掉真实威胁。需分层采集并关联分析：
-
网络层：用
iftop或netstat -anp | grep :80实时识别单 IP 连接数突增（如 >200）、大量 SYN_RECV 状态——可能是慢速攻击或扫描行为 -
应用层：通过 Nginx
access.log提取高频异常请求，例如：tail -n 5000 /var/log/nginx/access.log | awk '$9 ~ /^(499|502|504)$/ {print $1}' | sort | uniq -c | sort -nr | head -10
重点关注返回 499（客户端主动断连）且来自同一 IP 的密集请求，常为 CC 攻击特征 -
进程层：监控
ps aux --sort=-%cpu | grep nginx，若某 worker 持续占 CPU >90%，结合strace -p [pid]可判断是否陷入正则回溯或死循环 -
系统层：用
dmesg -T | grep -i "killed process"检查 OOM 杀死记录；journalctl -u nginx --since "2 hours ago" | grep -i "segmentation\|core"排查段错误崩溃
二、应急预案要明确三类动作触发条件
预案不是文档，是可执行的指令集。每类动作必须绑定清晰、自动可判的触发信号：
-
自动限流：当 Prometheus 抓取到
nginx_http_requests_total{code=~"4.."} / nginx_http_requests_total > 0.3（4xx 错误率超 30%）且持续 2 分钟，立即在 Nginx 配置中启用limit_req并 reload -
IP 封禁：脚本每 5 分钟解析 access.log，对 1 分钟内请求 ≥ 300 次且含
/wp-login.php、等敏感路径的 IP，写入 <code>/etc/nginx/conf.d/block.conf并nginx -s reload -
服务降级：当后端健康检查失败节点数 ≥ 总 upstream 数的 50%，自动切换至静态维护页（
error_page 502 503 504 /maintenance.html），避免雪崩
三、演练必须验证两个硬性指标
没经过真实故障检验的预案等于没有。每次演练后必须记录并改进：
- MTTD（平均检测时间）≤ 90 秒：从攻击发生到监控系统发出首条高危告警的时间。若超时，需优化日志采集延迟或告警规则灵敏度
- MTRA（平均响应时效）≤ 3 分钟：从告警触发到限流/封禁/降级动作完成、业务恢复正常的时间。若超时，检查 reload 是否阻塞、配置语法是否频繁出错
四、闭环复盘的关键动作
每次事件或演练后，必须完成三项输出：
- 更新
geo黑名单配置，将本次确认的恶意 IP 段固化写入 - 检查
error.log中重复出现的 warning（如 “upstream timed out”），针对性调大proxy_read_timeout或增加重试 - 归档本次攻击的 UA、Referer、请求路径特征，加入 WAF 规则或 Nginx
if判断做前置拦截
