访问很多站点时可能会遇到一个让人摸不着头脑的页面标题写着 “Were sorry...”正文是 “but your computer or network may be sending automated queries.”。第一反应通常是“网站是不是挂了”或者“是不是我的 IP 被拉黑了”。实际上这大概率是 Cloudflare 安全防护在起作用它把当前请求识别成了自动化流量然后直接拦截。这个提示正在变得越来越常见原因也很简单一方面Cloudflare 背后有大量的自动化流量识别逻辑另一方面现在访问网站的远不止真人浏览器还有爬虫、监控脚本、CI/CD 任务、RPA 工具以及最近很火的 “Computer Use” 类 AI 代理。当这些东西撞上 Cloudflare 的 Bot 防护就会看到那段熟悉的 “automated queries” 提示。本文要解决的问题比较明确搞清楚 Cloudflare 为什么把请求识别成自动化流量遇到误拦截时如何从后台排查以及当你确实需要放行“合法自动化流量”时应该怎么配置。文章会围绕 Cloudflare 后台的 Security → Bots 相关功能展开同时给出 WAF 规则、API 查询、Python 请求侧的完整示例。需要提前说一句本文只讨论“你自己的站点”或“你已获授权的系统”的防护配置任何绕过他人网站防护的操作都不在讨论范围内。1. “Were sorry” 是什么错误它代表什么状态先看这段提示的完整含义。当你在浏览器或脚本里访问一个接入了 Cloudflare 的网站Cloudflare 的安全引擎会先对请求做一次评估。如果它认为这个请求不是真人浏览器发出的以下两种处理方式最常见返回验证页要求完成 Managed Challenge 或 JS Challenge直接返回 403 拦截页页面内容就是 “Were sorry... but your computer or network may be sending automated queries.”从 HTTP 状态码看第二种情况通常是403 Forbidden响应头里能看到server: cloudflare同时会带一个cf-ray标识用来在后面排查时定位具体请求。从 Cloudflare 的产品逻辑看触发这个拦截的源头不一定是单一个功能。可能是 Bot Fight Mode机器人对抗模式可能是 WAF 自定义规则也可能是企业版的 Bot Management 对请求做了实时评分分数过低后触发了拦截。这里容易产生一个误解有人觉得只要把 Cloudflare 的“安全级别”调低或者关掉 “Under Attack Mode”就能解决所有拦截问题。这种想法不完全错但不准确。Cloudflare 的防护体系是分层的Bot 相关拦截和全局安全等级并不是同一层。下面把常见响应方式先列出来响应形式HTTP 状态用户看到的结果典型触发场景JS Challenge403 但通过后放行短暂等待后进入页面请求头和行为特征不符合真实浏览器Managed Challenge403 或 429出现交互式验证页面威胁评分处于中间区域需要进一步验证Block拦截403直接看到 Were sorry 提示威胁评分很高或命中明确规则Allow放行200正常访问命中白名单规则所以第一次看到 “Were sorry” 时不要急着改代码。先在浏览器里访问同一个地址看是否正常。如果浏览器正常、脚本异常那说明 Cloudflare 不是在针对“这个网站”而是在针对“这个请求的特征”。2. Cloudflare Bot 管理的核心机制与常见误区2.1 什么是 Bot 管理Cloudflare 的 Bot 管理本质是一套“请求信任评估”系统。它不只是看 User-Agent 这种容易伪装的字段而是综合多个维度给请求打分请求来源 IP 的信誉度TLS 指纹JA3/JA4是否与真实浏览器一致HTTP 头顺序、大小写、是否缺少常见头请求频率和路径行为是否渲染 JavaScript、是否执行浏览器环境特征ASN、数据中心 IP、代理 IP 等网络属性。换句话说Cloudflare 判断的不只是“你是谁”而是“你像不像一个真实用户”。在后台配置上Cloudflare 提供了几个层次的功能。免费套餐常见的是 Bot Fight Mode它会把识别出的自动化流量引导到一个虚假的不可用页面更高级的套餐可能有 Super Bot Fight Mode 或 Bot Management后者支持更细粒度的阈值和规则比如按请求路径、按 IP、按 UA 分别设置处理方式。2.2 “严格模式”到底严格在哪里很多人在后台看到 Bots 相关的选项可能会有类似“Bot Management 模式由严格改为...”这种描述。这里的“严格”通常指对可疑请求的处理力度宽松模式对可疑流量只做监控或打标记尽量不拦截标准模式对明确是 Bad Bot 的流量做 Challenge 或 Block严格模式对评分不高的请求也采取较强处理宁可误杀也不放行。如果确认自己的站点强依赖 API、自动化运维脚本、无头浏览器访问那“严格模式”确实容易造成误伤。但从安全角度讲全局调低模式不是首选方案更推荐的做法是用 WAF 规则做精确放行这一点后面会专门演示。2.3 关于绕过拦截的三个误区误区一换一个 Chrome 的 User-Agent 就能通过。能通过一些简单规则但 Cloudflare 会继续看 TLS 指纹、访问频率、行为路径只改 UA 很快会再次被识别。误区二关掉所有安全功能最省事。这会同时关掉对恶意流量的防护站点可能面临更实际的攻击风险。生产环境不建议这么做。误区三既然提示 “automated queries”说明 Cloudflare 禁止一切自动化。不是这样。Cloudflare 本身提供了大量 API、Bot 管理配置和安全事件查询能力目的就是让合法自动化可控地运行。关键是你有没有把自己的自动化流量“声明清楚”。3. 遇到误拦截时的排查流程当你的脚本或 AI Agent 被 Cloudflare 拦截时不建议上来就改配置。先用下面这套顺序排查大部分情况都能定位到原因。3.1 用 curl 复现并查看响应头先看服务器返回了什么。以 Linux/macOS 终端为例curl -I -A MyMonitorBot/1.0 https://example.com/api/status观察响应头里是否有cf-mitigated字段以及状态码是否为 403。某些情况下还会看到cf-challenge、cf-ray字段。把cf-ray记下来后续在 Security Events 里可以直接搜索。3.2 打开 Security Events 看拦截原因登录 Cloudflare Dashboard进入对应域名Security → Events然后在过滤条件里搜索自己的cf-ray或者按 IP、按请求路径过滤。Cloudflare 会在事件详情里标明命中服务可能是WAF命中了自定义规则或托管规则Bot Management请求威胁评分过高Super Bot Fight Mode判定为已知 Bad BotRate Limiting请求频率超过限制。这一步是整个排查过程里最重要的一步。很多人的问题是“改了半天空然无效”原因就是没有看安全事件而是凭感觉在猜。3.3 检查全局安全等级和 Under Attack Mode在 Dashboard 的Security → Settings可以看全局 Security Level。如果站点开启了 “Under Attack Mode”攻击模式那几乎每个请求都会经历一段 JavaScript 挑战自动化工具很容易被挡在外面。这时即使是合法运维脚本也需要先解决挑战问题。3.4 检查请求侧特征如果 Security Events 显示请求被标记为自动化流量可以对照检查请求头是否缺失常见浏览器头比如Accept-Language、Accept-EncodingUser-Agent 是否为空或过于简单请求频率是否明显高于普通用户来源 IP 是否属于机房、云服务商、数据中心 IP 段是否使用了无头浏览器默认配置。3.5 区分“拦截”和“挑战”还需要区分两种状态如果返回的是 403 页面说明请求被 Block如果返回的是验证页、或者浏览器里出现“Verify you are human”说明被 Challenge。Challenge 通常是高评分但没到直接拦截的程度Block 则是评分更低。排查到这一步基本能判断问题出在哪一层。下面进入配置层面的处理。4. Cloudflare 后台 Bots 管理模式的配置方式4.1 后台入口Cloudflare Dashboard 的路径如下域名 → Security → Bots在这个页面里可以配置 Bot Fight Mode 或 Bot Management 模式。不同套餐能看到的选项不一样这很正常。你需要关注的是是否开启了 Bot Fight Mode当前 Bot Management 的处理力度是否配置了静态规则放行或拦截指定 IP / UA / ASN。4.2 模式调整的保守做法如果你确认当前模式过严可以把处理模式从“严格”调整到“标准”或“宽松”。但我不建议只做这一步因为全局放宽后之前被挡住的恶意流量也可能一起放进来。更稳妥的思路是保留全局 Bot 防护在 WAF 里给已知的合法自动化流量加白名单用 Security Events 持续确认白名单规则是否生效。4.3 用 WAF 自定义规则做精确放行Cloudflare WAF 支持自定义规则。下面是一个示例表达式它只放行同时满足以下条件的请求请求方式是 GETUser-Agent 包含MyMonitorBot来源 IP 属于你自己的运维出口 IP。在 Dashboard 的Security → WAF → Custom rules → Create rule规则表达式可以写成(http.request.method GET and http.user_agent contains MyMonitorBot and ip.src in {203.0.113.10})动作选择Skip并勾选跳过后续的安全组件例如Skip → All remaining custom rules Skip → Bot Fight Mode这样做的好处是只有满足条件的请求会被放行其他流量仍然走原来的安全策略。如果希望通过 Cloudflare API 创建同一条规则可以用类似下面的请求curl -X POST https://api.cloudflare.com/client/v4/zones/$ZONE_ID/rulesets \ -H Authorization: Bearer $CF_API_TOKEN \ -H Content-Type: application/json \ --data { rules: [ { expression: (http.request.method \GET\ and http.user_agent contains \MyMonitorBot\ and ip.src in {203.0.113.10}), action: skip, description: Allow internal monitor bot } ] }需要注意API 的完整路径和参数会随套餐、产品版本变化使用前以 Cloudflare 官方 API 文档为准。生产环境操作前建议先在测试域名上验证规则效果。5. 给合法自动化工具和运维脚本放行的完整示例这一节给一个可落地的组合方案。假设你运营一个站点需要在固定服务器上运行健康检查脚本并且希望这个请求不被 Cloudflare 拦截。5.1 第一步给请求一个清晰的身份不要用空 UA也不要用和真人浏览器完全一样的 UA。设置一个包含站点标识和联系方式的身份头既方便 Cloudflare 规则识别也方便后续审计。在 Python 中推荐这样定义请求会话# monitor.py import time import requests MONITOR_UA ExampleSiteMonitor/1.0 (https://example.com/bot-info) MONITOR_FROM opsexample.com session requests.Session() session.headers.update({ User-Agent: MONITOR_UA, From: MONITOR_FROM, Accept: application/json, })把User-Agent和From头写清楚是降低被误判概率的第一步。Cloudflare 的规则也更容易在这种特征上做精确匹配。5.2 第二步按“IP UA 路径”做 WAF 放行前面 WAF 规则里我建议的是 IP UA 组合。从安全角度讲IP 属于强约束可以避免某个 UA 标识被其他人冒用后也绕过防护。如果运维出口 IP 不固定也可以改为按 IP 段或按 Firewall Rules 里的cf.verified_bot_category等字段判断。这里只演示通用思路具体字段以控制台自动补全的为准。规则表达式可以保持如下形式(http.user_agent contains ExampleSiteMonitor and ip.src in {198.51.100.0/24})5.3 第三步请求端做重试和友好失败即使配置了放行也建议在客户端处理 403、429 等情况。不要把请求写死成一次成功而是使用退避重试import time import requests def fetch_with_retry(url, max_retries3): session requests.Session() session.headers.update({ User-Agent: ExampleSiteMonitor/1.0 (https://example.com/bot-info), }) for attempt in range(max_retries): resp session.get(url, timeout10) if resp.status_code 200: return resp if resp.status_code in (403, 429): retry_after int(resp.headers.get(Retry-After, 5)) print(f[attempt {attempt 1}] retry after {retry_after}s) time.sleep(retry_after) continue resp.raise_for_status() raise RuntimeError(failed after retries)重试不是绕过拦截而是面对瞬时挑战或限流时的合理做法。如果重试后仍是 403就应该进入排查流程而不是暴力加大频率。5.4 第四步用安全事件确认放行生效配置完成后重新运行脚本回到Security → Events搜索刚才的请求。如果看到 action 是Skip或Allow说明规则生效如果仍看到Block需要检查表达式是否精确匹配或事件里显示命中其他规则。6. Computer Use 与 AI Agent 场景被 Cloudflare 拦截怎么办“Computer Use” 类 AI 代理是近期越来越常见的场景。它并不是传统意义上的爬虫而是模型在执行任务时自动打开浏览器、点击页面、输入内容。如果它访问的网站恰好使用了 Cloudflare就会遇到一个明显矛盾AI 代理不是真人但它模拟真人操作Cloudflare 的 Bot 检测很可能把它判定为自动化流量然后返回 “Were sorry” 页面。这里的核心原则和普通爬虫一样不要尝试绕过而是明确授权和放行。合法场景通常有两种第一种AI 代理访问的是你自己维护的站点。这时你可以在 Cloudflare 后台为代理的出口 IP 设置白名单或在最外层使用 Cloudflare Access 做身份认证。Cloudflare Access 是基于身份的访问控制可以让合法自动化通过短时 Token 访问内部应用或受保护路径比单纯调低 WAF 安全等级更可控。第二种AI 代理需要访问第三方站点。这种情况不应该去尝试修改对方站点的安全策略而应该优先看对方是否提供 API、开放接口或专门的数据合作协议。也就是说访问方要使用网站认可的官方渠道。补充一点Cloudflare 有一个人机验证产品叫 Turnstile它主要是验证“当前访客是人类”。对 Computer Use 类代理来说最好不要依赖通过在 Turnstile 上强行模拟人类交互来达到访问目的。更合适的方式是让自动化请求直接访问不经过验证的 API 端点或者在业务层使用 API Token、mTLS 等认证机制。如果被 Cloudflare 拦截后需要判断是不是配置问题可以按照第 3 节的排查流程走一遍。需要强调的是调试时要在自己拥有控制权的域名或测试环境中进行不要拿生产站点或者他人站点做绕过实验。7. 常见问题与排查思路下面的表格整理了我在日常运维里经常遇到的几类问题可以对照排查。问题现象可能原因排查方式解决方案浏览器能访问脚本 403脚本请求被 Bot 检测识别查看 Security Events 中命中的服务为脚本配置 WAF 放行规则或改用官方 API修改 UA 后仍被拦截检测依赖 TLS 指纹、IP 信誉、行为频率查看事件详情确认判定依据使用 IPUA 精确规则控制请求频率服务器访问自己的站点被拦截VPS IP 信誉度低或属于数据中心 IP在 Security Events 中搜索该 IP将该 IP 加入 WAF 白名单或通过 Access 认证访问调低安全等级后仍被拦安全等级和 Bot 管理不是同一个开关检查 Bots 页面和 WAF 规则分别确认 Bot Fight Mode、WAF、Rate Limiting 配置开启 Under Attack Mode 后大量验证这个模式本身对流量挑战很高查看 Security → Settings攻击结束后关闭该模式或使用 Access 保护敏感路径API 请求返回 403 而不是 JSONAPI 路径被全局防护拦截查看响应头cf-mitigated和事件日志为 API 路径单独设置 WAF 跳过规则给合法爬虫设了规则但没生效规则优先级或表达式没匹配上查看规则列表里的命中次数检查表达式字段确认 IP/UA 与请求实际值一致请求被 Managed Challenge 拦住请求评分处于中间区查看事件评分和威胁分数在客户端支持挑战处理或对可信来源做 Skip补充一条排查顺序的建议先看cf-ray再到 Security Events 搜事件然后确认命中规则最后才动手改配置。这个顺序能减少很多无效操作。8. 最佳实践与工程建议8.1 明确自动化流量的身份给每个自动化任务一个稳定、可识别的User-Agent建议格式包含名称/版本 用途 联系信息。这样做不是为了伪装成浏览器而是为了让 Cloudflare 规则可以精确识别你。Cloudflare 对“声明身份的爬虫”和“伪造身份的爬虫”的判定逻辑是有差别的。8.2 优先用白名单而不是全局放松当自动化流量需要访问网站时优先在 WAF 层加白名单尽量做到“白名单 限定路径 限定 IP”的最小权限组合。不要动全局安全等级。生产环境的任何一个全局开关影响面都比想象中大得多。8.3 对请求频率做控制Cloudflare 的 Rate Limiting 对高频请求非常敏感。即使请求来自白名单 IP如果频率异常高也可能触发其他规则。建议在自动化脚本里内置限速逻辑例如每请求之间 sleep 一个合理的间隔并记录请求耗时。8.4 使用 Cloudflare 的安全事件做持续观察配置完成后必须在 Security Events 里持续观察一段时间确认规则匹配情况、有没有误放行、有没有恶意流量借白名单绕过。安全配置不是“配置完就完事”而是一个持续迭代的过程。8.5 对敏感路径使用 Access 或 Token如果你要保护的是管理后台、内部工具或 API不建议只依赖 Bot 识别。更可靠的是在应用层或 Cloudflare Access 层加入身份认证。Bot 检测负责拦截“非真人”流量身份认证负责确认“合法访问者”两者配合才能真正解决问题。8.6 生产环境变更前先做验证修改 Cloudflare 的安全配置前建议在测试域名上验证 WAF 规则表达式记录当前配置便于回滚小范围放量逐步调整保留本次变更的日志方便事后审计。这些步骤和普通后端发布一样重要。Cloudflare 配置变更一旦出错轻则请求误拦截重则让整个站点暴露在风险中。9. 总结与后续学习方向看到 “Were sorry... but your computer or network may be sending automated queries” 时核心判断只有一句话这是 Cloudflare 对这个请求做了不信任的处理。了解它之后你就能按顺序解决问题先看 Security Events确认命中规则再决定是调整 Bot 管理模式、添加 WAF 白名单还是从请求侧优化身份和频率。本文实际覆盖了 Cloudflare Bot 管理的概念、后台配置入口、WAF 规则表达式、Python 请求端示例、Computer Use 类 AI 代理的合法处理方式以及一份可以直接对照使用的排查表。把这些内容用在“你自己拥有配置权限”的站点上绝大部分误拦截问题都能得到处理。下一步值得继续研究的方向包括Cloudflare Ruleset Engine 的规则优先级、Bot Management 的威胁评分机制、Cloudflare Access 与 mTLS 在服务间认证中的应用以及 Turnstile 在产品里如何做到既保护站点又不破坏用户体验。如果你正准备搭建一套带自动化流量的 Web 服务建议先把本文第 4 节和第 5 节的配置放在测试环境跑一遍再上生产。