WordPress 被 CC 攻击，最有效的止血动作是什么？

先开启全局 QPS 上限把服务保住，再按访问日志找出高频 IP 与被打的 URL，针对性地做单 IP 限流。不要一上来就封整个 IP 段，容易误伤真实访客。

开了防护插件之后正常访客会不会被误封？

取决于阈值设置。合理的做法是把「全局熔断」阈值设得较高（只在真正过载时触发），把「单 IP 限流」设得较细（按正常人类浏览频率的 3 到 5 倍），这样正常时段几乎不会误伤。

看三个维度：请求频率（正常爬虫有 crawl-delay 概念）、请求范围（正常爬虫会遍历全站，恶意爬虫只打搜索页和动态参数）、UA 与 IP 反查是否一致（伪造 UA 的爬虫，其 IP 反查结果与自称的身份对不上）。

如果防护逻辑放在 WordPress 内核加载之后，就起不了作用。要选在更早阶段就能拒绝请求的方案——全局 QPS 闸门应该在加载完整 PHP 应用之前生效，攻击流量不落地 PHP 才叫真防护。

检查后台用户列表是否有陌生管理员、wp-cron 是否有可疑定时任务、主题与插件目录是否有近期被改动的文件、以及数据库里是否出现陌生的 option 记录。发现任何一项都应按「已攻破」处理。

把「网站慢」笼统当成「被攻击」是最常见的误判。先看这三个指标，基本能定位方向：

如果已经出现陌生管理员账号或可疑的定时任务，说明不是「正在被攻击」而是「已经被攻破」。这时候先隔离（暂停站点或改数据库密码），再谈防护，顺序不能反。

命令行快速统计（把日志路径换成你自己的）：

很多安全插件的做法是「每来一个请求就判断一次规则」，这在高频攻击下本身就是负担：判断逻辑跑在 PHP 里，攻击流量依然会打到 PHP，站点照样会被拖垮。

更合理的结构是两层：

判断防护插件好不好用的一个标准：看它是否在「不加载 WordPress 完整内核」的阶段就能拒绝请求。如果所有判断都要走完 PHP 初始化，攻击量大时它自己也扛不住。

在所有业务逻辑之前设一个全站每秒请求数上限。超过阈值直接快速拒绝，不进入 WordPress 初始化流程。这一层的目的是「保命」——哪怕误伤一部分正常访客，也要先让服务器活下来。

针对单个 IP / 单会话做频率约束，并且阈值要能根据站点当下的压力动态调整。压力低时宽松，攻击时收紧。这样正常时段不会有误伤，攻击时段能自动加严。

知道攻击来自哪些地区不是为了「封整个地区」——那会误伤真实用户。它的实际用途是：

比较务实的组合是：源站做限流熔断（保证活下来）+ CDN 做前置过滤（减少无效流量）+ 隐藏源站 IP（防止被绕过）。三层各司其职。