Cloudflare 通用防护目标（只用 Cloudflare，适配所有服务器）
该方案只在 Cloudflare 侧完成，不依赖服务器类型、面板或 root 权限，目标是：
- 不长期依赖 Under Attack（仅作为应急开关）
- 通过 WAF 规则把高频机器人/CC 流量挡在边缘
- 重点保护 WordPress 高风险入口（wp-login、admin-ajax、xmlrpc）
- 通过事件数据持续迭代规则，保持长期稳定
一、Cloudflare 基础前置（必须）
1. DNS 全部走代理（橙云）
- 网站主域名、www 以及对外访问的记录，全部开启 Proxied（橙云）
- 不保留任何灰云直连源站记录，避免绕过 Cloudflare 直打源站
2. 打开 Bot 相关防护
- Bot Fight Mode / Bot 防护相关开关开启
- 安全级别不建议设置过低
二、WAF 规则最佳顺序
以下规则建议按顺序创建（从'减少误伤'到'精准拦截'）：
规则的核心思想是：先放行可信流量 → 再统一拦截机器人 → 再保护高风险入口 → 最后黑名单补刀。
规则 1：白名单（管理员/公司网络/可信 IP）
名称：Whitelist Trusted IPs
匹配条件：管理员公网 IP（或固定办公网络 IP 段）
操作：Allow / Skip（跳过安全检查）
用途：避免管理员登录后台、发布内容时被反复质询，减少误伤。
规则 2：自动程序（已知自动程序 = true）托管质询
名称：Known Bots Challenge
匹配条件：cf.client.bot eq true
操作：托管质询（Managed Challenge）
用途：对 Cloudflare 能识别出的自动化流量进行挑战，快速削减机器人请求带来的压力。
说明：这是'救火效果很强'的通用策略。后续如果想更偏 SEO，可把此规则调整为 Allow/Skip，并把挑战重点放到高风险路径与限速策略上（可选优化，不是必需）。
规则 3：直接阻止 XML-RPC（强烈推荐）
名称：Block XML-RPC
匹配条件：http.request.uri.path eq "/xmlrpc.php"
操作：Block
用途：xmlrpc.php 是常见被刷入口之一，很多站点并不需要它，直接阻止最省心。
规则 4：wp-login 只挑战 POST（对正常访问影响更小）
名称：wp-login POST Managed Challenge
匹配条件：(http.request.uri.path eq "/wp-login.php" and http.request.method eq "POST")
操作：托管质询（Managed Challenge）
用途：只对登录提交动作挑战，既能挡暴力破解/脚本登录，又尽量不影响正常访问。
规则 5：admin-ajax 托管质询（防刷防拖死）
名称：admin-ajax Managed Challenge
匹配条件：http.request.uri.path eq "/wp-admin/admin-ajax.php"
操作：托管质询（Managed Challenge）
用途：大量机器人会刷 admin-ajax 触发 PHP/数据库高负载，用挑战显著减压。
（不建议直接 Block，避免误伤前台依赖 admin-ajax 的功能。）
规则 6：阻止指定恶意 User-Agent（模板规则，持续扩展）
名称：Block Bad User-Agents
匹配条件：把已确认的恶意 UA 逐条加入（OR 组合）
操作：Block
用途：对明确恶意工具/脚本直接封禁，减少重复攻击成本。
三、Rate Limiting（如果可用：效果会更稳）
如果套餐/控制台支持 Rate Limiting（限速），建议对以下路径加'每 IP 阈值'：
/wp-login.php（POST）：例如 10 次/分钟/IP → Challenge 或 Block/wp-admin/admin-ajax.php：例如 60 次/分钟/IP → Challenge- 搜索参数（如
?s=）：例如 30 次/分钟/IP → Challenge /wp-json/（如不依赖 REST）：例如 60 次/分钟/IP → Challenge
建议策略：先 Challenge 观察是否误伤，再逐步收紧到 Block。
四、Under Attack 模式的正确使用方式（应急按钮）
- 日常：保持 Under Attack 关闭
- 攻击峰值：临时开启 Under Attack 30–120 分钟救火
- 峰值过去：关闭 Under Attack，继续依赖上述精细规则长期运行
五、如何用 Cloudflare Events 持续迭代（只靠 Cloudflare 即可闭环）
该方案不需要服务器日志，长期维护只看 Cloudflare 侧数据即可：
- 观察命中最多的规则（确认主要压力来源）
- 看 Top 目标路径（URL）是否集中在 wp-login/admin-ajax/xmlrpc 或其他路径
- 看 Top 国家/ASN/UA（必要时新增更精确的挑战/阻止规则）
- 新出现的恶意 UA 进入'UA 黑名单'规则
- 新出现的高频路径进入'Managed Challenge + Rate Limit'组合
六、最终可复制的'规则清单'（直接用）
| 顺序 | 名称 | 匹配条件 | 操作 |
|---|---|---|---|
| 1 | 白名单可信 IP | ip.src in {trusted IPs} | Allow / Skip |
| 2 | 已知自动程序 | cf.client.bot eq true | Managed Challenge |
| 3 | 禁用 XML-RPC | path eq /xmlrpc.php | Block |
| 4 | wp-login 防爆破 | path eq /wp-login.php AND POST | Managed Challenge |
| 5 | admin-ajax 防刷 | path eq /wp-admin/admin-ajax.php | Managed Challenge |
| 6 | 恶意 UA 黑名单 | http.user_agent in {...} | Block |
| 7 | 限速（可选） | 登录/ajax/搜索/API | Challenge/Block |
FAQ（只给可执行结论）
1）为什么'已知自动程序=true'能显著降低负载？
因为大量压力来源本质是自动化访问，挑战后会被筛掉或降频，从而减少回源请求与动态计算压力。
2）只做 wp-login 和 admin-ajax 够吗？
通常不够。建议至少加上：已知自动程序挑战 + xmlrpc 阻止，必要时再上限速。
3）担心误伤怎么办？
先做三件事：
- 加白名单（自己 IP）
- wp-login 只挑战 POST
- admin-ajax 用 Challenge 不用 Block
然后通过 Events 观察真实影响，再逐步收紧策略。
结论
该解决方案完全在 Cloudflare 完成，适用于所有服务器环境：
通过'白名单 → 已知自动程序挑战 → xmlrpc 阻止 → wp-login/admin-ajax 保护 → UA 黑名单 →（可选）限速 → Under Attack 应急'这一套组合，可稳定解决网站被刷导致的 CPU/内存 100%、关闭 Under Attack 立刻变慢的问题，并且可通过 Cloudflare Events 持续迭代长期有效。