近期在整理 Cloudflare 相关配置时无意间看到 “cloudflare / computer” 这个组合。第一反应是它可能是一个新开源项目或者是把 Cloudflare 封装到本地环境的工具。顺着访问报错和高频词继续看才发现大家真正集中遇到的问题其实是另一个更常见的场景一个用户用正常的浏览器访问你的站点却被 Cloudflare 拦截页面出现 “We’re sorry… but your computer or network may be sending automated queries” 这样的提示。很多站长第一次遇见这个页面心里会冒出一连串问题我的电脑是不是中毒了我的网络是不是被判定为异常Cloudflare 是不是把我的真实用户误伤成了机器人如果是误伤应该去后台哪里调整调整之后会不会又放进来一堆爬虫、攻击脚本这篇文章不打算做成 Cloudflare 的功能清单而是想围绕 “Cloudflare 如何看待你的计算机/网络” 这条线把 Bot 管理、安全挑战页、误报排查、防护策略这几个点串起来。如果只记住一句话我希望是Cloudflare 的安全能力不是“开一个总开关就能防住所有攻击”而是要理解它的检测维度学会分层配置并且把“误伤真实用户”当成一个需要持续观察和优化的工程问题而不是一次性把模式调到最严格就完事。1. 先理解 Cloudflare 是怎么“看待”你的电脑的1.1 从一次访问报错说起先还原一下最常见的现场。你打开一个配置了 Cloudflare 的网站地址栏输入域名按回车页面没有加载出来而是显示一个安全提示页大意是系统检测到你的电脑或网络可能正在发送自动查询为了保护站点当前访问被暂时阻止。此时你的第一反应可能是刷新但刷新往往还是会看到同一个页面。于是你会尝试切网络、换浏览器、清 Cookie甚至重启路由器。有时候这些操作有效有时候完全没用。真正的问题不一定出在你的设备上而在于 Cloudflare 对你的“这次访问”打了一个风险分风险分超过阈值后就会触发安全挑战。这里要先明确一个概念Cloudflare 在拦截页面里提到的 “computer” 并不特指你家里的台式机或笔记本电脑。它是一个泛指代表访问请求所来自的客户端设备、IP 网络环境、浏览器指纹、请求行为等一系列信息的总和。Cloudflare 的引擎会在请求到达源站之前根据这些信息判断“这次访问更像真人还是更像自动化程序”。1.2 “computer” 在这里不是设备而是一组流量特征很多人以为 Cloudflare 的 Bot 检测就像查身份证一样能直接认出“这是一个人”。实际上它更接近一个打分系统。引擎会同时观察很多特征请求的 IP 地址是否来自机房、云厂商、代理网络还是常见的家庭宽带段。浏览器 User-Agent、HTTP 头字段是否完整、是否与真实浏览器一致。请求频率是否在人类操作范围内比如一个用户不可能在 1 秒内连续打开 20 个页面。鼠标轨迹、页面交互事件这类客户端信号是否真实存在。同一个 IP 下是否同时出现很多不同设备的特征。请求路径是否符合真实浏览习惯比如是否直接请求登录接口而完全没访问过首页。这些特征组合起来会形成一个“自动化程度”的判断。如果请求看起来像脚本Cloudflare 就会要求用户完成一个验证挑战。如果有足够的证据证明是恶意自动化流量就会直接拦截也就是我们看到的安全挑战页或 403 页面。这里需要注意一点Cloudflare 不会公开所有检测规则因为它一旦完全公开攻击者就可以针对性地伪造流量。所以我们在后台看到的 Bot 管理模式、安全级别、自定义规则都属于“用户可控的暴露面”真正的检测逻辑是黑盒。1.3 为什么误判会存在既然检测是概率性的误判就不可能完全避免。最常见的误判原因不是 Cloudflare 的算法太笨而是站点本身的数据特征不够清晰。举个例子一个刚上线的小型技术博客访问量很低没有历史流量基线。某一天作者从自己的开发机频繁访问或者通过命令行工具拉取页面Cloudflare 看到“这个 IP 之前没什么流量突然快速请求多个页面”风险分就会升高。更不要说有些办公网络的出口 IP 是统一网关整个公司几十个人共享一个公网 IP在 Cloudflare 眼里这就是一个非常可疑的聚合节点。再比如你的站点配置了比较激进的 Bot 管理策略把所有“可疑或自动化程度较高”的流量都设为“挑战”这时候如果用户的浏览器版本比较老、JavaScript 执行失败、Cookie 被禁用就可能无法正常完成挑战最终看到拦截页面。所以误杀不是 “要不要发生” 的问题而是 “什么时候发生、怎么减少发生” 的问题。理解了这个前提我们再去看后台配置思路会清晰很多。2. 后台 Security → Bots从“严格”到“合规”的配置路径2.1 Bots 管理面板里到底有哪些模式登录 Cloudflare 后台进入某个域名的 Security安全菜单可以看到 Bots机器人相关设置。常见的有几个不同层级的管理模块包括Bot Fight ModeBot 战斗模式这是偏入门级的开关模式开启后 Cloudflare 会尝试拦截或挑战自动化流量。Super Bot Fight Mode超级 Bot 战斗模式在免费版或某些套餐中提供可以进一步区分“已验证的机器人”和“可能的机器人”。Bot Management机器人管理这是更高级的功能通常需要企业版开通也可以看到更细分的评分和管理策略。Bots 模式这里沿用你后台可能看到的 “Bots management mode”有些后台版本会出现一个下拉框让你选择 Bot 管理的严格程度常见的有 “不干预”“严格”“更多挑战”等。这些模式背后不只是“严格程度”的区别还包括数据收集深度和误判率。比如严格模式下Cloudflare 会更积极地挑战“看起来像自动化”的流量这会让恶意流量很难进来但真实用户被误伤的概率也会上升。2.2 严格模式的代价很多站长第一次配置安全策略时会本能地把一切选项调到最严格。原因很简单谁都不想自己的站点被爬虫刷爆更不想被攻击脚本打挂。但严格模式不是免费午餐它的代价就是误伤。如果站点的用户画像很杂、访问来源遍布各种网络环境、移动端占比高那么严格模式会导致大量正常用户看到安全挑战页。有的用户会耐心地点击验证有的用户会在第一次遇到拦截时直接关掉页面。对于内容型站点来说这可能意味着访问量下降对于电商和 SaaS 产品来说这可能直接变成订单流失。关键是有些严格模式还会对“未经过验证的自动化流量”直接采取质询甚至可能对某些合法的自动化工具造成影响。比如你的站点自己配置了监控服务、SEO 分析工具、RSS 抓取器这些工具的 IP 如果和普通用户 IP 混在一起很容易被挑战。所以我的建议是不要第一时间把 Bots 管理模式从默认改成“严格”更不要同时打开所有防火墙规则的拦截动作。先跑一段时间观察数据再逐步收紧。2.3 配置建议先观察再收紧如果要从后台开始调整可以参考下面的顺序先打开 Security 下的 Events安全事件或 Analytics分析观察当前有多少流量被挑战、被拦截哪些路径被拦截得最多。确认你的站点是否已经有正常运行的监控工具、搜索抓取工具、支付回调或第三方 API 调用者如果有先记录它们的 IP 或 User-Agent 特征。在 Bots 管理面板中先选择“只记录”Log或“挑战”Challenge而不是直接“阻止”Block。挑战可以给真实用户一次验证机会而阻止往往没有回旋余地。运行一到两天回到安全事件中查看被挑战或被拦截的请求检查其中是否有来自你自己公司 IP、办公室网络、常用测试工具的流量。确认没有误杀后再逐步提高模式的严格程度或者创建更精细的 WAF 自定义规则。这里有一个很重要的实操经验不要在流量高峰期直接切换严格模式也不要在没有观察任何日志的情况下一次性开启全部保护。最好选择业务低峰期调整并且保留至少 24 小时的日志窗口。注意后台的 “Bots 管理模式” 如果显示为 “严格”只代表 Cloudflare 会更愿意发出挑战并不等于“所有自动化流量都会消失”。真正决定效果的是你对自身业务的理解和规则的分工。3. 遇到 “computer may be sending automated queries” 怎么排查3.1 先分清问题层次客户端、网络、Cloudflare 配置当看到 “computer or network may be sending automated queries” 这个页面时不要把注意力全部放在“怎么让这个页面消失”上因为这可能掩盖真正的问题。有效的排查是按层次来分客户端层浏览器是否有异常插件、是否有自动化工具在后台运行、User-Agent 是否被篡改。网络层当前 IP 是否属于机房/云厂商、是否多人共享出口、是否有异常请求行为。Cloudflare 层站点的 Bots 模式是否设置得过严、是否有防火墙规则命中、IP 是否被加入了阻止列表、是否需要添加 WAF 放行规则。建议先不要急着换 IP 或开代理而是先看请求头和服务器的 access log确认 Cloudflare 返回的响应码是什么以及挑战页面出现的具体条件。3.2 常见原因和验证方法不同原因下的表现会不一样可以按下面的表格快速对比可能原因典型表现验证方法当前网络出口 IP 是共享 IP且触发频率过高同一网络下多台设备都出现提示更换手机热点访问同一个页面如果正常问题很可能在网络出口浏览器插件或脚本导致请求特征异常只有特定浏览器或设备出现提示用无痕模式访问并禁用全部扩展对比结果Cloudflare Bots 模式设置过严大量正常访问都出现挑战页后台临时把 Bots 模式调低观察是否恢复防火墙/WAF 规则误拦被拦截的路径比较集中不一定所有页面都触发查看 Security Events 中命中具体哪条规则有脚本在后台持续请求站点即使不操作页面也会周期性出现新请求查看浏览器开发者工具的 Network 面板排查定时请求如果用户在办公室网络最常见的就是共享出口 IP 被误判。这种情况更建议在 Cloudflare 后台创建一个 WAF 自定义规则对可信 IP 段设置 Skip 动作而不是直接要求用户换一个网络环境。3.3 排除误报的三步法如果你就是被误伤的站点管理员可以用三步法来确认问题到底出在哪第一步先模拟一次正常访问。用浏览器打开站点按 F12 打开开发者工具切到 Network 面板刷新页面查看文档请求的响应状态码。如果是 403 或者 409需要进一步查是 Cloudflare 拦截还是源站返回如果是 503通常和 Cloudflare 的挑战/速率限制有关。Chrome 的 Network 面板可以直接看到响应头里的cf-mitigated字段如果值是challenge说明确实是 Cloudflare 发起了挑战。第二步临时调整 Cloudflare 的规则来排除自身配置问题。在 Cloudflare 后台进入 Security → WAF创建一个宽松规则把测试者的 IP 加为白名单或者把 Bots 管理模式暂时调低然后重新访问。如果页面恢复正常说明问题基本出在 Cloudflare 的规则或模式上。如果页面依然被拦截那就需要检查客户端环境和源站代码。第三步记录并对比前后差异。改完配置后不要只看“现在能访问了”就结束。把安全事件中的日志导出对比调整前的拦截数量和次数。如果调整后拦截量明显下降但恶意流量没有明显上升说明之前的配置过于严格如果恶意流量上升很多则需要换一种更细致的策略比如只对特定路径开启严格模式。注意在调整 WAF 规则时优先使用 “Skip” 或 “Challenge” 动作不要轻易使用 “Block” 之外的极端动作。特别是放行规则要加好注释后续排查询问时可以知道这条规则是谁、为什么、什么时候添加的。4. Cloudflare 与 “Computer Use”当自动化工具变成访问者4.1 自动化工具越来越像真人检测越来越难“Computer Use” 这个词在这两年开始频繁出现它描述的场景是AI 智能体能够像人一样操作系统界面、浏览网页、点击按钮、填写表单。如果这些智能体把所有动作都伪装成真实浏览器行为传统意义上的指纹检测、频率检测、验证码都可能失效。过去我们识别爬虫靠的是 User-Agent 里的 python-requests、无头浏览器特征、快速请求频率。但现在这些特征正在变得不可靠因为自动化工具可以复用完整浏览器内核甚至能驱动真实浏览器执行 JavaScript、移动鼠标、产生真实交互事件。这意味着 Cloudflare 的 Bot 检测也要面对一个更复杂的战场攻击者有机会把流量质量做到和真人几乎一致而防御方只能在大量特征中寻找细微差别。对普通站长来说我们不需要知道内部算法但需要意识到一个问题我们把所有看起来像自动化的流量都拦截掉会误伤很多合法且有用的自动化工具但如果完全放行真正恶意的自动化流量也会混进来。4.2 Cloudflare 的 Bot Management 如何应对Cloudflare 的 Bot Management 并不是简单地把流量分成“真人”和“机器人”两类。它会给每个请求打一个 1 到 99 的分数分数越高代表越像真人。站长可以基于这个分数设置动作。常见配置思路是得分较低例如 1 到 30很可能是恶意机器人可以直接 Block。得分中等例如 30 到 60自动化概率较高但可能有合法用途采用 Challenge 或 Managed Challenge。得分较高例如 60 到 99接近真人行为可以正常放行。除了基于分数Bot Management 还允许你针对已授权的机器人做标记。比如知名的搜索引擎爬虫、监控工具、支付回调服务Cloudflare 可能有对应的验证机制标记后可以正常通过而不会触发挑战。不过 Bot Management 大多不是免费功能普通站点往往只能使用 Bot Fight Mode 或 Super Bot Fight Mode。这并不代表普通站点无解而是说我们需要用更合理的自定义规则来弥补。4.3 对普通站长的启示对没有企业版 Bot Management 的普通站长来说面对越来越像真人的自动化工具重点不应该放在“如何识别每一个机器人”上而是放在“如何降低无差别拦截带来的误伤”上。一个更务实的做法是识别关键业务路径。比如登录接口、下单接口、留言接口这些地方适合开启更严格的防护。对静态资源、文章详情页这类低频风险区域适当放行不要一刀切挑战。善用 Rate Limiting速率限制而不是全局挑战。对于单个 IP 的高频请求可以用速率限制精确控制。定期查看安全事件中的 Top IP、Top User-Agent、Top Path及时更新规则。说白了防护的意义不是让所有“机器人”都进不来而是让有价值的内容和业务接口不被爬取和攻击同时让真实用户不被打扰。这个平衡点必须靠数据不断调整。5. 从一次误杀到一套可持续的防护策略5.1 不要追求“全部拦截”而是分层管控很多人在配置 Cloudflare 时会把安全等级拉到“我感觉被攻击了”把 Bots 模式调到“严格”把 WAF 规则全部设为“阻止”以为这样最安全。但安全不是这样工作的。安全是一个分层模型每一层只需要拦截“上一层漏掉的那部分风险”就够了。如果所有层都开到最大强度结果一定是所有访问都被反复质询最终站点变成一个“只有验证通过才能看文章”的门禁系统。更合理的分层是第一层网络层。通过防火墙规则限制恶意 IP 段和攻击工具特征。第二层应用层。通过 WAF 规则检测常见的注入、扫描、恶意 payload。第三层访问层。通过 Bots 管理识别自动化流量对可疑流量发起挑战。第四层业务层。通过速率限制保护关键接口防止突发性的批量请求。每一层之间要有明确的职责分工。不要用 Bots 管理模式去替代 WAF 的注入检测也不要用速率限制去替代 IP 封禁。只有各层各司其职误伤率才能降下来。5.2 五步方案从最小验证到持续优化如果你还不确定自己的 Cloudflare 防护策略该怎么配置可以先按下面这五步走这个框架适合以“稳定可用”为优先原则的普通站点也适合把误杀率降到最低先建立访问基线。记录正常情况下一周的请求量、IP 数、路径分布、错误码比例。了解你站点的真实用户来自哪些地区、哪些网络类型。只开启“观察”模式不直接拦截。把 Bots 模式设置为检测或日志模式先看数据再决定是否要动手。在 WAF 中只启用高可信的托管规则不要一开始就自定义猛规则。从风险最高的路径开始加固。优先保护登录、注册、支付、API 等接口加入速率限制和挑战验证。内容页面可以保持相对宽松避免大量真实用户被挑战页挡住。引入持续观测闭环。每周检查一次 Security Events 和 Analytics关注拦截率、挑战完成率、误杀反馈。一旦发现真实用户访问下降优先查看是不是某条规则或模式调整所致。定期清理和优化规则。删除没有命中记录的规则合并重复的规则更新已知合法工具的白名单。为新上线的功能模块预留规则命名规范避免临时加规则导致冲突。这个方案的核心不是“一次到位”而是“用数据驱动调整”。前两周可能会频繁改动但后续会越来越稳定。5.3 适用边界和长期注意事项最后有必要说明一下这个方案的边界。如果是政府、金融、军工等对安全性要求极高的站点可能需要更严格的企业级 Bot Management、设备指纹、自定义检测模型上面的通用策略只能作为起点。如果是个人博客、内容站、小工具站其实不需要太多复杂规则免费版的 Bot Fight Mode 加速率限制通常已经够用。如果是电商、SaaS重点放在保护交易接口和核心 API 上不要为了拦截爬虫而牺牲所有页面的可用性。长期使用 Cloudflare 时还要注意几个容易踩坑的地方不要在变更规则时深夜无人值守如果规则误封大量用户发现时可能已经晚了。不要把所有第三方服务都直接加白名单外部 IP 可能会变化建议优先校验 User-Agent 和请求签名。不要忽略源站日志。Cloudflare 只是入口源站 access log 能告诉你哪些流量真正到达了后端哪些被拦在了门外。不要依赖“重启路由”来解决问题。遇到挑战页时先排查自身配置再考虑客户端环境。如果你正在被 “computer may be sending automated queries” 这个页面困扰下一件值得做的事不是继续刷新也不是把安全等级降到最低而是打开 Cloudflare 后台的 Security Events看一眼那条流量到底是被什么规则拦截的。搞清楚了为什么会被判成自动化请求这个问题就解决了一半。下次再看到 “cloudflare / computer” 这样的组合我会把它理解为Cloudflare 正在不断重新定义“什么样的计算机/网络请求值得信任”。我们作为使用者能做的不是和这个黑盒对抗而是通过配置和日志让它在保护业务的同时尽量不打扰真实用户。