亮点
许多网站对所有人开放首页，但对点击深入的内容设限。Auto 现在可以直接从首页进入：获取入口页面分配的 session，并在携带该 session 的同时请求您需要的目标页面。Browser 本周承担了更繁重的工作。当多个 request 同时访问同一页面时，它能完成网站的复选框验证；而在页面持续受阻时，它会报告实际捕获的信息，而不是只返回一个笼统的词。
更新内容
Auto 可打开受 session 限制的页面
eBay 商品页面会在我们现有的所有路由上拒绝冷启动 request。但当 request 携带 eBay 首页向普通访客发放的 cookie jar 时，相同的 URL 即可成功打开。无需登录，无需借用账号，完全等同于在浏览器标签页中的手动操作。
Auto 现在会自动执行此操作。当某个出口节点成功连接到源站但访问深层页面仍被拒绝时，Auto 会通过同一个出口节点抓取网站根目录，保留返回的所有 cookie，然后重新发起请求。response 会明确告知这一过程：获胜的阶梯节点显示为 warmup。
但成本才是关键所在。该 session 具备可移植性，因此 cookie jar 并未与获取它的出口节点绑定。后续读取会通过 /api/proxy 重放，并在消耗 2 个 credit 的情况下命中 /api/single。这与我们在 关于 Cloudflare 验证通过机制的文章中介绍的“先升级再重放”链路相同，只是将 cf_clearance 替换为了目标网站自身的 session cookie。
机制经过专门限制：每个 request 仅在不同出口节点上重试两次，且仅在深层 URL 请求失败以及出口节点确实连通源站的前提下触发。因此，对于直接屏蔽我们的网站，只会产生两次额外的子调用开销，绝不会陷入循环。关于阶梯机制如何选择节点的更多信息，请参阅 Auto 技术解析。
Browser 支持在并发请求时通过复选框验证
Browser 现在可以在针对同一页面的并发 request 中完成复选框验证。在一个受 Turnstile 保护的新闻网站上同时发起三次请求，耗时分别为：5.2 秒、5.8 秒、9.1 秒。
随之发布的还有两项细微改动。只有在验证组件彻底消失后，点击才算生效，因为 Cloudflare 重新下发验证的频率往往超出预期（首次点击通常并不意味着验证结束）。此外，通过验证的页面会在完成验证的那次调用中报告 defenseSolved: true，该调用也是计费对应 solve 的同一次调用。
被拦截页面会反馈求解器观察到的具体信息
“Timeout”通常让人误以为是延迟问题。但在大多数情况下，延迟并不是根本原因，解决方案可能就在另一个出口节点。
当验证服务拒绝一次尝试时，它会重新下发验证，并在 cookie jar 中写入自身的重试标记。Browser 可以读取该标记。它不会持续等待直至超时，而是在约 17 秒内返回响应，明确指明服务商、已执行的点击操作以及是否获得了通行权限：
Timeout after 12s: the cloudflare challenge did not complete from this exit
(2 checkbox presses, clearance granted, challenge re-issued by the site)
其中一行提示您改用其他方式发送 request。另一行则毫无有效信息。
API 层的错误信息也更加直观。等待超时的 request 会明确返回 timeout，无法访问的服务会返回 unavailable，当 request 根本没有配置 proxy 时，绝不会将其归咎于 proxy 问题。Browser 调用的 timeout_ms 会完全遵循 API 允许的 120 秒上限，因此响应缓慢的目标能够获得您设定的完整时间预算，您看到的是引擎本身的判定结果，而非来自网关的判定。参数详见 API reference。
账单信息，以及在开票当月更正发票
保加利亚发票的收件人栏目中需要打印公司法定代表人（MOL）。此前系统并未采集该信息，导致该栏目始终为空。现在账单信息已包含该字段。
如果发票仍处于开票当月内，且其锁定的信息与您当前的账单配置不一致，Invoices 列表现在提供了 Update details 选项。对话框会明确列出变更的每个字段及其新值，并清晰说明发票编号、日期和金额均保持不变；点击确认即代表您的授权，该记录将保存在我们端。处于修改窗口期内但无需更改的发票会显示 "Editable until" 及其截止日期，让窗口期清晰可见，而非事后才获知。
Under the Hood
Dashboard 运行的所有脚本均由我们自己的源站提供服务，登录后只会重定向至本站路径。
渲染服务的发布采用逐台服务器推进的方式，每台服务器都必须成功响应真实页面后，才会开始处理下一台。
在状态页面上，issues endpoint 会通过其公开 API 提供待解决和已解决的事项，与页面上列出的内容完全一致。
明确指出原因的拒绝只需一次调用即可定位。以 "Timeout" 结束的等待则需要猜测下一步该尝试什么，且耗费相同的成本。错误信息也是产品体验的一部分，本周我们已开始将其作为标准产品特性来对待。