Highlights
过去一个组织只是一行记录，且只能容纳一个人。现在它是一个完全由你掌控的管理页面：邀请同事、分配角色、允许他们创建由公司付费的 key。Proxy Finder 不再笼统地回复“重试次数耗尽”，而是开始明确指出遇到的具体阻碍；Browser 也在本周完成了优化，确保向页面呈现完全一致的指纹特征。
What's New
真正可自主管理的组织功能
过去添加同事需要给我们发邮件，导致团队往往会购买两个互不相关的订阅。
现在你的组织在 Dashboard 中拥有专属页面，并提供三种角色。Owner 绑定订阅套餐，所有 key 的费用均计入该套餐，因此 Owner 仅限一人且所有权支持转让。Admin 负责管理用量、账单和成员。Member 正常使用功能。邀请通过邮件地址发送，即使对方尚未注册也能直接接收。
组织内的任何人都可以创建归属于该组织的 key，或将个人 key 迁入组织，开发者无需再使用扣除个人费用的 key 来处理公司业务。组织 key 产生的用量直接计入 Owner 的套餐，且每次确认都会明确显示由谁的套餐付费。任何 Member 都可以重命名 key；重新生成、禁用和删除操作则仅限 Owner 和 Admin，因为这些操作生效时会立即影响所有正在使用该 key 的同事。
一个 Owner 筛选器贯穿 Overview、Detailed Metrics、Recent Activity 和你的 key 列表。Usage & Limits 以及 Billing 仍保持个人隔离，因为 Member 无权查看 Owner 的配额情况。
Proxy Finder 不再盲目猜测
无论是所有出口节点被封禁、所有出口节点失效，还是我们成功获取了真实页面但被你自定义的规则丢弃，“Download maxTry limit reached” 的报错此前完全一样。但这三种情况需要的解决方案截然相反。
现在失败的任务会附带 attemptReport：包含多少个出口从未响应、多少个被已知防御系统拦截以及具体是哪家防护厂商、多少个被你的 validate.status 拒绝，以及多少个返回了 HTTP 200、未见任何防护拦截且仅仅未通过你的 validate.data。同时还会附带一段清晰的总结说明。
最后一项统计最为关键。一个无法匹配的内容规则，在我们过去的检测维度下看起来与全方位被封禁毫无二致，且无论重试多少次都无法解决。（了解更多 validate rules 如何判定成功。）
另一半优化在于 Profile。Proxy Finder 过去只轮换出口节点，从不轮换客户端签名，因此一个拒绝特定浏览器 Profile 的站点会在代理池的所有出口节点上拒绝该请求。现在一旦遭遇拦截，系统会在既定的重试流程中自动切换 Profile，因此单次任务的请求数和额度消耗保持不变。如果你自行固定了 profile，则不会发生任何改变。需要注意的是，在对抗最严格的目标站点时，命中的出口节点依然比发送的 Profile 更关键。
Browser 消除指纹冲突
过去向 Browser 索取 User-Agent 的效果甚至不如不索取。三个层级对该 request 的身份各有认知，导致单个 request 可能同时声明为 Windows、Mac 以及集群并未运行的版本。现在只需确定一个值，即可在所有环节贯穿使用：启动阶段、页面本身以及页面启动的 worker。
Client hints 均派生自该字符串，因此 sec-ch-ua、平台和 navigator.platform 保持一致。response 会返回我们实际发送的字符串，这一点至关重要，因为 clearance cookie 与出口和 User-Agent 绑定在一起。渲染器查询在 document 和 worker 中也会得到相同的响应，这又补齐了一个累积生效的微弱信号。
同时上线的还有另外三项改进：
- 时钟与出口保持一致。 Browser 在出口节点所在国家的时区运行，因此渲染本地时间的页面会展示当地访客所见的内容。如果国家未知，则保持时钟不变。
- WebRTC 与其他流量保持在同一路径。 proxy 设置涵盖了浏览器通过 TCP 发送的内容。WebRTC 不在该路径上，因此页面向其查询 ICE 候选信息时会获得单独的响应。每当 request 包含出口时，Browser 都会将其关闭。
- 带锚点的 URL 恢复正常开销。 以
#reviews结尾的 URL 过去每次都会超时。现在已恢复到正常速度。
成本更低的路由，以及数据准确的 Dashboard
Imperva 不仅在拦截页面中注入脚本，在正常页面中也会注入，而 Auto 无法区分两者，导致正常页面无谓地升级调用浏览器。在某汽车租赁网站上，这曾导致 6 次尝试耗费 75 个 credit 和 27.5 秒；现在只需 1 次尝试、10 个 credit，耗时约 6.5 秒。某些站点在拒绝无 session 的 request 时会顺带返回一个 session，现在所有 4 个引擎都会在升级前直接带上该 session 重试。
概览页面的 credit 卡片此前会显示所有消耗并标记为已计费。在按成功付费模式下这两者并不相同，且差额涉及实际费用，因此卡片上同时展示这两项数据：数字显示为已计费，下方显示实际消耗，按产品及总量分别统计。Requests 卡片也采用了相同的拆分方式。时间范围和细粒度现在也是独立的控制项，支持 30 分钟到 1 年以及自定义范围，废弃了此前显示为 "1D" 却展开 30 天数据的标签。
在 Playground 中，carry 按钮现在会提供上一次 response 的 profile，因此如果发送的 request 使用了并非你手动输入的 profile，也可以直接重放可行的版本。所有参数均已收录在 API reference 中。
Under the Hood
Proxy Finder 为每个 host 保留更多历史记录：从原先的十几个增加到 32 个 exit。在线上 A/B 测试中，它在简单 target 上表现持平，在复杂 target 上表现更优，页面获取时间中位数从 5.5 秒降至 3.8 秒，同时整个集群的 latency 保持不变。有一个 target 的表现出现了反常，我们目前尚不清楚原因，因此正在对其进行单独测量。
注定会失败的 task 无论如何都会失败。区别在于你是在一分钟内关闭工单，还是花一下午时间去排查错误的方向。