全部文章

FourA 简报 (2026年5月8日至5月15日)

控制台现已提供用于构建 API 调用的真实请求调试台,且 `unblocker: true` 在 Single 和 Proxy Finder 上已恢复端到端运行。

亮点

现在你可以直接在控制台中基于自己的 API key 构建、发送和重放 request。新的测试区涵盖了全部三款产品,并在多次运行中保留 cookie、预设和历史记录。同时发布了两个可靠性修复,unblocker: true 几周来一直在悄然退化(现已恢复端到端功能),此外 Browser 现在可以可靠地捕获 Cloudflare 的被动挑战 cf_clearance cookie。

最新动态

控制台测试区

/dashboard/#playground 现在是一个真正的工作台。包含三个产品选项卡(Single、Proxy Finder、Browser)、一个 URL 栏、header、body,以及匹配每个产品实际 schema 的所有特定产品 flag。发送 request,并在 JSON、HTML 和文本视图模式下查看 response 渲染。使用 Ctrl/Cmd+K 在 response 面板中进行搜索。需要阅读大量 HTML 时,可将 response 展开至全屏。

我们在以自身期望的方式构建它时,实现了一些功能:

  • 接收到的 cookie 会保存到每个主机的存储罐中。对同一主机的下一个 request 会自动附加它们,你可以在发送前检查、编辑或删除任何 cookie。
  • 可用 proxy 栏会收集成功运行 Proxy Finder 后返回的每个 proxy ID,你可以点击“使用”,在 Single 或 Browser request 中重用该 proxy 而无需重新输入。
  • 将 request 保存为预设。可从历史记录对话框重放最近 20 次运行中的任何一次。
  • curl 复现工具显示了你在终端中发送相同 request 所需运行的确切命令(包含 x-api-key)。

测试区会签署一个短期的内部 token,因此你的明文 key 永远不会离开控制台。配额、指标和 last_used_at 会计入你选择的 key,与你在自己的代码中发送 request 的方式相同。

unblocker: true 已恢复端到端功能

我们发现了一个构建问题,在过去几周里,该问题导致带有 unblocker: true 的 Single 和 Proxy Finder request 被悄悄降级。构建发布时没有实际接入绕过功能,因此本应通过握手级别反机器人拦截的 request 反而获得了通用的 request 签名。本应允许我们通过的站点阻止了我们。

修复已部署。我们在十一个实际目标上进行了端到端验证,其中包括三个以前需要 Browser 才能通过的 Cloudflare 拦截页。Single 现在可以自行通过它们。链式的 Proxy Finder + Browser + Single 流程(寻找 proxy,从 Browser 获取 cf_clearance cookie,使用 Single 加上该 cookie 加上相同的 proxy 发送页面 request)在一次往返中返回完整的 HTML。

这是我们的责任。unblocker: true 在发布当天运行良好,并在例行重建期间悄然损坏。如果你在过去几周对受保护站点运行了带有 unblocker: true 的 request,并且在预期返回 200 时看到了 403,这就是原因。请重试。

Browser 支持处理 Cloudflare 的被动 JavaScript 挑战

Cloudflare 有两种质询模式。主动模式(HTTP 403 加插页)我们已经处理了。被动模式更隐蔽:页面立即返回 200,但 Cloudflare 注入一个异步 JavaScript 探针采集客户端指纹,然后才下发 cf_clearance cookie。在修复之前,Browser 在探针完成前就结束了响应,因此该通行 cookie 从未存入 cookie 罐。

Browser 现在显式监听 Set-Cookie 事件,如果在 body 中看到被动质询标记,则等待 cf_clearance。没有轮询,没有固定宽限期,非 Cloudflare 站点没有额外等待。测试套件中的 12 个真实域名(其中 3 个在被动路径上)现在都能可靠返回通行 cookie。

修复 API 边缘的 SSRF 漏洞

有效的 pk_live_... API 密钥并不意味着可以访问我们的私有网络。如果目标的字面主机名或 DNS 解析结果落入 RFC 5735、6598 或 IPv6 保留网段,API 现将拒绝该目标。同样的检查作为第二道防线在每个后端产品上运行。

表面上你不会看到任何区别。我们在完成 TCP 握手前拦截了一类内网探针。

博客启用独立社交预览,修复分页

现在每篇博客文章都会生成专属的 Open Graph 图片,将文章标题和摘要渲染到品牌卡片上。将 foura.ai/blog/... 链接粘贴到 Discord、LinkedIn、Slack 或 Twitter 中,你将看到特定于该文章的预览,而不是通用的后备图片。

博客索引的分页之前悄然损坏了。“Older”按钮会把你送回第一页。我们在基于路径的 URL (/blog/page/N/) 上重建了它,添加了带智能窗口的数字导航,并为分页系列添加了适当的 rel=prev/next 链接标签。旧的 ?page=N URL 通过 301 重定向到新格式,因此在此之前抓取的任何内容都不会丢失。

幕后更新

我们的 MCP 服务器现已在 mcp.foura.ai 上线,供任何支持 Model Context Protocol 的 LLM 工具使用。身份验证使用与 REST API 相同的 pk_live_... Bearer token。它将这三个产品作为工具公开 (Single、Proxy Finder、Browser) 以及少量提示。如果你将 FourA 接入 Claude Code 或任何支持 MCP 的智能体,你不再需要运行本地网桥。

如果你之前因为旧的 playground 功能简陋而没有使用 dashboard,本周可以打开看看。它现在是我们自己在调查 API 目标异常时使用的界面。