核心更新
现在，您直接在控制面板中即可针对自己的 API key 构建、发送和重放 request。全新的 Playground 覆盖了全部三款产品，并可在多次运行之间保留 cookie、预设和历史记录。伴随该功能一同发布的还有两项可靠性修复：unblocker: true 在过去几周内出现隐性降级（现已恢复端到端正常工作），且 Browser 现在能够可靠地捕获 Cloudflare 的被动挑战 cf_clearance cookie。
新增功能
控制面板 Playground
/dashboard/#playground 现在是一个真正的工具台。提供三个产品标签页（Single、Proxy Finder、Browser）、URL 栏、header、body，并公开了与每个产品实际 schema 相匹配的所有专属 flag。发送 request，即可在 JSON、HTML 和文本视图模式下查看渲染后的 response。使用 Ctrl/Cmd+K 即可在 response 面板中进行搜索。当需要阅读大量 HTML 时，可将 response 展开至整个视口。
我们在按照自己期望的使用方式构建它时，实现了以下几点：
- 您接收到的 cookie 会保存到基于主机的 jar 中。
- 下一次向同一主机发送 request 时会自动附带这些 cookie，并且您可以在发送前检查、编辑或删除任何 cookie。
- 可用 proxy 栏会收集 Proxy Finder 成功运行后返回的每个 proxy id，因此您可以直接点击“使用”，在 Single 或 Browser request 中复用该 proxy，无需重新输入。
- 将 request 保存为预设。
- 从历史记录对话框中重放最近 20 次运行中的任意一次。
- cURL 重现器会显示您在终端中运行以发送相同 request 的确切命令（包含
x-api-key）。
Playground 会签署一个短期有效的内部 token，因此您的明文 key 永远不会离开控制面板。额度、指标和 last_used_at 都会计入您选择的 key，这与您从自己的代码中发送 request 的效果完全相同。
unblocker: true 恢复端到端正常工作
我们发现了一个构建问题，该问题在过去几周内导致带有 unblocker: true 的 Single 和 Proxy Finder request 发生隐性降级。发布的构建版本中未实际接入旁路（bypass），因此本应通过握手级反爬虫防护墙的 request 却获取了通用的 request 签名。本应放行的网站因此拦截了我们。
修复程序已部署。我们已在 11 个真实目标上进行了端到端验证，其中包括 3 个此前需要 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 在探测程序完成之前就结束了 response，导致 clearance cookie 未能存入 jar 中。
Browser 现在会显式监听 Set-Cookie 事件，并在 body 中检测到被动挑战标记时等待 cf_clearance。无需轮询，没有固定的宽限期，对于非 Cloudflare 网站也不会产生额外的等待。测试套件中的 12 个真实域名（其中 3 个处于被动路径上）现在均能可靠地返回 clearance cookie。
修复了 API 边缘的 SSRF 漏洞
有效的 pk_live_... API key 并不意味着拥有访问我们私有网络的许可。API 现在会拒绝任何主机名本义或 DNS 解析结果落入 RFC 5735、6598 或 IPv6 保留网段的目标。相同的检查也会在每个后端产品中运行，作为第二道防线。
您在表面上不会看到任何变化。我们在其完成 TCP 握手之前就阻止了这一类内部网络探测。
博客获得专属社交预览，分页功能已修复
每篇博客文章都会生成专属的 Open Graph 图片，将文章标题 and 摘要渲染在品牌卡片上。将 foura.ai/blog/... 链接粘贴到 Discord、LinkedIn、Slack 或 Twitter 中，您将看到特定于该文章的预览，而非通用的默认图。
博客索引页的分页功能此前默默失效了。“Older” 按钮会将您带回第 1 页。我们基于路径型 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。它将这三款产品作为 tool（Single、Proxy Finder、Browser）以及少量 prompt 开放。如果您正在将 FourA 接入 Claude Code 或任何支持 MCP 的 agent，则无需再运行本地桥接。
如果您之前因为旧版 Playground 功能简陋而对控制面板望而却步，本周不妨打开它体验一下。现在，当针对某个 API 目标出现异常时，我们自己也会使用这个界面来进行排查。