一位 SaaS 开发人员发现，在他账户中的每个域名上都开启 Cloudflare 的 Bot Fight Mode，导致 API 流量停滞了整整一个月，使得付费客户无法使用其产品的核心功能。
当开发人员注意到使用指标突然趋于平缓时，问题浮出水面。新注册用户仍在不断增加，但活跃会话却停止了增长。经过数周的代码重写和调试，事实证明，一个单一的安全开关才是罪魁祸首：Cloudflare 的 Bot Fight Mode 将该 SaaS 自身的 AWS Lambda 端点标记为恶意机器人并将其拦截。
单一设置如何导致整个服务瘫痪
该开发人员的技术栈依赖于服务器到服务器（server-to-server）的调用。一个内部 Lambda 函数定期将数据回传到该 SaaS 的公共域名，这种模式在现代微服务架构中非常常见。Bot Fight Mode 会对看起来像自动化爬虫的请求发起挑战或进行拦截，从而保护内容驱动型网站免受数据抓取。
当该模式在所有区域（zones）启用时，Cloudflare 将 Lambda 的出站请求视为另一个自动化客户端。请求从未到达应用程序，由于拦截发生在边缘侧（edge），SaaS 的监控工具没有看到任何错误——流量就那样凭空消失了。开发人员在 Cloudflare Workers 上的 CPU 使用率飙升，导致他怀疑是外部爬虫，而不是他自己的后端。
直到深入查看 Cloudflare 的日志后，他才看到了与 Lambda IP 范围匹配的“Bot Fight Mode”拦截条目。他为受影响的区域关闭了该功能，API 流量随即恢复，使用指标也回到了正常水平。
为什么这个错误对 SaaS 运营者至关重要
- 以 API 为中心的产品需要开放的服务器到服务器通道。 Bot Fight Mode 假设主要流量是针对 HTML、图像或静态资源的真人浏览器请求。暴露了 API、webhook 或内部回调的 SaaS 平台可能会被限流或拦截，且不会向应用层发送可见的错误代码。
- 全局安全设置很少能适配所有工作负载。 将单一的 Cloudflare 配置应用于所有域名，等同于认为每个网站都具有相同的威胁模型。内容网站、论坛和 SaaS 后端的安全需求截然不同。
- 静默失败会吞噬收入。 开发人员的告警系统没有触发，因为被拦截的请求从未到达应用程序。只有用户参与度指标的下降才暗示了问题的存在。如果不对边缘侧日志进行主动审查，类似的问题可能会在无人察觉的情况下持续存在。
开发人员可以采取哪些措施来避免同样的命运
- 审计每个区域的流量特征。 在启用 Bot Fight Mode 之前，列出您的域名预期的请求类型：真人浏览器、API 调用、webhook 回调或内部服务调用。如果其中任何一项对核心功能至关重要，请将该区域视为“API 优先”，并保持最低限度的机器人缓解设置。
- 在分阶段环境中测试更改。 Cloudflare 允许您将设置应用于单个子域名或暂存区域（staging zone）。在全局推广更改之前，请验证合法的自动化操作是否仍然有效。
- 将边缘侧日志作为可观测性技术栈的一部分进行监控。 将 Cloudflare 的防火墙和机器人缓解日志流式传输到 SIEM、Loki 或任何聚合服务中。将拦截请求的激增与应用指标的下降进行关联，以便及早发现静默失败。
- 确保安全设置是可逆的。 准备一份记录在案的回滚计划。如果新规则导致了意外行为，请先禁用它，并在投入时间进行代码规避之前确认更改。
- 提出正确的问题。 不要问“我该如何阻止爬虫？”，而要问“这个工具是否解决了我在面对的具体问题？”对于需要开放 API 访问的 SaaS 来说，一个可以阻止爬虫的安全功能可能并不是合适的答案。
更广泛的视角
对于需要保护静态内容免受激进爬虫攻击的网站来说，Bot Fight Mode 仍然具有价值。它的缺点是无法区分恶意爬虫和遵循相同 HTTP 模式的正当自动化客户端。
总结
当您在单个 Cloudflare 账户下管理多个域名时，请将每个域名视为一个独立的安全性区域。仅在流量完全由人工驱动的地方启用 Bot Fight Mode；对于 API 密集型的 SaaS 工作负载，请保持该设置关闭，或使用自定义防火墙规则进行微调。只需轻轻一点，它屏蔽合法流量的效果可能与阻止爬虫一样高效。