一个 & 触发验证码：Simon Willison 的 Cloudflare 反爬规则给网站运营的启发

Simon Willison 今天记录了一个很小但很有价值的网站运营细节：他把自己站内搜索页的 Cloudflare CAPTCHA 规则改细了。

原来的问题是，搜索页为了防止爬虫遍历复杂筛选结果，会触发 Cloudflare 的 Managed Challenge。但规则太宽，连普通用户输入一个简单搜索词，例如 ?q=term，也可能被要求做验证码。

他的改法是，只在搜索路径匹配 /search/*，并且查询字符串里至少包含一个 & 时触发挑战。也就是说，像 /search/?q=lemur 这种只有一个查询参数的普通搜索，不再触发 CAPTCHA；更复杂、包含多个筛选参数的搜索 URL，才进入挑战流程。

原文里的规则是：

(http.request.uri.path wildcard r"/search/*" and http.request.uri.query contains "&")

这件事看起来很小，但对所有运营内容站、工具站、资料库、商品库的人都有启发：防爬虫不是越狠越好。真正好的规则，是让正常用户少受打扰，同时让高风险路径更难被机器批量扫。

粗暴防护为什么会伤害正常用户

很多网站第一次遇到爬虫压力时，会自然地做一件事：把拦截规则写宽。

例如：

只要访问 /search/ 就触发验证码

这种规则简单，也能立刻减少一部分抓取。但代价同样明显：真正想搜索内容的用户也会被拦住。对于内容站来说，这尤其危险，因为搜索通常是高意图行为。用户已经明确知道自己想找什么，此时弹出验证码，很容易把人赶走。

更合理的思路不是“搜索页都危险”，而是拆开看：

• 单一关键词搜索，通常是正常用户行为；
• 多条件筛选、翻页、组合查询，更像爬虫批量探索路径；
• 短时间内大量请求，才更接近自动化抓取；
• 某些 User-Agent、IP 段、异常 referer，可以作为辅助信号，但不应该单独决定一切。

Simon 这条规则的精妙之处就在这里：它没有把整个搜索页一刀切，而是抓住了“复杂筛选搜索通常会带多个查询参数”这个具体特征。

为什么一个 & 可以成为边界信号

在 URL 查询字符串里，& 通常用来分隔多个参数。

例如：

/search/?q=cloudflare

这是一个简单搜索。它只表达一个意图：用户想搜 cloudflare。

而下面这种 URL：

/search/?q=cloudflare&type=til&tag=security&page=8

它包含多个参数，更像是在筛选、翻页、组合条件。对于带 faceted search 的站点，这类 URL 可能形成大量组合。爬虫如果沿着所有筛选条件遍历，就会制造很多低价值请求，甚至拖慢站点。

所以，& 不是“爬虫证据”，而是一个轻量的风险提示：这个请求可能比普通搜索复杂，值得更严格地看待。

这也是规则设计里很重要的一点。一个信号不需要完美，它只需要在你的场景里能提高判断质量，同时不会明显伤害正常用户。

AI 工具在这个案例里真正帮了什么

这条记录还提到，Simon 用 Claude Code 探索了解法，也尝试过 Cloudflare MCP。但 Cloudflare MCP 没能直接编辑相关规则，最后切换到了 Cloudflare API。

这说明 AI 工具在配置类任务里有三个常见作用。

第一，帮你把模糊问题变成规则条件。

人类一开始说的是“不要让普通搜索触发验证码，但要挡住复杂筛选爬虫”。AI 可以帮你把它变成可测试条件：路径是什么、query 里有什么、哪些样例应该命中、哪些样例不应该命中。

第二，帮你设计验证样例。

一个靠谱的配置变更，不应该只看规则文本，还要有样例：

/search/?q=lemur
期望：不触发 CAPTCHA

/search/?q=lemur&tag=ai
期望：触发 CAPTCHA

/blog/any-post/
期望：不受影响

第三，帮你找到执行路径，但不能替代权限验证。

MCP 能不能改规则，API 有没有权限，后台是否需要二次确认，这些都不是“模型觉得可以”就能成立的。AI 可以建议路线，真正执行时仍要看平台能力和账号权限。

普通网站可以怎么照着做

如果你也运营一个带搜索或筛选的网站，可以按这个顺序检查。

第一步，列出正常用户路径。

不要从“我要挡爬虫”开始，而是先写下哪些请求必须顺畅。例如站内搜索、文章页、分类页、产品页、价格页、登录页。尤其是已经有明确意图的页面，不要轻易加重阻力。

第二步，列出高风险路径。

例如：

• 多参数筛选组合；
• 深层分页；
• 站内搜索结果页的批量遍历；
• 短时间重复访问相似 URL；
• 会触发高成本计算的接口。

第三步，让 AI 帮你把规则翻译成“条件 + 样例”。

你可以这样问：

我想给站内搜索加一条反爬规则。
目标是：普通关键词搜索不触发验证码，复杂筛选搜索触发验证码。
请你根据下面这些 URL 样例，帮我归纳触发条件，并列出 10 个应该命中和不应该命中的测试样例。

第四步，再决定用 Cloudflare、Nginx、应用层代码还是日志告警。

不是所有问题都要在边缘层解决。有些规则适合 Cloudflare，有些适合应用层限流，有些只需要先记录日志。越靠前的拦截越有力，也越容易误伤，所以要更谨慎。

鲲鹏 AI 观察

这个案例的价值，不在于“一个 & 就能解决所有反爬问题”。它真正说明的是：网站运营进入 AI 时代后，很多工作不是让 AI 大包大揽，而是让 AI 帮你把边界讲清楚。

过去我们写规则，经常凭经验拍一个大范围条件。现在更好的做法是：先让 AI 帮忙把场景拆成正常路径、高风险路径、边界样例和验证清单，再由人决定是否上线。

这也是普通人用 AI 做实际工作的一个范式：

• 不要只问“怎么防爬虫”；
• 要问“哪些用户不应该被影响”；
• 要问“这条规则会命中哪些样例”；
• 要问“上线后我应该看哪些日志和指标”。

AI 的价值不是让你少思考，而是让你把思考对象拆得更具体。

参考来源

• Simon Willison: TIL: Cloudflare CAPTCHA on at least one ampersand