更新日志

在暗色主题下，下拉菜单、复选框、滚动条、自动填充字段和对话框按钮曾显示为亮色外观(白色框、多余的轮廓)。现在，所有控件均遵循当前活动的主题。模态框不再导致底层页面滚动，对话框内的工具提示现在置于顶层显示，数字输入框隐藏了其微调按钮。

之前由于未设置底层链接，部分已付款发票的 PDF 按钮无法渲染。现在发票标签页中的所有已付款发票均已配置可用的 PDF 按钮。

如果您将负值的 validate 传递给 /api/auto（例如 {data: {fail: ['"Due to legal reasons"']}}），Cloudflare “Just a moment” 插页可能会作为缓存的成功响应漏过，因为失败列表碰巧没有匹配其文本。Auto 现在会在应用您的验证规则之前拒绝质询页面，它会更换无效出口并重新解析，而不是对其进行评分。

如果您通过托管 MCP 服务器在 foura_auto 上设置了较长的超时时间，请求可能会在调用完成之前在边缘节点超时。该问题已修复。全预算的 auto 调用现在可以端到端地运行其完整的 180 秒预算。

如果您在对同一目标发起大量并发 Auto 请求时遇到 429 错误，过去这些请求会集中到一个缓存出口，因为预热路径会选择分数最高的出口并执行一次重放。现在，Auto 会根据需要建立额外的会话，并将每个请求路由至负载最低的出口。因此，突发流量会分散至多个 proxy ID，而不是向单个出口施压。本地测试结果：在无 cookie 的便携式主机上，100 个请求的突发流量现在可以在数秒内分散至已扩展的资源池中。

即使是顺利通过的页面，Cloudflare 也会注入被动脚本，而 Auto 过去会将任何对此脚本的引用视为主动质询，并强制运行完整的浏览器验证。现在，只有真正的插页标记（“just a moment”页面及类似页面）才会触发浏览器路径；纯净的 200 响应会从成本较低的 proxy 层返回。Auto 默认还会跟随最多 5 次重定向（可通过 followRedirects 配置）。

当受 Cloudflare 保护的目标在验证通过后返回真实的地理位置封锁页面 (451) 时，Browser 产品之前会将其报告为 200，因为 watcher 硬编码了验证通过后的状态。现在，watcher 会读取验证通过后的实际 Document，因此 200 仍保持为 200，451 会显示为 451，同时 Auto 会拒绝错误的内容，并继续寻找真正符合您的 validate 规则的出口。

无论使用何种键盘布局，Cmd+K (Ctrl+K) 快捷键现在均可打开命令面板和搜索模态框。此前我们匹配的是输入的字符（在西里尔布局下为 к），因此使用非拉丁布局的用户无法触发任何操作。现在我们匹配物理按键。该修复已应用于主站、博客和文档。

一次冷 Auto 解析可能需要数分钟，该 request 现在会在整个预算期内保持打开状态。来自任何层的错误都将作为客户端可解析的 JSON 返回。

支持复用 cookie 的网站（以 bet365 为测试基准）之前一直停留在昂贵的浏览器解析（每次请求 15 积分），而不是在首次解析后降至低成本的 2 积分重放。存在两个 bug：任何短暂的传输错误都会触发拦截，且成功的浏览器重放从未刷新会话 cookie。已修复这两个问题。现在，对于支持复用 cookie 的网站，首次解析后的重复请求仅消耗 2 积分，与定价说明完全一致。

我们已收紧跨域访问权限，仅允许 foura.ai 携带凭证调用 API。我们还加强了 metrics endpoint 的输入过滤器，并移除了一个仅用于开发环境的备用密钥。现有的集成不受影响。

如果你在 request 中设置了 validate.status.accept，引擎会将接受的非 200 状态码视为完全成功。Activity 之前仍将这些标记为失败，从而干扰了你的使用统计数据。现在，结果将遵循你的 validate 判定，因此你接受的 403 将显示为成功，而不是 App Fail。

如果您之前通过 Single 抓取西里尔文、中文、日文或其他非 UTF-8 页面，返回的 body 往往会显示为乱码。在您看到原始字节之前，我们曾将每个 response 强制解码为 UTF-8。现在，我们从 response 中读取字符集（依次通过 Content-Type、<meta charset>，最后回退至 UTF-8）并进行正确解码。感谢 Alexandar Kanchev (Sensika) 反馈此问题。

公开网络中的一些 proxy 实际上并没有转发您的 request。它们将其作为纯文本服务器转储回显，并试图窃取其中的内容。我们现在能在 response 到达您的代码之前识别出这种模式，因此 Single、Browser 和 Proxy Finder 都会返回明确的失败（或重试），而不是垃圾数据。

我们修复了一个导致新发现的 proxy 在验证前需要等待的延迟问题。Proxy Finder 现在会立即对它们进行检测，从而使 proxy 池保持最新状态，并有更多活跃、可用的 proxy 处于轮换中。