从春节前后开始我陆续收到好几个站长朋友的反馈网站的访问日志里出现了大量的 AI 爬虫请求有些甚至比真实用户流量还多。更让人头疼的是这些请求的 User-Agent 五花八门有的叫 GPTBot有的叫 ClaudeBot还有叫 Bytespider、Amazonbot 的完全分不清是搜索引擎收录还是 AI 模型在抓数据。随着 AI 应用爆发式增长Cloudflare 的仪表盘上也出现了一个很形象的趋势AI 机器人流量占比持续攀升正常站点开始被 AI 抓取、AI 内容聚合、AI 训练数据采集搞得焦头烂额。我把这个现象称为Cloudflare AI Psychosis——不是 Cloudflare 本身出了问题而是 AI 时代的流量混乱让站点的安全策略变得异常复杂Bots 管理成了每个站长都必须面对的新课题。本文将围绕 Cloudflare 的 Bots 管理、AI 爬虫识别与拦截、自定义规则配置、Workers 层防护以及常见误伤问题展开结合真实场景给出完整的配置思路和可复制代码。无论你是个人博客站长、企业站点运维还是做内容平台的开发者都可以在本文中找到一套适合自己站点的 AI 爬虫治理方案。1. AI 爬虫时代的流量困境1.1 什么是 AI 爬虫AI 爬虫AI Bot / AI Crawler是指那些专门用于采集网页内容、图片、文档用于大模型训练、RAG 知识库构建、内容聚合分析的自动化程序。它们的工作方式和传统搜索引擎爬虫类似但目标完全不同搜索引擎爬虫是为了建立索引AI 爬虫则是为了获取直接可用于训练和推理的文本数据。目前市面上几乎所有主流 AI 服务商都发布了自己的爬虫程序爬虫名称所属公司主要用途GPTBotOpenAI训练 GPT 系列模型ClaudeBotAnthropic训练 Claude 模型Bytespider字节跳动训练豆包等模型AmazonbotAmazon搜索和商品理解Google-ExtendedGoogleAI 训练数据采集Applebot-ExtendedAppleApple IntelligenceCCBotCommon Crawl抓取全网页数据供多模型使用这些爬虫的 User-Agent 大多数都能查得到但问题在于互联网上的爬虫远不止这些正规玩家还有很多第三方数据公司、开源项目作者、内容聚合工具在伪装成各种 UA 进行抓取甚至有些直接用无头浏览器模拟真人访问普通防护手段很难拦截。1.2 Cloudflare 视角下的“AI 精神错乱”“Psychosis”这个词听起来有点夸张但从 Cloudflare 安全团队的观察来看AI 带来的流量确实呈现出一种“精神错乱”般的状态请求频率忽高忽低AI 爬虫可能在某几天集中抓取让流量曲线瞬间飙升然后又突然完全消失。UA 频繁变化同一个 IP 段的爬虫会轮换使用不同的 User-Agent甚至伪装成 Chrome 浏览器。抓取路径无规律有的爬虫只抓首页和文章列表有的则会遍历所有详情页、下载附件、读取 robots.txt。正常用户被误伤部分安全策略在拦截 AI 爬虫时会把使用无头浏览器、RPA 工具、海外节点的真实用户一同拦截。这种混乱直接导致了很多站点在 Cloudflare 后台看到的现象Security 事件数量猛增、Bot Score 剧烈波动、缓存命中率下降、源站负载升高。如果你没有一套清晰的 AI 爬虫治理策略很容易在“全拦截”和“全放行”之间反复摇摆。1.3 为什么需要专门治理 AI 爬虫有人会说反正爬虫来了就拦截呗有什么好纠结的但在实际运维中AI 爬虫治理远比想象中复杂。一方面并不是所有 AI 爬虫都该被屏蔽——例如你自己在开发 RAG 应用可能需要放行某些内容抓取工具来构建知识库另一方面有些 AI 爬虫能带来有价值的回源流量比如 Google-Extended 的抓取记录会影响你的内容在 AI 搜索中的出现概率。所以正确的做法不是一刀切而是先摸清这些爬虫的真实行为再分场景配置策略。2. Cloudflare Bots 管理核心概念2.1 Cloudflare 如何识别 BotCloudflare 的 Bot 识别并不是简单检查 User-Agent 就完事而是综合了多种信号User-Agent / JA3 / JA4 指纹JA3 是 TLS 握手指纹JA4 是更精细的 TLS 指纹。Cloudflare 维护了一个庞大的指纹库能识别 headless Chrome、PhantomJS、Selenium 等自动化工具。行为特征请求频率、点击路径、鼠标移动轨迹、页面停留时间、并发连接数等。IP 信誉来自数据中心、主机托管商、代理网络的 IP 权重会很低。JS Challenge 结果Cloudflare 会给可疑请求下发一段 JavaScript 挑战只有真正的浏览器才能通过。基于这些信号Cloudflare 会给每次请求打一个Bot Score机器人评分范围是 1 到 99。分数越低代表是机器人的可能性越大分数越高代表是真实用户的可能性越大。在自定义规则中你可以直接用cf.bot_management.score这个字段来匹配请求。2.2 Bots 管理模式的区别在 Cloudflare 的Security → Bots页面有一个核心选项叫Bots Management Mode。不同套餐支持的模式不同常见的模式包括模式说明适用场景严格Strict)只放行确认的人类流量拦截所有潜在 Bot高安全要求站点宽松Loose)只拦截高置信度的 Bot允许中间分数流量普通内容站点仅记录Log only)只做标记不实际拦截前期观察阶段允许列表模式只拦截明确不在白名单中的 Bot面向 API 业务的站点网络热搜里提到的那条“将 bots management 模式由严格改为...”正是很多站长在 AI 爬虫治理中的第一步尝试因为严格模式下误伤率太高很多渠道的推广流量、移动端浏览器、甚至部分正常爬虫都会被拦导致业务受损。解决方向不是简单地把模式从严格调成宽松而是应该配合自定义规则做精细化分流。2.3 Bot Fight Mode 与 Super Bot Fight Mode在了解自定义规则之前需要先分清 Cloudflare 的几类 Bot 防护能力Bot Fight Mode免费版可用拦截已知的恶意爬虫但是不能自定义。Super Bot Fight ModePro 及以上可用允许你按“已验证 Bot / 已知 Bot / 疑似 Bot”分类处理。Bots ManagementEnterprise 级功能提供详细的 Bot Score 和自定义规则支持。自定义 WAF 规则所有套餐都可以通过 WAF 规则引用 Bot Score实现了类似 Bots 管理的效果。这里要特别说明国内很多站长用的是 Cloudflare 免费版或 Pro 版没有完整的 Bots 管理界面。这种情况下想治理 AI 爬虫最有效的路径是用自定义 WAF 规则 Workers 缓存规则组合来实现。3. Cloudflare 识别 AI 爬虫的几种方式3.1 通过 user-agent 精确匹配最简单粗放的方式是直接匹配已知的 AI 爬虫 UA。Cloudflare 的 WAF 自定义规则支持正则表达式你可以把需要拦截的爬虫 UA 写成一个正则。例如(gptbot|claudebot|bytespider|amazonbot|ccbot|google-extended)这种方式的好处是规则简单、性能好但缺点是依赖 UA 真实性。如果对方每天换 UA或者伪装成普通浏览器那么这条规则很快失效。3.2 通过验证 BotVerified Bots列表Cloudflare 维护了一个“Verified Bots”名单里面包含 Googlebot、Bingbot、GPTBot 等知名爬虫。在 Super Bot Fight Mode 或者 Bots Management 界面里你可以拿这些名单做允许/拦截操作。例如你允许 Googlebot 正常抓取但拦截 GPTBot。这是比较推荐的操作逻辑先基于可信名单放行再对名单外的可疑行为做严格限制。3.3 通过 ASN / IP 信誉很多 AI 爬虫都运行在云厂商的 IP 上比如 AWS、Google Cloud、Azure、DigitalOcean、OVH 等。Cloudflare 的 IP 信誉库会对这些“数据中心 IP”打低分。你可以直接做一个规则如果来源 IP 是数据中心 ASN 且 Bot Score 低于 30就执行拦截或 JS Challenge。但需要注意这种规则容易误伤使用云服务器办公的真实用户因此最好加一些限定条件比如访问目标路径是否为敏感资源。3.4 通过 JS Challenge 分流JS Challenge 是治理 AI 爬虫的“中间路线”不直接拦截而是要求客户端执行一段 JavaScript 来证明自己是浏览器。真正的 AI 爬虫大多不执行 JS因此拿不到cf_clearanceCookie后续的请求都会被拦截。真实用户几乎无感知会看到一次短暂的白屏。在 Cloudflare 自定义规则中一项典型的 AI 爬虫分流策略是如果请求 UA 匹配常见 AI 爬虫 → 执行 JS Challenge。如果 Bot Score 低于 20 且访问路径是文章列表 → 执行 JS Challenge。如果 Bot Score 低于 20 且访问路径是登录页/API → 直接拦截。4. 实战Cloudflare 后台配置 AI 爬虫治理下面进入正题。假设你有一个内容型网站网站托管在 Cloudflare 后面源站在国内服务器或海外服务器均可。你想做三件事观察哪些 AI 爬虫在访问你的网站。阻止部分 AI 爬虫抓取全文但保留搜索引擎收录。避免误伤真实用户和正常的 API 调用。4.1 第一步确认当前 Bots 管理模式登录 Cloudflare 后台在左侧导航找到Security → Bots。如果你看到的是 “Bot Fight Mode” 或 “Super Bot Fight Mode” 页面说明你的套餐还在这些功能范围内。先不要急着改模式而是把当前状态记录下来。比如如果当前是严格模式并且出现了大量误拦截日志可以先把模式切换成仅记录或宽松模式观察几天积累数据。这里需要强调调整 Bots 管理模式一定要在流量低峰期操作并且先在某个域名或某条路径上小范围验证。不要直接对全站执行严格模式否则一旦误伤面扩大严重影响用户访问。4.2 第二步利用 WAF 自定义规则拦截 AI 爬虫在 Cloudflare 后台左侧找到Security → WAF → Custom rules点击Create rule。场景一拦截常见 AI 爬虫抓取文章内容。适合免费版、Pro 版、Enterprise 版因为 WAF 自定义规则在大部分套餐都可以用。规则名称Block AI Crawlers - Content Paths匹配条件(UA contains GPTBot or UA contains ClaudeBot or UA contains Bytespider or UA contains Amazonbot) and URI PATH contains /articles/执行动作Block如果你不确定这些爬虫 UA 的全部值可以加入正则表达式形如(.*)(gptbot|claudebot|bytespider|amazonbot|ccbot|google-extended)(.*)Cloudflare WAF 的自定义规则支持正则表达式但注意正则默认是区分大小写的也可以用matches操作符来达到类似效果。需要说明的是这样直接 Block 会导致这些爬虫在日志里变成 403后续想分析它们的访问行为就看不到了。因此更推荐先做以下“挑战”策略规则名称Challenge AI Crawlers匹配条件使用正则匹配常见的 AI Bot UA。执行动作Managed Challenge这样 AI 爬虫会收到 403 或 challenge 页面不会进入源站而真实用户例如刚好也用了某个爬虫 UA 的发烧友则有机会完成挑战继续访问。4.3 第三步基于 Bot Score 的精细化规则如果你使用的是 Enterprise 或 Pro 套餐可以看到cf.bot_management.score字段。在 WAF 自定义规则中新建如下规则规则名称Low Bot Score - Challenge条件cf.bot_management.score lt 25执行动作Managed Challenge或 JS Challenge这条规则适合绝大多数内容站点。它的含义是只要 Cloudflare 判断该请求极可能是机器人就执行挑战。真实用户即使分数偏低也能通过挑战继续访问而大部分 AI 爬虫并不会执行 JavaScript会在第一步被卡住。但这里有一个常见的坑有些网站使用了一些前端框架例如 Next.js、Nuxt.js 的 SSR 模式页面已经预渲染好了搜索引擎爬虫和 AI 爬虫都能直接抓取到 HTML。如果你设置了上面的低分挑战可能会影响部分搜索引擎爬虫的抓取。解决方法是把搜索引擎的合法爬虫加白名单让它直接跳过挑战。规则可以写成条件 1cf.bot_management.verified_bot条件 2排除常见搜索引擎(cf.bot_management.score lt 25 and not cf.bot_management.verified_bot)也就是说如果请求来自verified_bot比如 Googlebot直接放行否则再看 Bot Score 决定是否挑战。4.4 第四步通过 Workers 加强 AI 爬虫防护有些情况下使用 WAF 规则还是不够灵活。比如你想在 robots.txt 被访问时给 AI 爬虫返回一个特殊内容或者你想在 HTML 响应中注入一个noindex标签仅针对 AI 爬虫或者你想统计 AI 爬虫访问了哪些 URL用于后续分析。这时可以借助 Cloudflare Workers。下面是一个简单的 Worker 代码用来识别 AI 爬虫并返回 403 或者自定义内容// 文件路径workers-ai-bot-blocker.js export default { async fetch(request, env, ctx) { const url new URL(request.url); const userAgent request.headers.get(User-Agent) || ; // 定义 AI 爬虫关键词列表 const aiBotKeywords [ gptbot, claudebot, bytespider, amazonbot, ccbot, google-extended, anthropic-ai, perplexitybot ]; const lowerUA userAgent.toLowerCase(); const isAiBot aiBotKeywords.some((keyword) lowerUA.includes(keyword)); // 如果目标是 robots.txt并且是 AI 爬虫返回一个最小化的 robots 内容 if (url.pathname /robots.txt) { if (isAiBot) { return new Response(User-agent: *\nDisallow: /\n, { headers: { Content-Type: text/plain } }); } // 非 AI 爬虫继续走源站 return fetch(request); } // 如果访问文章页且判定为 AI 爬虫返回 403 if (isAiBot url.pathname.startsWith(/articles/)) { return new Response(Forbidden, { status: 403 }); } // 其他情况正常回源 return fetch(request); } };这个 Worker 示例的思路是先获取请求的 UA 和路径。如果请求的目标是robots.txt那么 AI 爬虫收到的是“全站禁止抓取”的响应。如果 AI 爬虫请求文章列表或详情页则直接返回 403。其他请求正常回源。上线后你可以在 Cloudflare 后台的Workers Pages → 你的 Worker → Triggers → Custom Domains中绑定你的站点域名。为了不影响正式环境建议先绑定一个测试域名或测试路径。4.5 第五步记录 AI 爬虫流量并持续分析无论使用哪种拦截方式都建议开启日志记录。Cloudflare 的Security Events页面会展示所有被 WAF 规则处理的请求包括规则名称、匹配到的 UA、来源 ASN、目标路径等。你可以根据日志不断调整规则。另一个很实用的工具是 Cloudflare 的Analytics → Traffic Analytics里面可以按 Bot Score 分布来查看流量构成。比如你发现“低分请求”占到了 40%那说明你的站正被大量爬虫访问如果这些“低分请求”中真实用户占了不小比例就需要考虑调整 Bot Score 阈值或执行动作为“挑战”而不是“拦截”。5. 完整代码示例Worker 版 AI 爬虫管理面板如果你希望有一个可配置的 AI 爬虫管理方案不希望在 Worker 代码里写死关键词可以用 Cloudflare Workers KV 存储配置列表。下面给出一套更完善的示例。5.1 保存配置到 KV假设你有一个 KV 命名空间叫AI_BOT_CONFIG在 Workers 中绑定为BOT_CONFIG。配置内容可以是一个 JSON 字符串{ blockedKeywords: [gptbot, claudebot, bytespider], challengeKeywords: [perplexitybot, amazonbot], protectedPaths: [/articles/, /docs/] }5.2 Worker 读取 KV 并执行策略// 文件路径worker-kv-ai-bot-manager.js export default { async fetch(request, env, ctx) { const url new URL(request.url); const userAgent (request.headers.get(User-Agent) || ).toLowerCase(); const config await env.BOT_CONFIG.get(config, json).catch(() null); // 默认配置防止 KV 未初始化 const blockKeywords config?.blockedKeywords || [gptbot]; const challengeKeywords config?.challengeKeywords || []; const protectedPaths config?.protectedPaths || []; const isBlocked blockKeywords.some((kw) userAgent.includes(kw)); const isChallenged challengeKeywords.some((kw) userAgent.includes(kw)); const isProtectedPath protectedPaths.some((p) url.pathname.startsWith(p)); if (isBlocked isProtectedPath) { return new Response(Blocked by AI Bot Manager, { status: 403 }); } if (isChallenged isProtectedPath) { // 简易挑战逻辑要求带上指定的查询参数 if (url.searchParams.get(challenge) ! passed) { return new Response(Challenge failed, { status: 401 }); } } return fetch(request); } };这种方式的优点是配置在 KV 中不需要每次修改代码。你可以在 Cloudflare 后台手动更新 KV 值也可以通过一个管理接口去更新。5.3 使用 Crontab 定期同步 AI 爬虫 IP 列表除了 UA 匹配你还可以把已知的 AI 爬虫 IP 段保存到 KV 中然后用 Workers 定期拉取某个可信源来更新。Cloudflare Workers 支持 Scheduled Triggers定时触发器下面这段代码演示了定时拉取一份远程 IP 列表并写入 KV// 文件路径scheduled-sync-bot-ips.js export default { async scheduled(event, env, ctx) { const resp await fetch(https://example.com/ai-bot-ips.json); // 这里替换为你的可信源 const data await resp.json(); // 假设 data.ips 是一个字符串数组 await env.BOT_CONFIG.put(blockedIps, JSON.stringify(data.ips || [])); console.log([sync] updated ${data.ips?.length || 0} IPs); }, async fetch(request, env, ctx) { const clientIp request.headers.get(CF-Connecting-IP) || ; const blockedIps JSON.parse((await env.BOT_CONFIG.get(blockedIps)) || []); if (blockedIps.includes(clientIp)) { return new Response(Blocked, { status: 403 }); } return fetch(request); } };需要注意不要让 Worker 定时任务去访问不可靠的来源否则恶意攻击者可能通过控制该来源来批量封禁真实用户 IP。6. 常见问题与排查思路6.1 我用了严格模式为什么还有 AI 爬虫能访问严格模式并不是“万能锁”。如果 AI 爬虫使用了真实的浏览器指纹例如用 Puppeteer 开启 stealth 插件或者通过住宅代理 IP 访问Cloudflare 很难识别。排查思路如下打开 Security Events确认拦截日志里是否有该请求。如果没有拦截日志说明请求被其他规则放行了比如 Page Rules 或 WAF 规则优先级更高。尝试把该请求的 IP 放入 Firewall Rules 的 IP Access Rules 做一次手动拦截验证。如果手动拦截后该爬虫仍然能访问则考虑请求并未经过 Cloudflare可能 DNS 解析未生效或存在多条 A 记录。6.2 调整模式之后为什么网站搜索流量下降了这通常是因为某些搜索引擎爬虫也被你的规则误伤。比如你把“严格模式”打开后像 Yandex、Baidu 这类爬虫如果不在 Cloudflare 的 Verified Bots 列表里就会收到 JS Challenge导致抓取失败。解决方案在 WAF 规则中增加白名单(cf.bot_management.verified_bot)或指定 UA 放行。或者把 Bots 管理模式从“严格”降到“宽松”观察一周再看搜索流量是否恢复。6.3 Managed Challenge 会不会影响用户留存会但影响很小。大部分真实用户会在毫秒级完成 JS 挑战几乎无感知。只有两种情况影响明显用户手机浏览器版本过旧无法执行新版 JS 挑战。用户网络环境屏蔽了 cf_clearance Cookie。建议针对移动端 UA 或者特定地理区域适当降低挑战概率例如只对高风险路径启用挑战。6.4 如何确认某个 UA 是不是 AI 爬虫可以通过下面的方式判断搜索该 UA 对应的官方文档看是不是公开的模型服务商爬虫。检查访问频率单个 IP 在短时间内发起超过 50 次请求基本可以断定是爬虫。查看访问路径如果只访问文章页、图片资源、PDF 文件不访问首页和 JS/CSS大概率是内容采集爬虫。6.5 使用表格总结常见问题问题现象常见原因解决思路严格模式下正常用户被拦截低版本浏览器/移动设备无法通过 JS Challenge将动作改为 Managed Challenge并按 UA 加白AI 爬虫仍然访问使用真实浏览器指纹或代理 IP增加 IP 信誉规则结合 ASN 和 Bot Score 做多维判断robots.txt 被频繁抓取爬虫在探测抓取边界对 robots.txt 做缓存并给 AI 爬虫返回 Disallow 内容源站负载飙升大量爬虫绕过 CDN 直接访问源站在源站安全组中仅放行 Cloudflare IP 段搜索收录减少合法爬虫被 WAF 规则拦截放行 Verified Bots或调整 Bot Score 阈值7. 最佳实践与工程建议7.1 不要在白天直接切换严格模式如果你打算把 Bots 管理模式从“宽松”切换到“严格”建议选择凌晨流量低峰期操作并且提前在测试路径上用自定义规则模拟。生产环境中的任何安全策略变更都应有回滚方案。Cloudflare 后台有“审核日志”功能操作前建议截图保存当前配置。7.2 用好 Cache 规则减轻源站压力AI 爬虫最可怕的地方在于高频遍历页面。即使你通过 Bot Score 做了挑战挑战请求本身也会消耗一定的边缘资源。更优的做法是对文章页、列表页设置合理的 Cache Rule让匿名请求直接命中 Cloudflare CDN 缓存源站只接收少量回源请求。例如HTML 页面 TTL 设为 300 秒。对带有sitemap关键词的路径不做缓存保证搜索引擎收录更新。对 API 路径设置按需缓存或完全绕过缓存。7.3 配置源站层白名单防止绕过 CDN有一部分 AI 爬虫会探测源站 IP并绕过 Cloudflare 直接访问源站。这是很多站长最容易忽略的风险点。建议在源站服务器安全组或防火墙中做以下限制只允许 Cloudflare 官方 IP 段访问 80/443 端口。禁止来自非 Cloudflare IP 的 HTTP 请求。定期查看源站访问日志寻找可疑的源站 IP 探针。在服务器防火墙中可以用如下思路以 UFW 为例# 只允许 Cloudflare IP 段访问 80/443 for ip in $(curl -s https://www.cloudflare.com/ips-v4); do sudo ufw allow from $ip to any port 80 proto tcp sudo ufw allow from $ip to any port 443 proto tcp done # 拒绝其他 IP 访问 80/443 sudo ufw deny 80/tcp sudo ufw deny 443/tcp执行前记得先保留 SSH 端口默认 22的放行规则避免把自己锁在外面。7.4 不要全盘照搬别人的拦截列表每个网站的内容类型、用户群体、SEO 需求都不一样。别人拦截 GPTBot不一定适合你。比如有的工具站希望被 AI 产品收录从而获得 AI 搜索流量那就应该放行 GPTBot 和 ClaudeBot。建议把 AI 爬虫分成三类分别设置策略分类示例推荐策略搜索引擎爬虫Googlebot、Bingbot、Baiduspider放行纳入 Verified Bots模型训练爬虫GPTBot、ClaudeBot、Bytespider默认拦截但可根据业务放行第三方采集工具自定义 UA 或匿名爬虫低 Bot Score 请求执行 Managed Challenge7.5 定期复盘日志动态调整规则AI 爬虫的 UA 和 IP 段是动态变化的。建议建立一个每周复盘流程导出 Security Events 中过去 7 天的拦截数据。找出仍然成功请求源站的疑似 AI Bot 请求。更新 Worker 里的关键词列表或 WAF 正则。检查是否有真实用户被误伤及时加入白名单。如果站点规模较大可以通过 Cloudflare 的 Logpush 功能将日志推送到对象存储或日志分析平台做更精细的统计和告警。8. AI 时代的防护心态与学习建议AI 爬虫治理这件事本质上是一场动态博弈。今天你拦截了 GPTBot明天可能出现新的 Anthropic 爬虫今天你放行了 Perplexity后天它的抓取策略可能变成模拟真实用户。想靠一套静态规则永久解决问题是不现实的。但这不是说我们只能被动挨打。通过 Cloudflare 的 WAF、Bots 管理、Workers、缓存规则和源站防护等多层组合完全可以构建一套相对稳定的防护体系。核心心法是先观察再分流最后拦截。刚开始把所有 AI 爬虫都设置为“仅记录”了解它们的行为特征。一周后基于日志制定黑白名单对高置信度爬虫执行挑战。一个月后再结合源站日志和搜索流量变化做动态微调。如果你正在深入学习 Cloudflare 的安全体系下一步可以关注以下几块内容Cloudflare WAF 自定义规则的表达式语法和优先级。Workers 的定时触发器和 KV 存储构建动态防护策略。Cache Rules 和 Cache Reserve 的配合使用。Logpush 和 Workers Analytics 做流量监控。Cloudflare Tunnel 隐藏源站 IP彻底隔绝绕过流量。这中间最容易踩坑的是规则优先级问题。Cloudflare 的执行顺序大致是WAF 自定义规则 → Rate Limiting → 防火墙规则 → 页面规则 → Worker → Cache 规则。你要对某条请求做拦截最好在 WAF 自定义规则这一层完成因为它的日志展示最直观排错最方便。另外不要忽视安全变更的灰度发布。任何 WAF 规则都可以先设置成“Log”模式观察一段时间后再切换成“Block”模式。Cloudflare 后台支持规则切换配合“模拟”的方式可以极大降低误伤风险。不管你是个人站长还是企业平台的技术负责人AI 爬虫治理都不应该通过“一刀切”解决。结合站点类型、内容价值、用户画像和搜索需求制定属于自己的分层策略才是健康可持续的做法。希望这套基于 Cloudflare 的 AI Bot 治理方案能帮你在 AI 流量浪潮中站稳脚跟。 Cloudflare AI爬虫治理实战：从Bots管理到WAF规则配置
从春节前后开始我陆续收到好几个站长朋友的反馈网站的访问日志里出现了大量的 AI 爬虫请求有些甚至比真实用户流量还多。更让人头疼的是这些请求的 User-Agent 五花八门有的叫 GPTBot有的叫 ClaudeBot还有叫 Bytespider、Amazonbot 的完全分不清是搜索引擎收录还是 AI 模型在抓数据。随着 AI 应用爆发式增长Cloudflare 的仪表盘上也出现了一个很形象的趋势AI 机器人流量占比持续攀升正常站点开始被 AI 抓取、AI 内容聚合、AI 训练数据采集搞得焦头烂额。我把这个现象称为Cloudflare AI Psychosis——不是 Cloudflare 本身出了问题而是 AI 时代的流量混乱让站点的安全策略变得异常复杂Bots 管理成了每个站长都必须面对的新课题。本文将围绕 Cloudflare 的 Bots 管理、AI 爬虫识别与拦截、自定义规则配置、Workers 层防护以及常见误伤问题展开结合真实场景给出完整的配置思路和可复制代码。无论你是个人博客站长、企业站点运维还是做内容平台的开发者都可以在本文中找到一套适合自己站点的 AI 爬虫治理方案。1. AI 爬虫时代的流量困境1.1 什么是 AI 爬虫AI 爬虫AI Bot / AI Crawler是指那些专门用于采集网页内容、图片、文档用于大模型训练、RAG 知识库构建、内容聚合分析的自动化程序。它们的工作方式和传统搜索引擎爬虫类似但目标完全不同搜索引擎爬虫是为了建立索引AI 爬虫则是为了获取直接可用于训练和推理的文本数据。目前市面上几乎所有主流 AI 服务商都发布了自己的爬虫程序爬虫名称所属公司主要用途GPTBotOpenAI训练 GPT 系列模型ClaudeBotAnthropic训练 Claude 模型Bytespider字节跳动训练豆包等模型AmazonbotAmazon搜索和商品理解Google-ExtendedGoogleAI 训练数据采集Applebot-ExtendedAppleApple IntelligenceCCBotCommon Crawl抓取全网页数据供多模型使用这些爬虫的 User-Agent 大多数都能查得到但问题在于互联网上的爬虫远不止这些正规玩家还有很多第三方数据公司、开源项目作者、内容聚合工具在伪装成各种 UA 进行抓取甚至有些直接用无头浏览器模拟真人访问普通防护手段很难拦截。1.2 Cloudflare 视角下的“AI 精神错乱”“Psychosis”这个词听起来有点夸张但从 Cloudflare 安全团队的观察来看AI 带来的流量确实呈现出一种“精神错乱”般的状态请求频率忽高忽低AI 爬虫可能在某几天集中抓取让流量曲线瞬间飙升然后又突然完全消失。UA 频繁变化同一个 IP 段的爬虫会轮换使用不同的 User-Agent甚至伪装成 Chrome 浏览器。抓取路径无规律有的爬虫只抓首页和文章列表有的则会遍历所有详情页、下载附件、读取 robots.txt。正常用户被误伤部分安全策略在拦截 AI 爬虫时会把使用无头浏览器、RPA 工具、海外节点的真实用户一同拦截。这种混乱直接导致了很多站点在 Cloudflare 后台看到的现象Security 事件数量猛增、Bot Score 剧烈波动、缓存命中率下降、源站负载升高。如果你没有一套清晰的 AI 爬虫治理策略很容易在“全拦截”和“全放行”之间反复摇摆。1.3 为什么需要专门治理 AI 爬虫有人会说反正爬虫来了就拦截呗有什么好纠结的但在实际运维中AI 爬虫治理远比想象中复杂。一方面并不是所有 AI 爬虫都该被屏蔽——例如你自己在开发 RAG 应用可能需要放行某些内容抓取工具来构建知识库另一方面有些 AI 爬虫能带来有价值的回源流量比如 Google-Extended 的抓取记录会影响你的内容在 AI 搜索中的出现概率。所以正确的做法不是一刀切而是先摸清这些爬虫的真实行为再分场景配置策略。2. Cloudflare Bots 管理核心概念2.1 Cloudflare 如何识别 BotCloudflare 的 Bot 识别并不是简单检查 User-Agent 就完事而是综合了多种信号User-Agent / JA3 / JA4 指纹JA3 是 TLS 握手指纹JA4 是更精细的 TLS 指纹。Cloudflare 维护了一个庞大的指纹库能识别 headless Chrome、PhantomJS、Selenium 等自动化工具。行为特征请求频率、点击路径、鼠标移动轨迹、页面停留时间、并发连接数等。IP 信誉来自数据中心、主机托管商、代理网络的 IP 权重会很低。JS Challenge 结果Cloudflare 会给可疑请求下发一段 JavaScript 挑战只有真正的浏览器才能通过。基于这些信号Cloudflare 会给每次请求打一个Bot Score机器人评分范围是 1 到 99。分数越低代表是机器人的可能性越大分数越高代表是真实用户的可能性越大。在自定义规则中你可以直接用cf.bot_management.score这个字段来匹配请求。2.2 Bots 管理模式的区别在 Cloudflare 的Security → Bots页面有一个核心选项叫Bots Management Mode。不同套餐支持的模式不同常见的模式包括模式说明适用场景严格Strict)只放行确认的人类流量拦截所有潜在 Bot高安全要求站点宽松Loose)只拦截高置信度的 Bot允许中间分数流量普通内容站点仅记录Log only)只做标记不实际拦截前期观察阶段允许列表模式只拦截明确不在白名单中的 Bot面向 API 业务的站点网络热搜里提到的那条“将 bots management 模式由严格改为...”正是很多站长在 AI 爬虫治理中的第一步尝试因为严格模式下误伤率太高很多渠道的推广流量、移动端浏览器、甚至部分正常爬虫都会被拦导致业务受损。解决方向不是简单地把模式从严格调成宽松而是应该配合自定义规则做精细化分流。2.3 Bot Fight Mode 与 Super Bot Fight Mode在了解自定义规则之前需要先分清 Cloudflare 的几类 Bot 防护能力Bot Fight Mode免费版可用拦截已知的恶意爬虫但是不能自定义。Super Bot Fight ModePro 及以上可用允许你按“已验证 Bot / 已知 Bot / 疑似 Bot”分类处理。Bots ManagementEnterprise 级功能提供详细的 Bot Score 和自定义规则支持。自定义 WAF 规则所有套餐都可以通过 WAF 规则引用 Bot Score实现了类似 Bots 管理的效果。这里要特别说明国内很多站长用的是 Cloudflare 免费版或 Pro 版没有完整的 Bots 管理界面。这种情况下想治理 AI 爬虫最有效的路径是用自定义 WAF 规则 Workers 缓存规则组合来实现。3. Cloudflare 识别 AI 爬虫的几种方式3.1 通过 user-agent 精确匹配最简单粗放的方式是直接匹配已知的 AI 爬虫 UA。Cloudflare 的 WAF 自定义规则支持正则表达式你可以把需要拦截的爬虫 UA 写成一个正则。例如(gptbot|claudebot|bytespider|amazonbot|ccbot|google-extended)这种方式的好处是规则简单、性能好但缺点是依赖 UA 真实性。如果对方每天换 UA或者伪装成普通浏览器那么这条规则很快失效。3.2 通过验证 BotVerified Bots列表Cloudflare 维护了一个“Verified Bots”名单里面包含 Googlebot、Bingbot、GPTBot 等知名爬虫。在 Super Bot Fight Mode 或者 Bots Management 界面里你可以拿这些名单做允许/拦截操作。例如你允许 Googlebot 正常抓取但拦截 GPTBot。这是比较推荐的操作逻辑先基于可信名单放行再对名单外的可疑行为做严格限制。3.3 通过 ASN / IP 信誉很多 AI 爬虫都运行在云厂商的 IP 上比如 AWS、Google Cloud、Azure、DigitalOcean、OVH 等。Cloudflare 的 IP 信誉库会对这些“数据中心 IP”打低分。你可以直接做一个规则如果来源 IP 是数据中心 ASN 且 Bot Score 低于 30就执行拦截或 JS Challenge。但需要注意这种规则容易误伤使用云服务器办公的真实用户因此最好加一些限定条件比如访问目标路径是否为敏感资源。3.4 通过 JS Challenge 分流JS Challenge 是治理 AI 爬虫的“中间路线”不直接拦截而是要求客户端执行一段 JavaScript 来证明自己是浏览器。真正的 AI 爬虫大多不执行 JS因此拿不到cf_clearanceCookie后续的请求都会被拦截。真实用户几乎无感知会看到一次短暂的白屏。在 Cloudflare 自定义规则中一项典型的 AI 爬虫分流策略是如果请求 UA 匹配常见 AI 爬虫 → 执行 JS Challenge。如果 Bot Score 低于 20 且访问路径是文章列表 → 执行 JS Challenge。如果 Bot Score 低于 20 且访问路径是登录页/API → 直接拦截。4. 实战Cloudflare 后台配置 AI 爬虫治理下面进入正题。假设你有一个内容型网站网站托管在 Cloudflare 后面源站在国内服务器或海外服务器均可。你想做三件事观察哪些 AI 爬虫在访问你的网站。阻止部分 AI 爬虫抓取全文但保留搜索引擎收录。避免误伤真实用户和正常的 API 调用。4.1 第一步确认当前 Bots 管理模式登录 Cloudflare 后台在左侧导航找到Security → Bots。如果你看到的是 “Bot Fight Mode” 或 “Super Bot Fight Mode” 页面说明你的套餐还在这些功能范围内。先不要急着改模式而是把当前状态记录下来。比如如果当前是严格模式并且出现了大量误拦截日志可以先把模式切换成仅记录或宽松模式观察几天积累数据。这里需要强调调整 Bots 管理模式一定要在流量低峰期操作并且先在某个域名或某条路径上小范围验证。不要直接对全站执行严格模式否则一旦误伤面扩大严重影响用户访问。4.2 第二步利用 WAF 自定义规则拦截 AI 爬虫在 Cloudflare 后台左侧找到Security → WAF → Custom rules点击Create rule。场景一拦截常见 AI 爬虫抓取文章内容。适合免费版、Pro 版、Enterprise 版因为 WAF 自定义规则在大部分套餐都可以用。规则名称Block AI Crawlers - Content Paths匹配条件(UA contains GPTBot or UA contains ClaudeBot or UA contains Bytespider or UA contains Amazonbot) and URI PATH contains /articles/执行动作Block如果你不确定这些爬虫 UA 的全部值可以加入正则表达式形如(.*)(gptbot|claudebot|bytespider|amazonbot|ccbot|google-extended)(.*)Cloudflare WAF 的自定义规则支持正则表达式但注意正则默认是区分大小写的也可以用matches操作符来达到类似效果。需要说明的是这样直接 Block 会导致这些爬虫在日志里变成 403后续想分析它们的访问行为就看不到了。因此更推荐先做以下“挑战”策略规则名称Challenge AI Crawlers匹配条件使用正则匹配常见的 AI Bot UA。执行动作Managed Challenge这样 AI 爬虫会收到 403 或 challenge 页面不会进入源站而真实用户例如刚好也用了某个爬虫 UA 的发烧友则有机会完成挑战继续访问。4.3 第三步基于 Bot Score 的精细化规则如果你使用的是 Enterprise 或 Pro 套餐可以看到cf.bot_management.score字段。在 WAF 自定义规则中新建如下规则规则名称Low Bot Score - Challenge条件cf.bot_management.score lt 25执行动作Managed Challenge或 JS Challenge这条规则适合绝大多数内容站点。它的含义是只要 Cloudflare 判断该请求极可能是机器人就执行挑战。真实用户即使分数偏低也能通过挑战继续访问而大部分 AI 爬虫并不会执行 JavaScript会在第一步被卡住。但这里有一个常见的坑有些网站使用了一些前端框架例如 Next.js、Nuxt.js 的 SSR 模式页面已经预渲染好了搜索引擎爬虫和 AI 爬虫都能直接抓取到 HTML。如果你设置了上面的低分挑战可能会影响部分搜索引擎爬虫的抓取。解决方法是把搜索引擎的合法爬虫加白名单让它直接跳过挑战。规则可以写成条件 1cf.bot_management.verified_bot条件 2排除常见搜索引擎(cf.bot_management.score lt 25 and not cf.bot_management.verified_bot)也就是说如果请求来自verified_bot比如 Googlebot直接放行否则再看 Bot Score 决定是否挑战。4.4 第四步通过 Workers 加强 AI 爬虫防护有些情况下使用 WAF 规则还是不够灵活。比如你想在 robots.txt 被访问时给 AI 爬虫返回一个特殊内容或者你想在 HTML 响应中注入一个noindex标签仅针对 AI 爬虫或者你想统计 AI 爬虫访问了哪些 URL用于后续分析。这时可以借助 Cloudflare Workers。下面是一个简单的 Worker 代码用来识别 AI 爬虫并返回 403 或者自定义内容// 文件路径workers-ai-bot-blocker.js export default { async fetch(request, env, ctx) { const url new URL(request.url); const userAgent request.headers.get(User-Agent) || ; // 定义 AI 爬虫关键词列表 const aiBotKeywords [ gptbot, claudebot, bytespider, amazonbot, ccbot, google-extended, anthropic-ai, perplexitybot ]; const lowerUA userAgent.toLowerCase(); const isAiBot aiBotKeywords.some((keyword) lowerUA.includes(keyword)); // 如果目标是 robots.txt并且是 AI 爬虫返回一个最小化的 robots 内容 if (url.pathname /robots.txt) { if (isAiBot) { return new Response(User-agent: *\nDisallow: /\n, { headers: { Content-Type: text/plain } }); } // 非 AI 爬虫继续走源站 return fetch(request); } // 如果访问文章页且判定为 AI 爬虫返回 403 if (isAiBot url.pathname.startsWith(/articles/)) { return new Response(Forbidden, { status: 403 }); } // 其他情况正常回源 return fetch(request); } };这个 Worker 示例的思路是先获取请求的 UA 和路径。如果请求的目标是robots.txt那么 AI 爬虫收到的是“全站禁止抓取”的响应。如果 AI 爬虫请求文章列表或详情页则直接返回 403。其他请求正常回源。上线后你可以在 Cloudflare 后台的Workers Pages → 你的 Worker → Triggers → Custom Domains中绑定你的站点域名。为了不影响正式环境建议先绑定一个测试域名或测试路径。4.5 第五步记录 AI 爬虫流量并持续分析无论使用哪种拦截方式都建议开启日志记录。Cloudflare 的Security Events页面会展示所有被 WAF 规则处理的请求包括规则名称、匹配到的 UA、来源 ASN、目标路径等。你可以根据日志不断调整规则。另一个很实用的工具是 Cloudflare 的Analytics → Traffic Analytics里面可以按 Bot Score 分布来查看流量构成。比如你发现“低分请求”占到了 40%那说明你的站正被大量爬虫访问如果这些“低分请求”中真实用户占了不小比例就需要考虑调整 Bot Score 阈值或执行动作为“挑战”而不是“拦截”。5. 完整代码示例Worker 版 AI 爬虫管理面板如果你希望有一个可配置的 AI 爬虫管理方案不希望在 Worker 代码里写死关键词可以用 Cloudflare Workers KV 存储配置列表。下面给出一套更完善的示例。5.1 保存配置到 KV假设你有一个 KV 命名空间叫AI_BOT_CONFIG在 Workers 中绑定为BOT_CONFIG。配置内容可以是一个 JSON 字符串{ blockedKeywords: [gptbot, claudebot, bytespider], challengeKeywords: [perplexitybot, amazonbot], protectedPaths: [/articles/, /docs/] }5.2 Worker 读取 KV 并执行策略// 文件路径worker-kv-ai-bot-manager.js export default { async fetch(request, env, ctx) { const url new URL(request.url); const userAgent (request.headers.get(User-Agent) || ).toLowerCase(); const config await env.BOT_CONFIG.get(config, json).catch(() null); // 默认配置防止 KV 未初始化 const blockKeywords config?.blockedKeywords || [gptbot]; const challengeKeywords config?.challengeKeywords || []; const protectedPaths config?.protectedPaths || []; const isBlocked blockKeywords.some((kw) userAgent.includes(kw)); const isChallenged challengeKeywords.some((kw) userAgent.includes(kw)); const isProtectedPath protectedPaths.some((p) url.pathname.startsWith(p)); if (isBlocked isProtectedPath) { return new Response(Blocked by AI Bot Manager, { status: 403 }); } if (isChallenged isProtectedPath) { // 简易挑战逻辑要求带上指定的查询参数 if (url.searchParams.get(challenge) ! passed) { return new Response(Challenge failed, { status: 401 }); } } return fetch(request); } };这种方式的优点是配置在 KV 中不需要每次修改代码。你可以在 Cloudflare 后台手动更新 KV 值也可以通过一个管理接口去更新。5.3 使用 Crontab 定期同步 AI 爬虫 IP 列表除了 UA 匹配你还可以把已知的 AI 爬虫 IP 段保存到 KV 中然后用 Workers 定期拉取某个可信源来更新。Cloudflare Workers 支持 Scheduled Triggers定时触发器下面这段代码演示了定时拉取一份远程 IP 列表并写入 KV// 文件路径scheduled-sync-bot-ips.js export default { async scheduled(event, env, ctx) { const resp await fetch(https://example.com/ai-bot-ips.json); // 这里替换为你的可信源 const data await resp.json(); // 假设 data.ips 是一个字符串数组 await env.BOT_CONFIG.put(blockedIps, JSON.stringify(data.ips || [])); console.log([sync] updated ${data.ips?.length || 0} IPs); }, async fetch(request, env, ctx) { const clientIp request.headers.get(CF-Connecting-IP) || ; const blockedIps JSON.parse((await env.BOT_CONFIG.get(blockedIps)) || []); if (blockedIps.includes(clientIp)) { return new Response(Blocked, { status: 403 }); } return fetch(request); } };需要注意不要让 Worker 定时任务去访问不可靠的来源否则恶意攻击者可能通过控制该来源来批量封禁真实用户 IP。6. 常见问题与排查思路6.1 我用了严格模式为什么还有 AI 爬虫能访问严格模式并不是“万能锁”。如果 AI 爬虫使用了真实的浏览器指纹例如用 Puppeteer 开启 stealth 插件或者通过住宅代理 IP 访问Cloudflare 很难识别。排查思路如下打开 Security Events确认拦截日志里是否有该请求。如果没有拦截日志说明请求被其他规则放行了比如 Page Rules 或 WAF 规则优先级更高。尝试把该请求的 IP 放入 Firewall Rules 的 IP Access Rules 做一次手动拦截验证。如果手动拦截后该爬虫仍然能访问则考虑请求并未经过 Cloudflare可能 DNS 解析未生效或存在多条 A 记录。6.2 调整模式之后为什么网站搜索流量下降了这通常是因为某些搜索引擎爬虫也被你的规则误伤。比如你把“严格模式”打开后像 Yandex、Baidu 这类爬虫如果不在 Cloudflare 的 Verified Bots 列表里就会收到 JS Challenge导致抓取失败。解决方案在 WAF 规则中增加白名单(cf.bot_management.verified_bot)或指定 UA 放行。或者把 Bots 管理模式从“严格”降到“宽松”观察一周再看搜索流量是否恢复。6.3 Managed Challenge 会不会影响用户留存会但影响很小。大部分真实用户会在毫秒级完成 JS 挑战几乎无感知。只有两种情况影响明显用户手机浏览器版本过旧无法执行新版 JS 挑战。用户网络环境屏蔽了 cf_clearance Cookie。建议针对移动端 UA 或者特定地理区域适当降低挑战概率例如只对高风险路径启用挑战。6.4 如何确认某个 UA 是不是 AI 爬虫可以通过下面的方式判断搜索该 UA 对应的官方文档看是不是公开的模型服务商爬虫。检查访问频率单个 IP 在短时间内发起超过 50 次请求基本可以断定是爬虫。查看访问路径如果只访问文章页、图片资源、PDF 文件不访问首页和 JS/CSS大概率是内容采集爬虫。6.5 使用表格总结常见问题问题现象常见原因解决思路严格模式下正常用户被拦截低版本浏览器/移动设备无法通过 JS Challenge将动作改为 Managed Challenge并按 UA 加白AI 爬虫仍然访问使用真实浏览器指纹或代理 IP增加 IP 信誉规则结合 ASN 和 Bot Score 做多维判断robots.txt 被频繁抓取爬虫在探测抓取边界对 robots.txt 做缓存并给 AI 爬虫返回 Disallow 内容源站负载飙升大量爬虫绕过 CDN 直接访问源站在源站安全组中仅放行 Cloudflare IP 段搜索收录减少合法爬虫被 WAF 规则拦截放行 Verified Bots或调整 Bot Score 阈值7. 最佳实践与工程建议7.1 不要在白天直接切换严格模式如果你打算把 Bots 管理模式从“宽松”切换到“严格”建议选择凌晨流量低峰期操作并且提前在测试路径上用自定义规则模拟。生产环境中的任何安全策略变更都应有回滚方案。Cloudflare 后台有“审核日志”功能操作前建议截图保存当前配置。7.2 用好 Cache 规则减轻源站压力AI 爬虫最可怕的地方在于高频遍历页面。即使你通过 Bot Score 做了挑战挑战请求本身也会消耗一定的边缘资源。更优的做法是对文章页、列表页设置合理的 Cache Rule让匿名请求直接命中 Cloudflare CDN 缓存源站只接收少量回源请求。例如HTML 页面 TTL 设为 300 秒。对带有sitemap关键词的路径不做缓存保证搜索引擎收录更新。对 API 路径设置按需缓存或完全绕过缓存。7.3 配置源站层白名单防止绕过 CDN有一部分 AI 爬虫会探测源站 IP并绕过 Cloudflare 直接访问源站。这是很多站长最容易忽略的风险点。建议在源站服务器安全组或防火墙中做以下限制只允许 Cloudflare 官方 IP 段访问 80/443 端口。禁止来自非 Cloudflare IP 的 HTTP 请求。定期查看源站访问日志寻找可疑的源站 IP 探针。在服务器防火墙中可以用如下思路以 UFW 为例# 只允许 Cloudflare IP 段访问 80/443 for ip in $(curl -s https://www.cloudflare.com/ips-v4); do sudo ufw allow from $ip to any port 80 proto tcp sudo ufw allow from $ip to any port 443 proto tcp done # 拒绝其他 IP 访问 80/443 sudo ufw deny 80/tcp sudo ufw deny 443/tcp执行前记得先保留 SSH 端口默认 22的放行规则避免把自己锁在外面。7.4 不要全盘照搬别人的拦截列表每个网站的内容类型、用户群体、SEO 需求都不一样。别人拦截 GPTBot不一定适合你。比如有的工具站希望被 AI 产品收录从而获得 AI 搜索流量那就应该放行 GPTBot 和 ClaudeBot。建议把 AI 爬虫分成三类分别设置策略分类示例推荐策略搜索引擎爬虫Googlebot、Bingbot、Baiduspider放行纳入 Verified Bots模型训练爬虫GPTBot、ClaudeBot、Bytespider默认拦截但可根据业务放行第三方采集工具自定义 UA 或匿名爬虫低 Bot Score 请求执行 Managed Challenge7.5 定期复盘日志动态调整规则AI 爬虫的 UA 和 IP 段是动态变化的。建议建立一个每周复盘流程导出 Security Events 中过去 7 天的拦截数据。找出仍然成功请求源站的疑似 AI Bot 请求。更新 Worker 里的关键词列表或 WAF 正则。检查是否有真实用户被误伤及时加入白名单。如果站点规模较大可以通过 Cloudflare 的 Logpush 功能将日志推送到对象存储或日志分析平台做更精细的统计和告警。8. AI 时代的防护心态与学习建议AI 爬虫治理这件事本质上是一场动态博弈。今天你拦截了 GPTBot明天可能出现新的 Anthropic 爬虫今天你放行了 Perplexity后天它的抓取策略可能变成模拟真实用户。想靠一套静态规则永久解决问题是不现实的。但这不是说我们只能被动挨打。通过 Cloudflare 的 WAF、Bots 管理、Workers、缓存规则和源站防护等多层组合完全可以构建一套相对稳定的防护体系。核心心法是先观察再分流最后拦截。刚开始把所有 AI 爬虫都设置为“仅记录”了解它们的行为特征。一周后基于日志制定黑白名单对高置信度爬虫执行挑战。一个月后再结合源站日志和搜索流量变化做动态微调。如果你正在深入学习 Cloudflare 的安全体系下一步可以关注以下几块内容Cloudflare WAF 自定义规则的表达式语法和优先级。Workers 的定时触发器和 KV 存储构建动态防护策略。Cache Rules 和 Cache Reserve 的配合使用。Logpush 和 Workers Analytics 做流量监控。Cloudflare Tunnel 隐藏源站 IP彻底隔绝绕过流量。这中间最容易踩坑的是规则优先级问题。Cloudflare 的执行顺序大致是WAF 自定义规则 → Rate Limiting → 防火墙规则 → 页面规则 → Worker → Cache 规则。你要对某条请求做拦截最好在 WAF 自定义规则这一层完成因为它的日志展示最直观排错最方便。另外不要忽视安全变更的灰度发布。任何 WAF 规则都可以先设置成“Log”模式观察一段时间后再切换成“Block”模式。Cloudflare 后台支持规则切换配合“模拟”的方式可以极大降低误伤风险。不管你是个人站长还是企业平台的技术负责人AI 爬虫治理都不应该通过“一刀切”解决。结合站点类型、内容价值、用户画像和搜索需求制定属于自己的分层策略才是健康可持续的做法。希望这套基于 Cloudflare 的 AI Bot 治理方案能帮你在 AI 流量浪潮中站稳脚跟。