打开你自己的 Cloudflare 后台，先别急着看性能面板。去 Security → Bots 的流量视图里待两分钟，你会看到一组让人疑惑的曲线：明明产品没有迎来新用户，请求量却一直不低；UV 没变，但某几个页面每天都有规律的“访问”；回源日志里出现一堆你从没听过的 User-Agent：GPTBot、ClaudeBot、PerplexityBot、Bytespider、CCBot。
如果你有这种感觉，说明你的站点正在被 AI 爬虫高频扫描。这不是个别现象。随着大模型训练、检索增强生成（RAG）、AI 搜索 Agent 在 2024 年到 2025 年快速铺开，几乎所有可被公开访问的网页都成了候选语料。Cloudflare 作为全球流量入口之一，是观察这一现象最直观的窗口。比流量压力更麻烦的是数据失真：当 Bot 请求混入正常访问，转化率、留存率、页面停留时间这些运营指标都会变得不可信。
所以，这篇文章讨论的 “AI Psychosis” 不是危言耸听。它指的是：AI 内容抓取行为正在变得疯狂，同时网站流量数据也开始出现幻觉。不是 AI 在胡言乱语，而是我们对自己网站的认知开始失真。本文会给你一套可落地的 Cloudflare 防护方案，包括后台操作路径、WAF 规则表达式、API 批量更新脚本和 Workers 兜底拦截代码，让你在半小时内把常见 AI 爬虫挡在边缘层，同时尽量不误伤真实用户和搜索引擎收录。
1. AI 爬虫正在改写网站流量结构
1.1 问题不是“爬虫变多”，而是“流量不再等于人”
传统网站运维里，爬虫并不是新鲜事。搜索引擎爬虫会定期来抓取页面，做收录和排名；监控系统会模拟访问来探测可用性；SEO 工具会批量拉取标题和描述。这些流量虽然不产生转化，但量级可控，User-Agent 明确，运维人员早就习惯了把它们从业务报表里剔除。
AI 爬虫不一样。它们来自大模型公司或 AI 搜索平台的抓取集群，行为更像大规模扫描器：请求频率高、遍历路径深、不关心页面渲染，却会把每个可访问的 URL 都拉一遍。更麻烦的是，部分 AI 爬虫并不会严格尊重 robots.txt，甚至会出现临时更换 User-Agent 的情况。如果你只依赖传统日志分析，很难第一时间发现自己正在被哪个模型“阅读”。
当你打开 Cloudflare 的 Bots 分析页面时，最直观的感受往往是：真实浏览器请求的占比比你想象的低。真正吃掉服务器资源、推高带宽成本、制造大量无效日志的，很可能是那些你没听说过的 UA。这种流量结构的变化，正在悄悄改写网站运营的基本假设：PV 高，不一定意味着用户多；某个接口请求暴涨，可能只是某个 AI Agent 在抓取知识库。
1.2 AI 爬虫和搜索引擎爬虫的行为差异
传统搜索引擎爬虫与 AI 爬虫的核心差异，并不是“抓不抓”，而是“怎么抓”和“抓来做什么”。搜索引擎爬虫的目标是建立索引，给搜索用户返回链接；AI 爬虫的目标是获取文本和结构化内容，用以训练模型或补充 Agent 的知识上下文。目标不同，行为模式自然不同。
| 对比维度 | 搜索引擎爬虫 | AI 爬虫 |
|---|---|---|
| User-Agent | 一般明确，如 Googlebot、Bingbot | 部分明确，部分伪装成普通浏览器或搜索引擎 |
| 请求节奏 | 相对规律，有配额约束 | 频率高，可能短时间内遍历整站 |
| robots.txt 遵守 | 多数会遵守 | 部分不遵守，或仅作为弱参考 |
| 抓取范围 | 按搜索策略选择页面 | 常常全站覆盖，包括 API、历史页面、静态资源 |
| 是否渲染 JS | 部分支持 | 很多不渲染，但会提取 HTML 和接口文本 |
| 主要目的 | 做搜索索引 | 训练数据、知识库、Agent 信息检索 |
从这张表能看出，AI 爬虫比传统爬虫更难对付。它不一定遵守 robots.txt，不一定会暴露自己的身份，也不一定只抓“应该被抓”的页面。这要求你在 CDN 或 WAF 层面做强制约束，而不是依赖对方的自觉。
1.3 为什么说这是 Cloudflare 语境下的 “AI Psychosis”
“Psychosis” 这个词听起来很重，但它恰好能描述当前站点运营者面临的双重困境。第一重，是 AI 公司之间的数据竞赛。大模型需要持续更新的语料，AI 搜索需要实时抓取网页问答，于是各家爬虫的扫描频率不断上升，甚至出现同一时间多个 Agent 并发抓取的情况。这种行为已经超出了传统互联网“爬虫与反爬”的平衡预期，看起来确实有些疯狂。
第二重，是流量数据的失真。当一个站点开始被 AI 爬虫高频访问，页面浏览量、独立访客、停留时长、接口错误率这些指标都会失去参考意义。你可能会因为一个页面请求量突然上涨而投入更多资源，结果发现那只是某个 Agent 把页面当训练语料拉了一遍；你也可能因为误判用户行为，做出错误的内容策略。这种“对真实流量失去把握”的状态，也是一种幻觉式的运营认知。
理解这两重含义之后，你就明白为什么本文要强调可配置、可验证、可回滚的防护方案。Cloudflare 的价值不在于拦截本身，而在于它位于流量入口，能统一观察、分类和处置这些“非人类流量”。
2. Cloudflare 能做什么：Bot 管理与 AI 爬虫识别
2.1 Cloudflare 在请求链路中扮演什么角色
当域名接入 Cloudflare 并开启橙色云朵状态后，所有 HTTP/HTTPS 请求都会先经过 Cloudflare 边缘节点，再由边缘转发到你的源站。这个链路位置决定了 Cloudflare 可以在请求到达业务服务器之前，完成 TLS 指纹识别、User-Agent 分析、IP 信誉查询、行为频率统计等一系列动作。
与源站自行拦截相比，Cloudflare 边缘拦截有两点优势。第一，拦截发生在网络入口，消耗的是 Cloudflare 的资源，而不是你的服务器资源；第二，Cloudflare 能看到跨站点的威胁情报，比如某个 IP 是否同时在抓取大量其他网站，这种信息是单体业务服务器很难获取的。因此，把 AI 爬虫防护放在 Cloudflare 层，比只写一个 Nginx 拦截规则更高效。
2.2 四类关键能力：Bot Score、Verified Bot、Managed Rules、WAF
Cloudflare 的机器人防护能力可以拆成四层理解。
第一层是 Bot Score。Cloudflare 会为每个请求计算一个 1 到 99 的分数，分数越低，是机器人的概率越高。你可以把分数作为自定义规则的条件，比如对分数低于 30 的请求执行 Managed Challenge。在企业版的 Bot Management 中，这个分数可以按产品线、按路径精细化使用。
第二层是 Verified Bot。Cloudflare 维护了一份公开爬虫白名单，包括 Googlebot、Bingbot 等主流搜索引擎爬虫。这类请求经过验证，误判概率低。AI 爬虫很多不在白名单内，但要注意：不在白名单并不代表一定恶意，只是没有得到认证。
第三层是 Managed Rules。这里有一组由 Cloudflare 维护的托管规则，其中包含对常见 AI 爬虫的识别逻辑。你可以在 Security → Bots 页面找到入口，把对应规则从“观察”改成“挑战”或“阻断”。托管规则的优点是免维护，Cloudflare 会持续更新规则特征。
第四层是 WAF 自定义规则。这是最灵活的一层，你可以基于 User-Agent、IP 地址、ASN、国家地区等条件写表达式，完全控制动作和优先级。对于已知 UA，自定义规则是最直接的拦截方式；对于伪装 UA，则需要结合 Bot Score 或 ASN 判断。
2.3 正确姿势：分层处理而不是一刀切
很多人在配置 Bot 防护时，习惯把动作直接设成 Block，结果第二天发现有真实用户被误伤。更稳妥的思路是分层处理：先用观察模式看清流量，再对高风险流量执行 Managed Challenge，最后才收紧为 Block。
具体来说，可以把流量分成四类：已验证的搜索引擎爬虫，放行并单独监控；明确已知的 AI 爬虫 UA，直接阻断；行为像 bot 但未被验证的请求，执行 Managed Challenge；正常浏览器请求，无感放行。这个分层逻辑适用于免费版到企业版的大多数场景，也是本文后面配置流程的核心思路。
3. 环境准备与前置条件
3.1 需要准备什么
配置 Cloudflare 防护并不复杂，但需要满足几个基础条件。
第一，你需要一个 Cloudflare 账号，并且把域名接入到 Cloudflare 中。接入的关键是域名 DNS 记录的代理状态必须为“已代理”，也就是橙色云朵开启状态。如果 DNS 记录是灰色云朵，请求不会经过 Cloudflare，后台配置的所有 Bot 规则都不会生效。
第二，你需要有访问 Cloudflare 控制台的权限。如果团队协作环境中你只有查看权限，建议先让管理员为你的账号开通 Zone 的 WAF 和 Rulesets 编辑权限。若后续要使用 API 批量配置，还需要准备一个 API Token，权限范围选择 Zone → WAF / Rulesets → Edit。
第三，准备一个测试页面或非生产环境。你可以在某个子域名上先配置规则，观察是否误伤，再推广到主力域名。对任何涉及“拦截请求”的变更，都应该先小范围验证，这比事后回滚更容易。
3.2 版本与界面差异说明
Cloudflare 控制台界面会持续改版，不同套餐看到的功能入口也可能不同。免费版一般可以使用 Bot Fight Mode、Super Bot Fight Mode 和 WAF 自定义规则；企业版则有更完整的 Bot Management 分析界面，能看到更细的 Bot Score 分布和 AI Scraper 分类。本文以通用操作路径为主，具体按钮名称以你账号后台实际显示为准。
另外，请先确认你的 API Token 没有使用全局 API Key。最小权限原则在这里很重要：一个只具备单个 Zone WAF 编辑权限的 Token，足够完成本文演示的规则更新，不需要也不能使用账户级全局密钥。
3.3 重要提醒：先验证，再上线
在任何生产环境变更前，建议先完成三件事：记录当前流量基线，导出当前 WAF 规则列表，准备一个紧急回滚开关。Cloudflare 的每条自定义规则都有“启用/暂停”开关，遇到误伤时可以一键暂停，不需要删除整个配置。这篇文章的核心建议是：把每一次防护变更当成一次灰度发布来对待。
4. 核心流程拆解：如何在 Cloudflare 后台拦截 AI 爬虫
4.1 第一步：确认你正在被哪些爬虫访问
登录 Cloudflare 控制台，进入对应域名，打开 Security → Bots 页面。在流量分析中，你可以看到“Bot 请求”和“人类请求”的占比，以及被识别为机器人流量的趋势。如果想更具体地确认是哪些 AI 爬虫，可以进入安全事件或 Bots 的 Top User-Agent 视图，搜索 GPTBot、ClaudeBot、PerplexityBot、Bytespider、CCBot、Google-Extended 等关键词。
这一步的目的是“看见问题”。如果你发现某些 AI 爬虫已经每天在扫你的站点，再进入下一步配置；如果当前机器人流量很少，可以只开启观察规则，不必立即阻断。
4.2 第二步：开启开关型防护
找到 Security → Bots 页面中的 Bot Fight Mode 或 Super Bot Fight Mode，确认是否已经启用。免费版用户一般可以看到 Bot Fight Mode，它会把未验证的高危机器人请求自动拦截或挑战。Super Bot Fight Mode 则提供更细的区分，可以单独处理“已验证 Bot”和“未验证 Bot”。
更符合“先观察再收紧”的做法是：先将模式从 Off 切换到 Challenge。Challenge 动作会要求疑似机器人完成浏览器质询，对真正的用户影响很小，同时能有效挡住大多数批量请求。运行 24 到 48 小时后，再到安全事件里检查命中记录；如果确认没有误杀正常用户，再决定是否将动作调整为 Block。
4.3 第三步：用 WAF 自定义规则锁定 AI UA
如果你关注的是已知的 AI 爬虫，最直接的方法是在 WAF 层创建自定义规则。路径是 Security → WAF → Custom rules → Create rule。
规则名称可以写成 “Block known AI crawlers”，表达式匹配常见的 AI 爬虫 User-Agent，动作按你的信任程度选择 Block 或 Managed Challenge。下面是一个通用表达式，你可以在其中增删关键词：
(lower(http.user_agent) contains "gptbot") or (lower(http.user_agent) contains "claudebot") or (lower(http.user_agent) contains "perplexitybot") or (lower(http.user_agent) contains "bytespider") or (lower(http.user_agent) contains "google-extended") or (lower(http.user_agent) contains "ccbot")这里使用lower()是为了避免大小写差异造成的漏匹配。需要提醒的是，AI 爬虫的 User-Agent 列表会变化，建议把你维护的关键词列表放进版本控制，定期更新，而不是配置一次就不再维护。
4.4 第四步：兜底规则处理伪装请求
已知 UA 能拦截一部分爬虫，但真正难处理的是伪装成普通浏览器的请求。针对这类请求，可以使用 Bot Score 和cf.client.bot字段做兜底。
例如，以下表达式表示“未经验证的机器人请求”，动作可以选择 Managed Challenge：
(cf.client.bot and not cf.client.bot.verified_bot)这条规则的优点是覆盖范围广，不依赖具体 UA；缺点是有概率让部分非主流浏览器用户收到一次质询。因此建议把它的动作设置为 Managed Challenge，而不是直接 Block。如果某个真实用户因为网络环境特殊被误伤，他完成一次质询后就能正常访问，影响相对可控。
4.5 第五步：上线顺序与紧急回滚
完成规则创建后，先在安全事件里确认规则已经命中，再把动作从观察或挑战切换为阻断。每一条规则都应该在名称里写清楚用途、创建日期和维护人，例如 “AI Bot Block - 20250115”。
如果线上出现异常，第一时间是暂停对应规则，而不是删除。暂停后流量会立刻恢复原状，再根据安全事件和源站日志分析误伤样本。整个过程建议控制在 10 分钟内完成，这也是把“可回滚”放在配置设计里的意义。
5. 完整示例与代码实现
5.1 示例一：WAF 自定义规则表达式
在 Cloudflare 后台创建自定义规则时，把表达式粘贴到 Expression Editor，选择动作 Block。
// WAF Custom Rule Expression // 文件位置：Security → WAF → Custom rules → Create rule ( lower(http.user_agent) contains "gptbot" or lower(http.user_agent) contains "claudebot" or lower(http.user_agent) contains "claude-spell-checker" or lower(http.user_agent) contains "perplexitybot" or lower(http.user_agent) contains "bytespider" or lower(http.user_agent) contains "google-extended" or lower(http.user_agent) contains "ccbot" or lower(http.user_agent) contains "amazonbot" or lower(http.user_agent) contains "meta-externalagent" )这段表达式把所有已知 AI 爬虫 UA 统一处理。实际使用时，建议先保存为 Log 动作，观察一段时间再改成 Block。可以从“CCBot”这类明确不产生业务价值的爬虫开始，逐步扩大范围。
5.2 示例二：通过 Cloudflare Rulesets API 更新规则
如果需要管理多个域名，或者希望把规则变更纳入 CI/CD 流程，可以调用 Cloudflare Rulesets API。下面是一个用 curl 更新 Zone 级自定义规则集的示例。请先将变量替换为你自己的实际值，并且先执行 GET 请求获取当前 ruleset 中的已有规则，避免覆盖。
#!/usr/bin/env bash # 文件路径：scripts/update_ai_bot_rule.sh ZONE_ID="your_zone_id" ACCOUNT_ID="your_account_id" API_TOKEN="your_api_token" RULESET_ID="your_zone_custom_ruleset_id" curl -X PUT \ "https://api.cloudflare.com/client/v4/zones/${ZONE_ID}/rulesets/${RULESET_ID}" \ -H "Authorization: Bearer ${API_TOKEN}" \ -H "Content-Type: application/json" \ --data '{ "rules": [ { "description": "Block known AI crawlers", "expression": "lower(http.user_agent) contains \"gptbot\" or lower(http.user_agent) contains \"claudebot\" or lower(http.user_agent) contains \"bytespider\" or lower(http.user_agent) contains \"ccbot\"", "action": "block", "enabled": true } ] }'这段代码的关键点在于“先读后写”。实际调用 PUT 前，应该先用GET /client/v4/zones/{zone_id}/rulesets/{ruleset_id}获取当前 rules，把已有规则拼接进去，再一起提交。如果你直接把上面这段 JSON 原样 PUT 上去，会覆盖掉该 ruleset 中已有的其他规则。RULESET_ID 的获取方式，可以通过GET /client/v4/zones/{zone_id}/rulesets查询 phase 为http_request_firewall_custom的 entrypoint，具体接口以 Cloudflare 官方 API 文档为准。
5.3 示例三：Cloudflare Worker 精细化拦截
如果自定义规则无法满足你的场景，比如你想实现“AI 爬虫访问时返回一份说明页面”或“对伪装 UA 的请求做二次识别”，可以编写一个 Cloudflare Worker。将 Worker 部署在域名入口，它对请求的处理发生在 Cloudflare 边缘，且比 WAF 表达式更灵活。
// 文件路径：worker/index.js const AI_CRAWLER_PATTERNS = [ 'gptbot', 'claudebot', 'claude-spell-checker', 'perplexitybot', 'bytespider', 'google-extended', 'ccbot', 'amazonbot', 'meta-externalagent', 'imagesiftbot', ]; export default { async fetch(request) { const userAgent = (request.headers.get('User-Agent') || '').toLowerCase(); const matched = AI_CRAWLER_PATTERNS.some((pattern) => userAgent.includes(pattern)); if (matched) { return new Response('Access denied', { status: 403 }); } return fetch(request); } }这段代码的逻辑非常简单：读取请求的 User-Agent，与已知 AI 爬虫关键词列表做匹配，命中则返回 403，未命中则继续转发。你可以在这个基础上扩展更多逻辑，例如对命中请求写一条日志到一个 KV 存储，方便后续分析。Workers 的好处是逻辑完全可控，坏处是需要自己维护代码和部署流程，适合有一定开发能力的团队。
5.4 示例四：IP 与 ASN 维度的补充规则
有些 AI 爬虫并不使用常见 UA，而是直接以云服务商的 IP 访问。这种情况下，可以结合 ASN 做规则。把某些云计算厂商的 ASN 加入“高风险网络”列表，当这些 IP 访问你站点时，先执行一次浏览器质询。下面是一个规则表达式示例：
( ip.src.asnum eq 15169 or ip.src.asnum eq 396982 or ip.src.asnum eq 20473 ) and not cf.client.bot.verified_bot这段表达式的含义是：来自这些 ASN、且不是已验证搜索引擎爬虫的请求，需要执行挑战。ASN 编号会发生变化，也可能误伤使用该云厂商相同出口 IP 的真实用户，因此建议动作选择 Managed Challenge 而非直接阻断，并且先观察一段时间。
6. 运行结果与效果验证
6.1 如何验证规则生效
配置完成后，不要只看后台，要回到真实流量里验证。推荐顺序是：先看 Security Events，再看 Bots Analytics，最后看源站访问日志。
Security Events 里会记录每条规则命中的次数和执行动作。你可以按规则名称筛选，确认 Block 或 Managed Challenge 的数量与预期一致。Bots Analytics 页面则能看到机器人流量的整体趋势，如果规则生效，机器人请求占比应该明显下降。
如果条件允许，可以打开源站访问日志，观察来自这些 AI 爬虫 UA 的请求是否已经停止。这里有个容易忽略的点：如果部分页面被 Cloudflare 缓存命中，源站日志不会出现对应请求，因此源站日志归零并不等于爬虫停止，应该结合安全事件一起判断。
6.2 预期效果判断
以“拦截前 vs 拦截后”做定性对比，通常可以观察到以下变化：拦截前，某些 AI UA 几乎全天都有稳定的请求，路径分散，间隔规律；拦截后，安全事件中会出现大量命中记录，而这些记录不会再出现在源站日志中。
如果你执行的是 Managed Challenge，还会在安全事件中看到“现在挑战”或“通过挑战”的状态。这代表一个疑似机器人完成了质询或放弃访问。真实用户如果遇到质询，一般几秒钟内通过，影响很小。
6.3 如果失败了先看哪里
防护配置没生效，第一步不是怀疑 Cloudflare，而是按这个顺序排查：先确认域名 DNS 记录是否为橙色代理状态，如果没有代理，所有规则都不会经过边缘；再确认规则是否为启用状态，且没有被更高优先级的规则放行；然后到安全事件里搜索该用户的 IP 或 UA，看看是否有规则命中记录。
如果安全事件里完全没有命中，说明请求可能没有经过 Cloudflare，或者表达式条件过于严格。如果命中了但源站仍然收到请求，需要检查是否是缓存回源造成的，比如请求被 CDN 缓存命中后，回源日志本身不应该出现该请求，这是正常现象，不代表规则失效。
7. 常见问题与排查思路
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| 配置 Block 后真实用户无法访问 | 表达式过宽，匹配到了移动 App 内置浏览器或代理 UA | 在安全事件中查看误杀请求的 UA 与 ASN，找出公共特征 | 把误杀特征加入白名单条件，或把动作从 Block 改为 Managed Challenge |
| 部分 AI 爬虫仍然可以访问 | 它们使用了伪装 UA，没有被已知清单覆盖 | 观察 Bots Analytics，查看是否存在 Score 很低且来自云厂商 ASN 的请求 | 增加cf.client.bot and not cf.client.bot.verified_bot兜底规则 |
| Google 搜索收录下降 | 表达式误匹配了 Googlebot，或规则优先级过高 | 检查安全事件中 Googlebot IP 是否被拦截，通过搜索引擎公开 IP 反查验证 | 在规则中排除已验证搜索引擎爬虫，或改用 Bot Score 维度 |
| robots.txt 已禁止但仍被爬 | 爬虫不遵守 robots.txt，约束条件只写在协议层 | 查看源站日志和边缘日志，确认抓取是否来自 AI 爬虫集群 | 改用 Cloudflare WAF 强制拦截，不能只依赖 robots.txt |
| 规则 API 返回错误 | Token 权限不足，或规则表达式语法错误 | 检查 API 返回的错误码，确认 Token 是否包含 Zone WAF Edit 权限 | 使用最小权限 Token，先在控制台验证表达式，再提交 API |
| 误伤运营监控或自动测试脚本 | 监控脚本的 UA 与机器人模型特征相似 | 在安全事件中筛选监控服务 UA 的请求，确认被哪条规则命中 | 维护一份内部白名单，对已知监控 UA 放行 |
8. 最佳实践与工程建议
8.1 分层防御，而不是一刀切
AI 爬虫防护最忌讳的是追求“全部 Block”。更好的策略是分层：第一层放行已验证搜索引擎爬虫；第二层阻断明确的 AI 爬虫 UA；第三层对未验证的高危机器人进行挑战；第四层对可疑但无法确定的请求只记录日志。每一层的动作强度从宽到严，既能保护资源，又能避免误伤。
比如可以把“搜索引擎收录”和“AI 爬虫防护”作为两个独立规则。搜索引擎爬虫需要放行，否则收录会下降；AI 爬虫则需要拦截。两者不能用同一个规则处理。
8.2 用户代理之外，增加 IP、ASN、验证码维度
单靠 UA 拦截只解决“明确暴露身份”的 AI 爬虫。对于伪装请求，建议把 Bot Score、ASN、IP 信誉等多维信息叠加起来。企业版 Bot Management 提供了更细的分数和触发日志；免费版也可以借助 WAF 自定义规则，把“ASN + 非验证 Bot + 特定路径”组合使用。
如果站点有重要表单或注册入口，可以接入 Cloudflare Turnstile 验证码。Turnstile 对用户无感，不要求用户输入字符，能有效挡住自动化脚本提交。对 AI 爬虫来说，表单入口往往是它们获取生成内容的通道，加一道验证码能显著提高采集成本。
8.3 把 UA 清单放进版本控制，定期更新
AI 爬虫的 User-Agent 不是固定不变的。OpenAI、Anthropic、ByteDance、Meta 等公司会新增爬虫名称，也会调整现有 UA。建议你维护一个 JSON 或 Txt 格式的规则清单，放在 Git 仓库里，配合 API 脚本完成更新。更新频率可以是一个月一次，也可以在发现新的高流量爬虫时立刻调整。
维护清单时要注意：不要盲目复制网上的全部列表。只选择与你业务相关的爬虫，避免把一些尚未确认的 UA 写进 Block 规则，导致误伤。
8.4 监控、告警与日志留存
防护配置上线后，需要配套监控。建议对以下指标设置告警：Block 事件数量突然激增、安全事件中出现大量 Managed Challenge、源站带宽异常下降、自定义规则命中率显著变化。这些指标都可能说明规则出现问题，需要及时人工介入。
日志留存也很重要。如果你使用免费版，建议至少定期导出安全事件；如果条件允许，开启 Logpush 把边缘日志推到自己的日志平台，保留 30 天以上。这样在规则变更后出现问题，可以快速回溯“变更前流量是什么样、变更后发生了什么变化”。
8.5 合规与安全边界
防护能力要用在合法场景中。自己的站点、自己拥有权限的项目，可以配置 Cloudflare 防护；但不要使用 Cloudflare 的规则或脚本去抓取、对抗其他站点。抓取第三方数据前，应遵守目标站点的服务条款和 robots 规则。本文给出的所有脚本和规则，都只用于保护你自己的业务资源。
8.6 回滚预案
每次修改规则前，保存当前规则集。Cloudflare 控制台和 API 都支持查询当前配置，你可以把这些配置内容作为备份存到 Git 仓库。遇到误伤时，最快的办法是暂停规则，而不是删除。暂停后流量立即恢复，你可以在安全事件里继续分析，等确定问题后再修改表达式重新上线。
9. 总结与后续学习方向
如果只做一件事，我建议你现在就去 Cloudflare 后台的 Security → Bots 页面看一眼。如果发现首页和接口路径里有大量你从没听过的 AI UA，就按第 4 节把 Managed Challenge 开起来。AI 爬虫防护本身不复杂，复杂的是后续的持续运营：规则不是配一次就完事，需要至少每个月 review 一次，并在每次规则变更后观察安全事件和源站日志。
进一步学习，可以从这几个方向切入：深入理解 Cloudflare Ruleset Engine 的表达式语法，把规则从“能用”变成“精准”；学习如何把 Logpush 与日志分析平台打通，建立基于数据驱动的 Bot 趋势监控；如果团队有开发能力，可以尝试用 Workers 实现更灵活的 AI Agent 流量识别与限流逻辑；企业场景下，再评估是否需要引入 Bot Management 和 Turnstile 验证码，覆盖更复杂的自动化攻击。先把最简单的拦截做好，再逐步升级，这才是大多数站点应对 AI 爬虫的最优路径。
