亮点
您现在可以直接在控制台中针对自己的 API key 编写、发送和重放 request。全新的 playground 覆盖全部三款产品，并在多次运行之间保留 cookie、预设和历史记录。同时上线了两项稳定性修复：unblocker: true 此前隐蔽降级了数周（现已完全恢复正常端到端运行），以及 Browser 现在可以稳定捕获 Cloudflare 的被动质询 cf_clearance cookie。
新增功能
控制台 Playground
/dashboard/#playground 现已成为真正的工作台。提供三个产品标签页（Single、Proxy Finder、Browser）、URL 栏、header、body，以及对应各产品实际 schema 暴露的全部产品特定参数。发送 request 后，可通过 JSON、HTML 和文本视图模式查看渲染的 response。使用 Ctrl/Cmd+K 可跨 response 面板进行搜索。需要阅读大量 HTML 时，可将 response 展开至全屏视口。
我们在按自身使用需求构建该功能时实现的几个特性：
- 接收到的 cookie 会保存到基于 host 的 cookie jar 中。后续向同一 host 发送 request 时会自动附加这些 cookie，您也可以在发送前检查、编辑或删除任何 cookie。
- 有效 proxy 侧栏会收集 Proxy Finder 成功运行返回的所有 proxy id，您可以直接点击“use”在 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 一直在被静默降级。发布该版本时未实际接入浏览器 profile，导致原本应携带浏览器签名的 request 采用了通用 request 签名。原本应该放行的网站拦截了我们的请求。
修复现已部署。我们在包括 3 个此前需要 Browser 才能通过验证页面的 11 个真实目标网站上进行了端到端验证。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 从未写入 cookie jar。
Browser 现在会显式监听 Set-Cookie 事件，并在 HTML body 中检测到被动质询标记时等待 cf_clearance。无需轮询，没有固定宽限期，也不会对非 Cloudflare 站点产生额外等待。测试套件中的 12 个真实域名（其中 3 个走被动路径）现在均可稳定返回 clearance cookie。
修复 API 边缘的 SSRF 漏洞
有效的 pk_live_... API key 并不意味着可以访问我们的内网。API 现在会拒绝任何主机名字面量或 DNS 解析结果属于 RFC 5735、6598 或 IPv6 保留网段的目标。每个后端产品都会运行相同的检查，作为第二道防线。
从外部看没有任何变化。我们在 TCP 握手完成之前就阻断了针对内网的探测行为。
博客支持独立社交分享预览，修复分页问题
现在每篇博文都会生成专属的 Open Graph 图片，将文章标题和摘要渲染到品牌卡片上。将 foura.ai/blog/... 链接粘贴到 Discord、LinkedIn、Slack 或 Twitter 时，你将看到文章特定的预览，而非通用的默认兜底图。
博客首页的分页此前存在隐性错误。点击 "Older" 按钮会跳回第 1 页。我们将其重构为基于路径的 URL（/blog/page/N/），添加了带智能窗口的数字导航，并为分页系列配置了正确的 rel=prev/next link 标签。旧的 ?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 目标出现异常时，我们自己也会通过该控制台进行排查。