如果你的业务用了 Cloudflare或者你写过脚本访问过某个套了 Cloudflare 的站点大概率见过这台“拦路虎”Were sorry... but your computer or network may be sending automated queries.初次遇到这个提示很容易以为只是普通的 403 或证书异常。实际上这是 Cloudflare 的机器人管理在起作用它判断这次访问不是“真人浏览器”于是直接在源站前面把流量挡了下来。更麻烦的是随着 AI 代理这类“computer use”方案普及自动化访问的形式越来越接近真实用户误伤和对抗也变得复杂。这篇文章不讲怎么绕过 Cloudflare也不教怎么破解验证码。只讲四件事Cloudflare 通过哪些维度判定你是“自动化流量”AI Agent / Computer Use 流量为什么会被单独识别作为站长在 Cloudflare 后台怎么把 Bots 相关模式调明白作为开发者遇到 automated queries 提示时该怎么验证、排查和合规接入。内容偏实操建议收藏备用。1. Cloudflare 与 Computer Use 核心能力速览先把 Cloudflare 在“机器人管理 AI 代理识别”方向上的能力梳理清楚。Cloudflare 不只是 CDN它最大的价值之一是在边缘节点直接完成流量分类和拦截几乎不消耗源站资源。能力项对应模块面向套餐一句话说明Bot Fight ModeSecurity → Bots免费版拦截明显来自数据中心的自动化攻击流量Super Bot Fight ModeSecurity → BotsPro / Business区分“已确认 Bot”和“疑似 Bot”分别设置处理动作Bot ManagementSecurity → BotsEnterprise提供 0-99 的 Bot Score可写细粒度规则Turnstile验证码服务所有开发者无感或轻量验证替代传统 CAPTCHAWAF 自定义规则Security → WAF全套餐按 UA、IP、ASN、国家等条件放行或拦截AI Agent 检测Bot 分类与日志企业版为主部分能力下放识别 Claude Computer Use、OpenAI Operator 等 AI Agent 流量这套能力体系的核心逻辑并不复杂Cloudflare 在边缘节点上看你“怎么访问”而不是只看到你“访问了什么”。你的 TLS 指纹、HTTP/2 指纹、浏览器指纹、请求频率、鼠标行为、IP 信誉全部会被折算成一个风险分。分数够低放行分数可疑弹验证码分数过低直接拦截。需要说明的是不同的 Cloudflare 套餐在后台看到的内容差别很大。免费版只有 Bot Fight Mode企业版才有完整的 Bot Management。本文以“实际仪表盘呈现为准”不把某个按钮写死。2. automated queries 提示是怎么产生的看到 “your computer or network may be sending automated queries” 这个页面时你实际上是被 Cloudflare 的挑战流程拦住了。Cloudflare 不会把你的请求直接交给源站而是返回一个验证页要求你证明自己是浏览器操作者。这个判断通常来自以下维度IP 信誉。数据中心 IP、代理 IP、曾经发起过高频攻击的 IP天然低分。TLS 指纹。requests、curl、Scrapy 等库使用的 TLS 指纹和 Chrome、Edge 明显不同即便你伪造了 User-Agent 也能被识别。HTTP/2 指纹。不同浏览器和服务端的 HTTP/2 帧排序、SETTINGS 参数不一样自动化库通常不具备完整的浏览器特征。JS 环境。浏览器会执行 JavaScript并能通过 Canvas、WebGL、字体等生成稳定的指纹。无头浏览器在这些维度上容易露馅。行为节奏。真人进入页面后会先浏览再操作鼠标轨迹是非线性、有停顿的脚本往往是瞬间请求、瞬时点击。请求频率。同一 IP 在短时间内大量请求同一页面会直接触发速率限制。需要特别说明的是这些维度并不是每次都同时生效。很多情况下你只是 IP 信誉或 TLS 指纹一关就没过连后面的 JavaScript 挑战都没机会执行。从用户侧看这个拦截页面有两种状态。一种是无感的Cloudflare 在后台执行 JS 挑战通过后自动跳回原页面用户几乎感知不到。另一种是显性的页面明确要求点击 Turnstile 验证框或者直接显示拒绝访问。自动化流量通常走不到无感放行那一步所以会直接卡在验证页上。这里要划一条合规边界看到这个提示如果你访问的是别人的站点正确做法是联系站点管理员、使用官方 API 或遵守站点条款而不是研究和破解 Cloudflare 的验证流程。本文后面的命令示例仅用于排查你自己站点或你自己有权限访问的服务的防护状态。3. Computer Use 时代AI Agent 为什么被单独分类传统的爬虫是直接发 HTTP 请求拿回 HTML 再解析。它的行为特征和真人差异巨大Cloudflare 用频率 TLS 指纹就足以识别。但 2025 年最大的变化是 “computer use” 类 AI Agent 出现了。Claude Computer Use、OpenAI Operator 这类方案不是直接调 API而是像人一样操作浏览器打开页面、移动鼠标、点击按钮、朗读页面内容、根据截图决策下一步。这种流量具备完整的浏览器指纹有 JS 执行环境行为节奏也更接近真人传统爬虫识别方案很难直接区分。于是 Cloudflare 的做法是把 AI Agent 当作一种新的 Bot 类型来分类。它可以通过 User-Agent 字符串例如 oai-agent、claude-computer-use 等标识、TLS 指纹、访问模式、点击行为等组合特征标记出“当前请求来自 AI Agent”。站长可以在后台查看这些 Agent 的访问记录决定放行、拦截、限速还是仅记录。这对站长有实际意义。以前你只需要考虑搜索引擎要不要放行现在你还要考虑Claude 的 computer use 要不要允许GPTBot 来了是给流量还是给爬虫AI Agent 如果绕过登录态操作你的网页会不会产生数据泄露这些决策都需要依赖 Bot 分类能力去做而不是靠日志里一把抓。从 Cloudflare 官方释放的信息来看AI Agent 识别已经进入 Bot 管理体系中并且在不断补充新的 Agent 类型。这也意味着即便你用最顶配的浏览器自动化框架只要 Cloudflare 将你的流量归到已知 AI Agent 分类下依然可能被精准处理。4. Cloudflare 后台 Bots 配置从严格到宽松这一节是站长视角。登录 Cloudflare 后台后进入 Security → Bots你会看到当前套餐可用的机器人管理产品。免费版通常只有简单的 Bot Fight ModePro/Business 有 Super Bot Fight Mode企业版有更完整的 Bot Management。4.1 Bot Fight ModeBot Fight Mode 是免费版的兜底方案。它会把明显来自数据中心的自动化攻击流量拦截掉同时通过验证码挑战疑似 Bot。对个人站点来说开着这个模式能明显减少垃圾评论、漏洞扫描和盗刷流量但要注意它也可能误伤来自海外数据中心 IP 的真实访客。如果你发现有正常访客被拦优先关闭该模式并改用更精确的 WAF 规则。4.2 Super Bot Fight ModePro/Business 套餐可以进一步把 Bot 分成“已确认”Definitely Automated和“疑似”Likely Automated两类分别设置“允许、拦截、绕过、日志”等动作。这里的“绕过”含义是让流量直接到达源站不经过挑战和验证。对于验证码服务商、支付回调、搜索引擎爬虫这类需要直连的流量绕过是合理的但如果把所有“疑似 Bot”都设置成绕过等于放弃了防护风险较高。4.3 从严格调整到宽松的正确姿势很多教程会建议如果某个业务被 Cloudflare 拦截就把 Security → Bots 里的模式由“严格”调整为“宽松”。这个做法在技术上是可行的但直接切换会比较危险。更稳妥的流程是先通过日志或 Analytics 确认被拦截流量的来源是特定 UA特定 IP 段还是特定 ASN在 WAF 自定义规则里先放行这些精确条件而不是整体放开 Bot 模式。观察 24-48 小时确认没有引入垃圾流量再决定是否调整全局 Bot 模式。如果业务本身是 API 服务不建议依赖 Bots 模式放行正确的做法是用 API Token 或 mTLS 做身份认证。4.4 放行合法 AI Agent如果站长希望允许特定的 AI Agent 访问可以在 WAF 自定义规则中按 User-Agent 放行规则方向条件示例动作放行搜索引擎user-agent contains googlebotAllow放行 AI 代理user-agent contains GPTBot or Claude-WebAllow拦截未知 Botcf.bot_management.verified_bot equals falseBlock仅记录不拦截cf.bot_management.score less than 30Log同样需要提醒放行 AI Agent 意味着你的页面内容可能被用于模型训练或自动化采集。建议在放行前明确自己的版权和隐私边界必要时在 robots.txt 中声明禁止抓取。5. 用命令行判断自己是否被识别为 Bot下面给出一套通用的自查流程适合站长确认“我的 Cloudflare 防护是不是误拦了正常请求”。这些命令只用于检查自己站点的防护状态不要拿去探测或绕过他人服务。5.1 先看响应头# 用浏览器 UA 访问站点观察响应头中的 Cloudflare 字段 curl -sI \ -A Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0.0.0 Safari/537.36 \ https://example.com正常通过 Cloudflare 的请求响应头通常包含server: cloudflare、cf-ray、cf-cache-status等字段。如果出现cf-mitigated: challenge或cf-mitigated: block说明请求触发了 Cloudflare 的挑战或拦截逻辑。5.2 用自动化库复现异常import requests # 仅供参考用于观察自动化请求的响应差异 headers { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0.0.0 Safari/537.36 } resp requests.get(https://example.com, headersheaders, timeout10) print(status:, resp.status_code) print(server:, resp.headers.get(server)) print(cf-ray:, resp.headers.get(cf-ray)) print(cf-mitigated:, resp.headers.get(cf-mitigated)) if cf-chl in resp.text or turnstile in resp.text: print(触发验证码/挑战页)如果浏览器访问正常、requests 访问异常基本可以确认问题不在源站而在 Cloudflare 的 Bot 识别维度上。此时优先检查 IP 信誉和 TLS 指纹而不是盲目换 IP。5.3 查看 Turnstile 校验结果Turnstile 是 Cloudflare 的验证码服务。如果你在自己的站点接入 Turnstile可以通过服务端接口校验 tokenimport requests # 服务端校验示例secret 需要从 Cloudflare 后台获取 data { secret: 0x4AAAA..., # 替换为你的 secret response: 前端传入的 turnstile token, } resp requests.post( https://challenges.cloudflare.com/turnstile/v0/siteverify, datadata, timeout10, ) print(resp.json())返回结果中的success字段为true表示验证通过false表示 token 无效或已过期。常见失败原因是前端 token 未刷新、secret 配置错误、时钟不同步。6. 开发者合规接入和 Cloudflare 防护共存如果你是开发者正在开发需要访问某个被 Cloudflare 保护的站点的工具下面这些方法才是可持续的合规路径。6.1 优先使用官方 API绝大多数对外服务都会提供 API。Cloudflare 保护的站点不等于禁止程序化访问而是禁止“伪装成浏览器的未授权程序化访问”。正确做法是找对方的技术文档申请 API Key按接口规范调用。# 示例调用 Cloudflare 官方 API 查询站点安全事件通用模板需替换 zone_id 和 token curl -X GET https://api.cloudflare.com/client/v4/zones/{zone_id}/security/events \ -H Authorization: Bearer ${CF_API_TOKEN} \ -H Content-Type: application/json具体接口路径和参数以 Cloudflare API 文档为准不要照搬猜测。API 返回的 JSON 建议用jq做字段过滤避免在大流量环境下刷屏。6.2 控制频率和 User-Agent如果必须访问 HTML 页面至少要满足几个前提频率控制在人类操作量级、使用可联系的真实 User-Agent、遵守 robots.txt 和站点服务条款。不要用同一个 IP 在短时间内并发请求几十个页面。6.3 关闭不必要的自动挑战这里所说的“关闭”是指站长自己站点的配置。如果你的业务服务本身没有强风控需求可以在 WAF 规则里把来自特定可信 IP 段的请求设为 Allow从而跳过挑战。不要通过修改 UA 或伪造指纹去强行突破他人的防护。# robots.txt 示例明确声明 AI 代理是否允许抓取 User-agent: GPTBot Disallow: / User-agent: Claude-Web Disallow: / User-agent: * Allow: /6.4 合理使用 TurnstileTurnstile 的价值在于它在验证时不打断正常用户。如果你在做一个公开工具不希望正常用户看到传统验证码可以把 Turnstile 接入进来用法类似 Google reCAPTCHA但配置更轻也不需要域名预注册。7. 资源占用与性能观察Cloudflare 的 Bot 管理不仅能拦截恶意流量还能显著降低源站压力。对运维来说观察性能时重点看四个指标安全事件数量。Cloudflare Analytics 的 Security 事件可以看到被 WAF、Bot Fight Mode、速率限制拦截的请求数。缓存命中率。如果缓存命中率高源站 CPU 和带宽压力会明显下降。源站带宽。对比开启 Bot 拦截前后的源站出流量是比较直观的收益数据。挑战页耗时。Turnstile 或 JS Challenge 如果耗时过高会影响真实用户访问体验需要关注边缘节点延迟和本地网络到最近 Cloudflare 节点的延迟。有一个常见误解是“Cloudflare 加了速度一定会变慢”。实际上动态内容在边缘节点做安全检测通常只增加几十毫秒级别延迟静态资源因为缓存命中反而会更快。如果出现大面积访问变慢先看是不是所有请求都在走源站回源再看是不是 WAF 规则里加了过多复杂条件导致边缘计算开销增加。性能观察不需要等到出问题再开始。建议提前在 Cloudflare 后台开启日志记录保存异常访问样本用于后续排查。免费版的日志保留时间有限重要业务建议通过 Logpush 把日志转到自己的对象存储中。8. 常见问题与排查方法问题现象可能原因排查方式解决方案访问出现 were sorry... 提示请求被 Cloudflare 判定为自动化查看响应头和 cf-ray确认是否出现 cf-mitigated使用浏览器环境访问确认 IP 信誉有权限时调整 WAF 规则自己站点把搜索引擎爬虫拦截了Super Bot Fight Mode 对未认证爬虫做了拦截Cloudflare 后台查看 Bot 分析日志在 WAF 规则中按 UA 放行 googlebot、bingbot自动化脚本请求返回 403TLS 指纹或 UA 被识别用 curl 和 requests 分别测试对比响应使用官方 API降低请求频率不要伪造浏览器 UA 硬闯验证码 Turnstile 一直不通过前端 token 过期或 secret 不匹配查看 siteverify 返回的 error-codes刷新 token检查 secret避免代理 IP 触发风控开启严格 Bot 模式后正常用户也掉线误判风险较高查看被拦截请求的 IP、UA、ASN 分布逐步调整规则先日志后拦截源站带宽仍然很高大量动态请求无法缓存看缓存命中率和回源统计调整 Cache Rules对 API 接口单独配置缓存策略日志中看不到 Bot 分类数据套餐或企业版功能未开启查看账单和套餐权限功能权限以 Cloudflare 套餐为准可咨询官方销售AI Agent 访问自己站点无法识别当前配置未开启 AI Agent 分类检查 Bots 分析页面升级套餐或使用 WAF 规则按 UA 主动匹配排查时要特别注意Cloudflare 的免费版和付费版看到的数据差异很大很多高级分析字段在免费版中不可用。不要因为免费版面板没有某类数据就误判为“没有机器人访问”。9. 最佳实践与合规建议到这里把 Cloudflare 与 Computer Use 相关场景下的工程化建议汇总一下。先看清楚流量再动手。不要因为几条障碍请求就全局关闭防护优先用 WAF 规则处理例外。配置 Bots 模式时先在“仅日志”模式下观察一天。确认拦截目标和误伤范围再切换到正式动作。把模型、输入、输出和日志分目录管理。无论是站点的分析日志还是自动化工具的抓取结果都要有清晰的审计路径。批量任务一定要加日志和失败重试。Cloudflare 的速率限制可能在你毫无预兆的情况下触发重试和退避策略是刚需。接口服务要限制访问范围。除非业务需要不要把自己的 Cloudflare API Token 暴露在公网代码中。涉及人脸、声音、版权素材、个人数据的自动化处理必须确认授权。Cloudflare 防护只能挡住机器流量挡不住“非法使用授权”带来的法律风险。发布或商用前做效果复核。尤其是用 computer use 类 AI Agent 操作网页时要确认对方站点是否禁止自动化访问。从合规角度看最值得牢记的一句话是Cloudflare 的 Bot 管理机制是为了保护站点的访问边界而不是鼓励你去破解边界。站长可以自由配置自己的防护策略但开发者无权绕过别人的防护。10. 总结Cloudflare 已经从单纯的 CDN进化为能识别传统爬虫、无头浏览器和 AI Agent 的边缘安全平台。对站长来说最新的变化是你需要决定是否放行 GPTBot、Claude Web 和各类 computer use 代理而不是简单地开关一个全局开关。这篇文章最值得记住的两个点一是 “were sorry... automated queries” 大概率是 Cloudflare 的 Bot 识别结果不是源站故障二是调整 Bots 模式时要低调、精确、灰度不要直接从严格一刀切到宽松。最容易踩的坑是用 requests 或 curl 去测试被 Cloudflare 保护的页面然后把“测试失败”当成“网站挂了”。正确做法是用真实浏览器先确认站点可用性再用命令行排查差异来源。下一步你可以做三件事登录 Cloudflare 后台确认自己套餐暴露了哪些 Bots 功能看一眼近 7 天的安全事件日志识别被拦截流量的组成如果有 AI Agent 访问需求先在 WAF 规则里用“仅记录”模式观察一天再决定放行策略。这篇就到这里建议收藏备用。