← 全部文章

FourA 周报:2026 年 8 月 14 日至 8 月 21 日

支持高效运作的组织管理体系,能准确定位受阻节点的 Proxy Finder,以及解决单页面同源请求响应不一致问题的 Browser。

亮点

以前的组织只是一行只能容纳一个人的记录。现在它是一个完全由你掌控的页面:邀请同事、分配角色、让他们创建由公司付费的密钥。Proxy Finder 也停止返回模糊的“重试次数耗尽”,开始明确指出遇到的具体阻碍;Browser 本周则致力于确保向同一个页面呈现一致的指纹特征。

更新内容

真正可运营的组织架构

以前添加同事需要给我们发邮件,导致许多团队购买了两份互不相关的独立订阅。

现在你的组织在 Dashboard 中拥有专属页面,并提供三种角色。Owner 绑定用于结算密钥费用的订阅,因此组织有且仅有一位 Owner,所有权通过转让变更。Admin 负责用量、账单和成员管理。Member 负责实际使用。邀请通过电子邮件发送,即便对方尚未注册也可直接加入。

组织内的任何成员都可以创建归属于组织的密钥,或将个人密钥迁移至组织内,开发者无需再使用个人密钥为公司业务买单。组织密钥的用量计入 Owner 的套餐,且每次确认都会明确显示由谁的套餐付费。所有成员均可重命名密钥;重新生成、停用和删除权限则仅限 Owner 和 Admin,因为这些操作一旦执行会立即中断所有同事的使用。

一个 Owner 筛选器即可贯穿 Overview、Detailed Metrics、Recent Activity 和密钥列表。Usage & Limits 以及 Billing 仍保持独立私密,Member 无权查看 Owner 的配额。

Proxy Finder 告别盲猜

过去,无论是所有出口均被封锁、所有出口均失效,还是我们已获取到真实页面但被你的自定义规则丢弃,“Download maxTry limit reached”的提示看起来都毫无二致。但这三种情况需要的修复方案截然相反。

现在,失败的任务会携带 attemptReport:包含多少个出口未响应、多少个被已知防护机制拦截及具体拦截厂商、多少个被你的 validate.status 拒绝,以及多少个返回 HTTP 200 且未检测到防护机制、仅未通过你的 validate.data。同时还会附带一句清晰的摘要说明。

最后这项统计尤为关键。无法匹配的内容规则在我们以往的评估维度中与被全面封锁完全一致,且任何重试都无法解决问题。(详细了解 验证规则如何判定成功。)

另一项改进在于 profile。Proxy Finder 过去只轮换出口而不轮换客户端特征,因此当某个网站拒绝特定浏览器 profile 时,池中的所有出口都会被拒绝。现在一旦遭遇拒绝,系统会在既定的重试流程中切换 profile,不会增加每个任务的 request 次数和 credit 消耗。如果你自行固定 profile,则行为保持不变。需要注意的是,在难度极高的目标上,命中的出口节点通常仍比发送的 profile 更关键。

Browser 修复特征冲突

以前让 Browser 处理 User-Agent,效果比完全不处理还要糟糕。三个层级各自对请求来源有不同的判定,导致同一个请求可能同时声明自己是 Windows、Mac 以及集群并未运行的版本。现在统一为一个值,一次确定,贯穿始终:包括启动阶段、页面本身以及页面启动的 worker。

Client Hints 基于该字符串生成,因此 sec-ch-ua、平台和 navigator.platform 都与之保持一致。响应会返回我们实际发送的字符串,这一点至关重要,因为 clearance cookie 是与出口和 User-Agent 绑定的。渲染引擎的查询在文档和 worker 中现在也会返回相同的结果,这是又一个累积起作用的微弱信号。

随之而来的还有另外三项改进:

  • 时钟跟随出口。 Browser 会在出口节点所在国家的时区运行,因此渲染本地时间的页面会显示该地区访客实际看到的内容。如果国家未知,时钟保持不变。
  • WebRTC 路径与其他流量保持一致。 代理设置仅覆盖浏览器通过 TCP 发送的内容。WebRTC 不走该路径,因此请求 ICE 候选地址的页面会获得不同的结果。只要请求携带出口节点,Browser 就会将其关闭。
  • 带锚点的 URL 恢复正常开销。 以 #reviews 结尾的 URL 过去每次都会导致超时。现在已恢复正常速度。

成本更低的路由,以及准确计数的 Dashboard

Imperva 不仅在拦截页面注入脚本,在正常页面中也会注入。Auto 过去无法区分这两者,导致正常页面被白白升级至浏览器模式。在某租车网站上,这曾导致 6 次尝试耗费 75 个 credits 和 27.5 秒;现在只需 1 次尝试、10 个 credits,耗时约 6.5 秒。有些网站在拒绝无会话请求时会在响应中返回 session,现在所有四款引擎都会在升级前直接带上该 session 发回重试。

概览中的 credits 卡片曾显示所有消耗并将其标记为已计费。在按成功付费模式下这两者并不相同,其差额对应真金白银,因此卡片上现在同时显示两项:计费数量为主数值,消耗数值显示在下方,按产品和总量分别列出。Requests 卡片也采用了相同的拆分方式。时间范围和粒度现在也改为独立控件,支持从 30 分钟到 1 年及自定义范围,替代了之前显示“1D”却展示 30 天数据的药丸标签。

在 Playground 中,带入按钮现在会提供上一次响应的配置参数,这样即使发出的请求使用了非手动输入的 profile,也能直接重放成功运行的版本。所有参数均可在 API 参考 中查看。

底层实现

Proxy Finder 为每个 host 保留更多历史记录:从十几个增加到 32 个出口。在生产环境 A/B 测试中,它在简单目标上表现持平,在困难目标上表现更好,页面获取时间中位数从 5.5s 降至 3.8s,同时全集群延迟保持不变。有一个目标的表现出现了反向变差,我们目前尚未查明原因,因此正在对其进行单独监控。

注定会失败的任务终究会失败。区别在于你是在一分钟内关闭工单,还是花一下午时间去排查错误的方向。