Cloudflare Browser Run 加强浏览器自动化调试：失败任务先查再重跑

Cloudflare 在 2026 年 9 月 18 日改写了失败任务的浏览器自动化调试流程。现在，完成一次 Browser Run 录制后，就能查看控制台日志、网络请求和最终页面结构；在再次启动浏览器之前，先把这次付费运行已经留下的证据查清楚。

浏览器自动化调试多了一份运行后证据包

过去，浏览器任务结束后只会留下运行输出和错误处理结果；如果事先启用了 Session Recording，还能回放过程。可一旦错误本身说不清原因，常见做法还是加日志，再跑一遍。

新的 Inspect 面板 会在已完成的录制旁提供三个视图：

• Logs：搜索捕获到的控制台输出，并按日志级别筛选。
• Network：查看每个请求的方法、状态、请求头、载荷、响应和耗时。还可将网络活动导出为 HAR 文件，即浏览器请求轨迹的标准归档格式。
• DOM：查看录制结束时的页面结构，并复制重建后的 HTML。DOM 指浏览器根据页面构建的元素树。

这是一组运行结束后的证据，并非又一个实时调试界面。Cloudflare 的 Session Recording 保存的是结构化 rrweb 事件数据，而不是视频。它会记录 DOM 变化、鼠标和键盘事件以及页面跳转。会话关闭后，Inspect 面板再把可搜索的线索补到回放旁边。

这也让本次发布与 Cloudflare 之前的 Browser Run 更新有所不同。会话访问边界与只读 Live View 管的是运行中的任务可以访问哪里，以及客户旁观时能做什么；Inspect 则帮助团队解释一个已经结束的任务为何失败。

哪些故障能从录制中看出来？

只要故障在浏览器里留下了证据，这个面板就能派上用场。

独立 SaaS 创业者可以找到被拒绝的请求

假设一个周期性采集任务已经打开页面，却没有返回数据。Network 视图可以显示 API 是否返回 401、限流是否返回 429、重定向是否把浏览器带到了意外位置，或某个依赖是否耗掉了大部分运行时间。

先检查请求和响应详情，再考虑添加临时日志。这样首轮诊断就能更聚焦：现有运行已经暴露了问题，接下来只需处理凭据、退避策略、重定向或缓慢依赖。

服务商负责人可以分清页面变更与脚本缺陷

客户工作流可能因为选择器变化、登录页取代预期界面，或资源请求报错而失败。最终 DOM 和复制出的 HTML 会还原浏览器最后停在什么页面，请求轨迹则交代它是如何到达那里的。

交付团队因此能拿到一份明确的排障材料，不再只有一句“自动化坏了”，而是最终元素树，以及一份包含可获取的请求头、载荷、状态码和耗时的 HAR。

平台工程师可以追踪正确的标签页

录制会按 Chrome DevTools Protocol 的 target（例如 target-1）组织事件数组，每个 target 通常对应一个浏览器标签页。多标签页录制会分别暴露这些 target，控制台里的 Inspect 面板也会跟随当前选中的标签页。

这对认证跳转和智能体工作流很关键：登录标签页可能成功，真正执行任务的标签页却失败。按 target 拆分证据，能避免把两条过程混在一起。

录制一次任务，再取回网络轨迹

录制需要主动开启。必须在首次获取浏览器会话时启用；重新连接已有会话后，无法再补开录制。

最小而实用的起点，是选一个目前仍需人工复现故障的周期性 Browser Session。

1. 1

   启动时启用录制

   Cloudflare 的 Puppeteer 示例在首次启动调用中传入 recording: true。关闭浏览器前，先保存会话 ID：

   import puppeteer from "@cloudflare/puppeteer";
   
   interface Env {
   	MYBROWSER: Fetcher;
   }
   
   export default {
   	async fetch(request: Request, env: Env): Promise<Response> {
   		const browser = await puppeteer.launch(env.MYBROWSER, { recording: true });
   		const page = await browser.newPage();
   
   		await page.goto("https://example.com");
   		// ... your automation steps ...
   
   		const sessionId = browser.sessionId();
   		await browser.close();
   
   		return new Response(`Session recorded: ${sessionId}`);
   	},
   };

   Playwright 使用相同的启动选项。通过 CDP 连接时，则在 WebSocket URL 中加入 recording=true。

2. 2

   请求已完成的录制

   会话关闭后，用它的会话 ID 请求录制：

   curl https://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/browser-rendering/recording/<SESSION_ID> \
     -H "Authorization: Bearer <API_TOKEN>"

   响应会把事件数组放在 result.events 下。这里的键（例如 target-1）就是发起网络请求时所需的 target ID。Cloudflare 整理新录制时，查询可能短暂返回 404；此时应重试查询，而不是把第一次 404 当成录制丢失。

3. 3

   取回指定 target 的原始请求

   从录制响应返回的 target 中选一个。target 参数不可省略：

   curl 'https://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/browser-rendering/recording/<SESSION_ID>/network?target=<TARGET_ID>' \
     -H "Authorization: Bearer <API_TOKEN>"

   接口会以 JSON 返回捕获到的请求，其中包括现有的请求与响应详情。

4. 4

   导出 HAR

   如果开发人员需要在浏览器网络查看器或其他分析工具中打开轨迹，请添加 format=har：

   curl 'https://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/browser-rendering/recording/<SESSION_ID>/network?target=<TARGET_ID>&format=har' \
     -H "Authorization: Bearer <API_TOKEN>"

   应把这个文件当作调试产物，只提供短期、受控的访问。文档说明响应可能包含可获取的请求头和载荷，因此它应按任务数据的同等级别处理。

最容易踩的坑，是等第一次故障发生后才启用录制：历史运行无法凭空补出证据。先从下一次故障值得追查的周期性任务开始。

浏览器费用不是成本大头

Cloudflare 当前的 Browser Run 定价 没有单列录制费或录制存储费。启用录制的 Browser Session 仍按常规的浏览器小时数和并发量计费。Session Recording 目前处于 beta 阶段，因此这只是现行公开价格，不应视为永久承诺。

Workers Free 每天包含 10 分钟浏览器时长，并支持三个浏览器并发。Workers Paid 的账户月度最低消费为 $5，其中包含 10 个浏览器小时和 10 个浏览器并发；超出后，每个额外浏览器小时收费 $0.09，每个额外浏览器并发收费 $2，并发用量按当月每日峰值的平均数计算。

一次诊断性重跑的直接费用很低，围绕它投入的人力却不低。下面只是规划模型，并非 Cloudflare 基准：

• 账户已用完内含的 10 个浏览器小时。
• 一个周期性任务每次运行 10 分钟，并在一个月内失败 12 次。
• 每次复现并诊断故障需要操作人员投入 20 分钟。
• 检查现有录制需要操作人员投入 5 分钟。
• 假设操作人员的综合成本为每小时 $75。
• 检查可以省去一次诊断性重跑，但修复后可能仍需再运行一次做验证。

这笔差额中，原始浏览器时长只占 18 美分，其余 $225 都是人力成本。Cloudflare 还会先汇总整个账期的浏览器用量，再以账户为单位取整，因此不要把一次 10 分钟运行对应的 1.5 美分，当成账单上必然出现的一项明细。

这才是对业务真正有影响的部分。Inspect 面板不会让浏览器算力本身省下一大笔钱，却有机会从事故处理中删掉一次“加埋点、复现、等待”的循环。

录制无法告诉你的信息

录制捕获的是文档状态与事件，不是每个渲染像素。

这些限制决定了哪些故障仍需换一种诊断方式。Canvas 绘制的图表、第三方 iframe 中的结账表单、视频状态、WebGL 场景，或输入到已遮蔽字段中的值，都可能出错，而周围的录制看起来仍一切正常。

DOM 视图展示的也是录制结束时的结构。它能说明任务最终停在什么页面，却不是此前每个状态的逐像素截图。

此外还有运行限制。录制会保留 30 天，单次时长至少 1 秒、最多 2 小时，并支持通过 launch() 或 CDP 启动的 Browser Sessions；Quick Actions 无法创建录制。页面活动特别频繁时，可能产生很大的事件流，因为每一次高频 DOM 变化都会变成录制数据。

谁应该现在就调整工作流？

如果周期性 Puppeteer、Playwright 或 CDP 任务一出错，就通常要先由人工复现，那么本周就值得行动。先给一个任务加上录制，而不是一次铺到所有任务，再衡量录制能否回答第一个诊断问题。

如果关键状态主要存在于 Canvas、WebGL、媒体、跨域 iframe 或已遮蔽的表单字段中，可以暂缓。在这条路径上继续保留截图、应用日志和定向埋点，因为录制无法取代它们。

如果工作始终停留在 Quick Actions，则本次更新没有影响。仅为录制而迁移到 Browser Sessions，不仅需要改实现，还会把并发量纳入定价模型；调试收益必须足以支撑这次迁移。

周一就做这件事

选一个曾多次失败的周期性 Browser Session。在首次启动时加入 recording: true，把会话 ID 与自己的任务 ID 存在一起，并让下一次计划任务正常关闭。

随后取回录制，拿到第一个相关 target ID，再请求原始网络轨迹或 HAR。记录从开始检查到确认失败请求或最终页面状态所需的时间。如果这些证据省掉了一次诊断性重跑，就为这个任务保留录制，并把轨迹纳入事故记录；如果没有，就关闭录制，把缺少的信号补到真正的盲区。

如果希望继续看到面向一线操作者的平台更新解读，欢迎订阅邮件通讯。