我们如何测量这些数据
求解时间在服务端测量:从我们的 API 收到你的 /solve 请求开始计时,到我们返回有效的 token 或放行 cookie 时停止。它不包含你的机器与我们 API 之间的网络往返——这取决于你所在的区域——因此你端到端观察到的延迟会略高于此处标注的求解时间。
只有当我们返回的 token 或 cf_clearance 被目标站点自身的验证所接受时,一次求解才算成功。失败的求解从不计费,这意味着成功率与你的账单是按完全相同的标准衡量的——我们没有任何动机把一个临界结果算作"成功求解"。
上述数字是在近期所有客户的生产流量上汇总得出的,而非在简单目标上的一次性实验。我们取诚实、保守的数值,而不是挑选最佳情况。
为何你的结果会有所不同
没有任何求解器能承诺单一固定的延迟,对任何作此承诺的服务你都应保持怀疑。你的真实数字取决于一些位于我们基础设施之外的因素:
- 目标难度——一个防护较弱的 Turnstile 小部件,会比一个运行强化托管挑战的端点或一个全新部署的 Kasada 清除得快得多。
- 代理质量——如果你提供的是缓慢或已被标记的住宅代理,无论我们求解多快,每一次经由它的往返都会增加延迟并可能降低成功率。
- 你的区域与网络——从你的服务器到我们 API 的往返会叠加到总耗时上;部署得更近会有帮助。
- 防护更新——Cloudflare 与 Kasada 频繁更新。我们会跟踪并适应,但在一次重大更改之后,某项服务可能会短暂处于其成功率区间的低端,直到我们的求解器追上。
为何 Turnstile 是亚秒级而 Kasada 不是
NSLSolver 在一个预热的服务端工作节点池上求解,而不是为每个请求冷启动一个无头浏览器。Turnstile 是非交互式的——它运行一个小型工作量证明和一组浏览器 API 探测——因此我们可以直接生成有效的 cf-turnstile-response token,这就是 Turnstile 平均约四分之一秒的原因。
Cloudflare Challenge,尤其是 Kasada,耗时更长,因为途中有真实且不可避免的计算:必须先完成一个完整的工作量证明,而对于 Kasada 还要完成一个庞大的浏览器指纹生成步骤,目标才会签发放行。那几秒是防护本身的代价,而非我们这边的额外开销——而且它仍然远比维护你自己的浏览器集群更快、更便宜。