Cloudflare Browser Run 实测：无头浏览器如何锁定域名并开放只读审阅

2026 年 9 月 14 日，Cloudflare Browser Run 上线了 2 项控制能力，改变了浏览器自动化项目向客户交付的方式：会话的访问范围可以锁定在获准主机名清单内，审阅人则能通过 Live View 旁观，却拿不到交互权限。配置时可以直接填写最多 50 个主机名，也可以接入最多 4 个共享域名集；不过，对无头浏览器项目真正有价值的不是清单容量，而是边界终于可以落到实处。

无头浏览器需要的是两道边界，不是一道

Browser Run 会话本质上是一个远程 Chrome 实例。代码通常借助 Puppeteer、Playwright 或 Chrome DevTools Protocol（一般简称 CDP）来操控它。

新的会话护栏决定浏览器可以通过 HTTP 或 HTTPS 请求哪些目标主机名。策略在会话启动时确定，并在整个会话生命周期内持续生效。

Live View新增的只读设置负责另一件事：限制某个人通过某一条已生成的观看链接能做什么。只读审阅人可以看到会话，但不能导航、输入、点击或执行 JavaScript。

这一区别很关键：自动化程序依然掌控浏览器，审阅人只能观察。与此同时，无论打开的是哪一条 Live View 连接，浏览器发出的 HTTP 和 HTTPS 请求都会被限制在会话允许清单内。

浏览器任务因此有了清晰的客户审阅流程

设想一家代理机构要在客户的 Web 应用中生成报告。浏览器需要访问客户的主站、身份验证主机、API、字体主机，可能还要连接图片 CDN；客户又希望在批准输出前亲眼看到任务执行过程。

现在，这两类问题可以拆开处理：

1. 技术负责人批准会话必需的目标地址。
2. 客户收到只读 Live View URL，观看任务执行。

审阅人得到的不是一台可操作的浏览器，任务拿到的也不是一份完全开放的目标清单。相比把同一条共享浏览器链接同时当作演示工具和访问控制决策，这样的交接更清楚。

但它仍不是一套完整的安全系统。Cloudflare记录的是针对 HTTP 和 HTTPS 请求的主机名控制，因此不能把它描述成通用网络沙箱。Live View URL 还包含签名 JWT，这意味着完整 URL 本身就是凭证。只读模式虽然移除了交互能力，页面上出现的内容却依然会暴露给观看者。

真正费工的是维护资产域名白名单

一个页面真正依赖的，几乎从来不只有那个最显眼的主机名。

生产页面可能在登录时重定向、调用独立 API，还会分别从不同主机加载脚本、图片和字体。Cloudflare 要求把这些依赖全部列入清单。漏掉任意一项，对应请求就会收到 403，响应头中还会出现 cf-mitigated: guardrails 和 cf-brapi-guardrails-reason: not-in-allowlist。

因此，维护允许清单会成为真实的交付成本。客户每次改版、更换身份提供商、替换分析服务或迁移 CDN，都可能带来策略变更和新一轮验证。这里不存在适用于所有项目的诚实工时数字，只能在自己的任务中实测。

Cloudflare 提供了两种携带清单的方式：

• allowedDomains 是直接配置方式，可以在会话启动调用中填写最多 50 个主机名模式。
• allowedDomainSets 最多可接入 4 份共享清单，其中既可以使用 Cloudflare 的 common-cdns 集，也可以填写返回纯文本主机名清单的 HTTPS URL。

多项客户任务需要使用同一批获准服务时，共享清单很有价值，但它也有明确的生效时序。Cloudflare 最长会缓存托管清单一小时；清单更新后，只有在刷新内容被读取之后启动的会话才会采用新规则。运行中的会话不会中途改变策略。

common-cdns 还有另一层取舍：它由 Cloudflare 维护，内容可能随时间变化。这样能减少清单维护工作，却不等于一份固定的允许清单。如果合同或审计要求目标地址保持稳定，应明确列出主机名，或使用自己托管的清单。

现在就能用上的四类团队

代理机构技术负责人：把批准权与操作权分开

先放行客户应用及其必需依赖，再启动浏览器任务，随后为客户经理或客户审阅人生成只读 Live View 链接。他们可以目睹证据生成，却无法点击进入应用或改变任务进程。其价值在于：审阅步骤不会悄然变成一次操作权限移交。

SaaS 创始人：让自包含 PDF 真正保持自包含

如果原本就使用可信的内联 HTML 生成截图或 PDF，可以用空的 allowedDomains 数组且不配置域名集来启动会话。HTML 仍会渲染，但无法通过 HTTP 或 HTTPS 获取外部 API、脚本、图片或字体。这样得到的是一条更容易验证的结论：本次渲染没有请求外部 Web 内容。

Quick Actions 不支持这一特定控制能力，其中也包括人们常用来生成截图和 PDF 的快捷端点。要使用它，必须通过 Puppeteer、Playwright 或 CDP 创建 Browser Session。

平台团队：统一管理一套依赖策略

通过 HTTPS 托管纯文本清单，每行填写一个主机名模式，再用 allowedDomainSets 引用该 URL。多套会话启动程序便可共用同一份清单。好处是维护入口只有一个，但必须记住：只要其中一行无效，整份托管清单都会被拒绝。

安全审阅人：要求提供一次失败测试

不要只展示配置。主动向未获准的主机名发起一次请求，再把 403 状态和两个护栏响应头一并存入审阅记录。真正有说服力的是反向路径确实被拦截，而不是一张看起来配置正确的对象截图。

配置一场带护栏的审阅会话

这是一段技术实操，因为该功能必须在创建会话时配置。以下代码取自本文所依据的 Cloudflare 页面。

1. 1

   安装兼容客户端并绑定浏览器

   Cloudflare 要求使用 @cloudflare/puppeteer 1.4.0 或更高版本才能启用护栏。对应的 Puppeteer 安装命令是：

   npm i -D @cloudflare/puppeteer

   Worker 还需要浏览器绑定。Cloudflare 的 Wrangler 示例将其命名为 MYBROWSER：

   {
   	"$schema": "./node_modules/wrangler/config-schema.json",
   	"name": "browser-rendering",
   	"main": "src/index.ts",
   	"workers_dev": true,
   	"compatibility_flags": ["nodejs_compat_v2"],
   	"browser": {
   		"binding": "MYBROWSER"
   	}
   }

   务必核对已安装的软件包版本。较旧的 Puppeteer 概览仍把 1.1.0 标为当前版本，但较新的护栏页面明确要求 1.4.0 或更高版本，应以功能页面的要求为准。

2. 2

   按目标地址策略启动会话

   Cloudflare 的 Puppeteer 护栏示例放行根域名及其子域名，同时接入共享的 common-cdns 集：

   import puppeteer from "@cloudflare/puppeteer";
   
   export async function startGuardedSession(env) {
   	const browser = await puppeteer.launch(env.MYBROWSER, {
   		guardrails: {
   			allowedDomains: ["example.com", "*.example.com"],
   			allowedDomainSets: ["common-cdns"],
   		},
   	});
   
   	return browser;
   }

   先盘点页面涉及的重定向、API、脚本、图片和字体，再替换示例值。请注意，*.example.com 并不包含 example.com，因此示例中需要同时写入两项。

3. 3

   证明未获准主机已被拦截

   向清单外的某个主机名发起请求。预期结果是 HTTP 403，响应头包含 cf-mitigated: guardrails 和 cf-brapi-guardrails-reason: not-in-allowlist。同时，还要沿着完整的登录与渲染路径测试获准页面。反向测试证明边界有效，正向测试证明任务仍能正常完成。

4. 4

   生成只读审阅链接

   取得会话 ID 后，可用 Cloudflare 的 REST 示例创建一个不允许观看者交互的标签页视图：

   curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/browser-rendering/devtools/browser/$SESSION_ID/live_view" \
   	--request POST \
   	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
   	--json '{
   		"mode": "tab",
   		"guardrails": {
   			"mode": "readonly"
   		}
   	}'

   应在可信的服务端代码中生成此 URL，并通过可信渠道分享。默认的连接启动期限为五分钟。expiresInMs 最低可设为 60,000 毫秒，最高为 3,600,000 毫秒，也就是一小时。

这里反复出现的 guardrails 很容易造成混淆。会话启动配置中的 guardrails 包含 allowedDomains，控制可访问的目标地址；Live View URL 请求中的 guardrails 包含 mode: readonly，控制这条连接上的观看者。想同时获得两道边界，就必须同时设置两处。

这项功能可能让任务进入另一种计费方式

Cloudflare 当前的 Browser Run 定价没有按允许清单条目单独收费。真正改变账单的，是集成方式的切换。

Quick Actions 只按浏览器时长计费，却不支持这些护栏。Browser Sessions 可以启用护栏，计费项目则包括浏览器时长与并发浏览器。如果原本使用快捷方式生成 PDF 或截图，现在又需要限制主机名，改用 Puppeteer、Playwright 或 CDP 会同时改变实现方式和成本模型。

Workers Paid 每月包含 10 个浏览器小时和 10 台并发浏览器。超出的浏览器时长为每小时 $0.09；超额并发为每台浏览器 $2.00，并按当月每日峰值的平均数计算。

实用的预算公式如下：

extra usage cost = max(0, browser hours - 10) × $0.09 + max(0, average daily peak browsers - 10) × $2.00

Cloudflare 自己的示例使用 50 个浏览器小时，并发浏览器平均数为 15。超出的 40 小时产生 $3.60，超出的五台浏览器产生 $10.00，额外用量费用合计 $13.60。这不是护栏费用，而是支持护栏的 Browser Session 路径所对应的账单。

Workers Free 每天包含 10 分钟浏览器时长和三台并发浏览器。用它做一个小型验证尚可，但要支撑包含多轮审阅的客户流程，余量并不充裕。

如果已经在使用 Browser Sessions，计费类别不会变化。新增成本主要来自运营环节：收集资产主机、测试拦截与放行路径，以及持续更新清单。如果仍在比较托管浏览器方案，可以参考这份更完整的 AI 智能体浏览器指南，了解这些用量项目在不同方案中的位置。

哪些地方仍然容易出问题

最常见的故障是：页面在开发环境中一切正常，允许清单上线后却丢失字体、图片、登录重定向或 API 请求。一个过于宽泛的通配符或许能让故障消失，却也会削弱原本想建立的边界。

Cloudflare 允许每个主机名模式使用一个通配符。对子域名应优先使用 *.example.com，并单独列出根域名。*example.com 这种前缀模式还可能匹配 evilexample.com 一类仿冒域名，因此不适合用于严格的客户策略。

只读 Live View 也有自己的边界。它只限制一条观看连接，既不能约束会话操作者，也不能阻止另一条连接控制会话。Puppeteer 和 Playwright 无法驱动只读连接，因为所需命令会被拦截。这对审阅人很有用，却无法充当自动化凭证——本就应该如此。

Quick Actions 和 Kitesurf 仍不在护栏功能范围内。使用其中任意一种方式的团队不会受到影响，除非他们认为主机名边界值得为之更换集成路径。

周一就可以这样行动

挑一个目标地址相对稳定的真实客户任务，不要从登录流程最混乱的项目开始。

盘点成功路径使用的每个主机名，包括重定向和资产主机。启动带护栏的 Browser Session，确认预期输出；随后主动请求一个未获准主机名，并保存 403 证据。最后，把只读 Live View 链接交给一名同事，确认对方只能观看、不能交互。

从这次试点记录四项数据：必需主机名数量、维护清单所花的时间、最初误拦的合法请求数量，以及并发浏览器的平均峰值。这四项数据足以判断，对该工作流而言，这是一项清晰有效的控制措施，还是一个代价高昂的承诺。

如果你要向客户交付浏览器任务，所需主机范围可以确定，而且“只观察、不控制”确实能解决审批问题，那么本周就值得行动。如果依赖频繁变化，或任务仍运行在 Quick Actions 上且尚未核算迁移到 Browser Session 的成本，应暂缓采用。如果既不运行 Browser Sessions，也不共享实时浏览器任务，这次更新不会改变你的周一安排。

如果想继续阅读面向实际操作者的平台更新解析，欢迎订阅邮件简报。