PAC Request Policy：浏览器级请求函数

引言

Proxy Auto-Config 文件已经存在很久。PAC 文件让浏览器按请求决定使用哪个代理路径，或者是否直接连接。这个决定发生在浏览器网络层里，在请求离开浏览器之前完成，因此它不同于页面脚本、自动化框架 hook 或应用层请求处理器。

这个老功能在现代浏览器工作流里仍然很有价值。团队现在很少只在一台机器上跑一个浏览器和一个代理。更常见的是：profile-backed 会话、Windows/macOS/Linux 主机、headless server、代理池、地区路由、长导航链、媒体较多的页面，以及不同自动化框架一起运行。路由决策需要和浏览器身份保持一致，而不是散落在多个辅助脚本里。

BotBrowser 的 PAC Request Policy 支持面向经批准的企业工作流。它把 request-aware policy 放回浏览器受控网络模型里，同时保留标准 PAC 路由行为。这样团队可以用更干净的方式表达请求策略，而不必把每个路由决定都放进页面代码或框架特定的请求处理器。

本文介绍公开 PAC 函数模型、支持的请求动作、部署来源，以及浏览器级请求策略比框架拦截更清晰的产品场景。快速配置请看 PAC Request Policy 文档和 CLI flags reference。

为什么 PAC 仍然重要

PAC 表面上很简单：浏览器询问一个策略应当如何路由某个 URL。简单正是它的价值。路由属于浏览器网络栈附近的问题，而不是页面框架已经开始处理请求之后才补上的逻辑。

代理决策经常不只看目标域名。有些请求应当走住宅或移动线路。有些请求需要走地区代理。有些内部服务应当保留在本地路径。有些静态资产可以和认证导航使用不同路径。有些企业工作流需要对少数请求类别应用更严格的策略，同时让页面其他部分保持普通浏览器行为。

把这些决策放进应用代码在小脚本里可行，但工作流变大后就难维护。Playwright route handler、Puppeteer request handling、旁路代理服务、Node 服务和 PAC 文件都会变成可能改变请求行为的位置。支持排查时，第一个问题就变成：到底是哪一层做了路由决定？

PAC 可以减少这种不确定性。浏览器拥有路由问题。规则跟着浏览器启动配置走。导航请求、子资源、跳转和浏览器管理的请求都更自然地服从同一策略。

对隐私浏览器工作流来说，这一点很重要，因为身份不只是 JavaScript。网络路径、路由选择、profile locale、timezone、browser-family 行为和页面运行时信号都需要一致。一个 profile 在页面里看起来一致，但如果网络路径不一致，整体保护仍会变弱。PAC 让路由侧的模型更明确。

浏览器外请求逻辑的问题

自动化框架提供了有用的请求控制。它们适合测试、mock 和简单任务，但不一定适合承担企业路由策略。

页面级请求处理器通常绑定到某个 page 或 context。它可能依赖框架特定的设置步骤，也可能要求在导航开始前先启用请求处理模式。当 service worker、redirect、preload、popup 或浏览器管理的请求进入工作流时，这种模型会更难推理。

旁路代理服务则是另一种取舍。它把网络逻辑集中在浏览器外部，但也把策略和定义浏览器身份的 profile 分开。代理服务能看到网络流量，但不一定知道当前应该使用哪个 profile、context 或 browser-family identity。团队可以继续传递额外元数据，但这样运行模型会变得比浏览器会话本身更大。

单一启动 flag 也有局限。只有一个路由时，--proxy-server 很干净。当浏览器需要按请求类别、域名组、环境或工作流阶段选择路径时，它就不够细。

PAC 处在这些方式之间。它是浏览器原生的、request-aware 的，并且可以作为一个小策略文件部署。它可以靠近浏览器启动配置，随会话配置一起审查，也能在支持排查时保持可理解。

BotBrowser 的方式

BotBrowser 支持可信 PAC request policy，用于需要把路由决策留在浏览器网络模型中的企业工作流。标准 PAC 路由仍然可用。团队仍然可以用 PAC 选择 direct route、HTTP proxy、HTTPS proxy、SOCKS route 或浏览器支持的其他标准 PAC 结果。

额外价值在于运行一致性。可信 PAC policy 可以和 profile、启动配置放在一起。路由策略、浏览器身份、代理配置和自动化入口都在同一个可审查包里，而不是散落在页面脚本和框架代码里。

配置仍使用标准 --proxy-pac-url 形态：

chromium-browser \
  --bot-profile="profiles/profile.enc" \
  --proxy-pac-url="file:///absolute/path/to/policy.pac"

当策略由内部控制面生成时，受控 loopback PAC 服务也是常见形态：

chromium-browser \
  --bot-profile="profiles/profile.enc" \
  --proxy-pac-url="http://127.0.0.1:8080/policy.pac"

策略来源要明确。本地文件适合审计，也适合跟随任务定义一起版本化。loopback 服务适合内部工具按 worker 提供策略。两种方式里，policy 都应当被看作浏览器环境的一部分，而不是随手加的辅助脚本。

PAC Request Policy 面向经批准的企业使用。它应当和 profile-backed browser identity、清晰的 route ownership、常规 privacy validation 配合使用。它不是 responsible use controls 或客户侧授权检查的替代品。

公开函数模型

BotBrowser PAC Request Policy 首先保留标准 PAC 入口：

function FindProxyForURL(url, host) {
  if (dnsDomainIs(host, "example.internal")) {
    return "DIRECT";
  }
  return "SOCKS5 proxy.example.com:1080";
}

FindProxyForURL(url, host) 仍然用于普通代理选择。它接收 URL 和 host，然后返回标准 PAC 结果，例如 DIRECT、PROXY、HTTPS、SOCKS、SOCKS4 或 SOCKS5。

经批准的 ENT Tier3 profile 可以在同一个可信 PAC source 中增加 BotBrowser 请求回调：

function BotBrowserFindProxyForRequest(url, host, method, headersB64, bodyB64, bodyState) {
  if (method === "POST" && dnsDomainIs(host, "api.example.test")) {
    return "CAPTURE; CAPTURE_FILE /var/botbrowser/captures/api.jsonl; CAPTURE_TAG api-post; CONTINUE";
  }
  if (shExpMatch(url, "https://media.example.test/*")) {
    return "SOCKS5 media-proxy.example.net:1080";
  }
  if (dnsDomainIs(host, "static.example.test")) {
    return "HTTPS static-proxy.example.net:8443";
  }
  return "CONTINUE";
}

BotBrowserFindProxyForRequest 是浏览器请求策略回调。它不会取代标准 PAC。当回调返回 CONTINUE，或没有返回有效路由时，请求继续走标准 PAC 路由。当它返回标准 PAC route 时，该 route 只应用于当前请求。

回调接收 6 个值：

参数	含义
url	完整请求 URL。
host	请求 hostname。
method	HTTP 方法，例如 GET 或 POST。
headersB64	Base64 编码后的请求 headers record。
bodyB64	当 body bytes 可用时，Base64 编码后的请求 body。
bodyState	Body 可用状态：none、bytes、file、stream、too_large 或 unsupported。

这让 PAC policy 获得比标准 FindProxyForURL 更多的请求上下文，同时仍然把决策留在浏览器网络路径里。

请求动作

BotBrowser 回调可以返回路由动作、控制动作和采集动作。多个动作可以用分号组合。

返回值	行为
CONTINUE	继续处理请求。如果回调没有提供 route，则使用标准 PAC 路由。
BLOCK	停止当前请求。
CAPTURE	与 CAPTURE_FILE <path> 配合时，为当前请求启用采集。
CAPTURE_TAG <tag>	给采集记录附加短 tag。
CAPTURE_FILE <path>	与 CAPTURE 配合时，把采集记录写入批准的绝对路径。
DIRECT	当前请求直接连接。
PROXY host:port	当前请求走 HTTP proxy。
HTTPS host:port	当前请求走 HTTPS proxy。
SOCKS host:port	当前请求走 SOCKS proxy。
SOCKS4 host:port	当前请求走 SOCKS4 proxy。
SOCKS5 host:port	当前请求走 SOCKS5 proxy。

采集是显式动作。单独返回 CAPTURE_FILE <path> 不会写记录。必须同时返回 CAPTURE 和 CAPTURE_FILE <path>。CAPTURE; CAPTURE_FILE <path>; BLOCK 会先写入批准的采集记录，然后停止请求。CAPTURE; CAPTURE_FILE <path>; CAPTURE_TAG <tag>; CONTINUE 会记录请求并继续使用正常路由。

返回字符串也可以同时表达 policy 和 route selection。媒体请求可以返回 SOCKS5 route，内部 host 可以返回 DIRECT，普通导航可以返回 CONTINUE，让默认 FindProxyForURL 结果继续生效。

可信 PAC 来源

请求回调只从部署方控制的明确 PAC source 中启用：

• file:// PAC 文件。
• data: PAC URL。
• Loopback HTTP(S) PAC 服务。
• 部署方控制的明确远程 HTTP(S) PAC 服务。

PAC auto-detect 和 WPAD 仍可用于标准 PAC 路由，但不适合作为 BotBrowser request callback 的来源。企业 request policy 应来自已知文件、受控 loopback 服务，或通过 HTTPS 提供的受控远程服务。

这个 trust model 在生产中很重要。PAC 文件可以路由流量、停止选定请求，或写入批准的采集记录。它应当被视为浏览器启动包的一部分，和 profile、proxy inventory、worker configuration 使用同样的审查纪律。

适用场景

PAC Request Policy 最适合一个工作流里存在多个请求类别，但仍需要一个一致浏览器身份的情况。

搜索或监控工作流可能需要导航请求走地区路由，而静态资产使用另一条路径。QA 工作流可能需要内部测试 host 保持本地路径，同时外部页面跟随选定 profile route。多地区验证任务可能希望用小型策略表定义路线，而不是在每个自动化脚本里写不同逻辑。

它也适合团队希望同一浏览器工作流可以在 Playwright、Puppeteer、raw CDP 或 worker service 下运行，而不必为每个框架重写路由逻辑。策略留在 PAC 里。自动化框架负责启动浏览器和驱动页面。浏览器负责网络路由决定。

职责划分可以很清楚：

• profile 定义浏览器身份。
• proxy configuration 定义可用网络路径。
• PAC policy 为请求类别选择路径。
• automation framework 执行工作流。
• validation process 检查结果是否保持一致。

这种划分降低了支持、QA 和平台团队排查变化时要检查的位置数量。

与 Per-Context 工作流的关系

Per-context 浏览器运行增加了清晰策略边界的必要性。一个浏览器实例可以承载多个独立 context，每个 context 有自己的 profile、proxy route、storage 和 runtime behavior。如果请求逻辑散落在 page handler 中，就更难知道哪条规则属于哪个 context。

PAC Request Policy 让团队可以把网络策略靠近 context 的启动配置。一个 context 可以携带它需要的 profile 和 routing policy，而不依赖全局进程假设。对于复用 worker、持续创建和销毁 context、或同一主机运行多个 profile family 的 fleet，这一点尤其重要。

browser-family consistency 也是同一原则。profile-backed browser identity 不应和网络行为分离。如果工作流要验证 browser family、region 和 route，请求策略就应当成为验证包的一部分。

部署建议

把 PAC policy 当作生产配置。它应当和任务定义放在一起，像代码一样审查，并保持足够小，让运维人员能理解预期路由行为。

优先使用明确的策略来源。稳定部署适合本地文件。worker agent 需要为当前任务提供策略时，适合 loopback 服务。避免依赖难以复现的机器环境状态。

策略命名保持朴素。任务目录里的 policy.pac 比目的不明的生成路径更容易审查。如果使用生成策略，随任务输出 manifest，保证启动方式可以复现。

路由归属要清楚。页面路由变化时，先看 PAC 文件。代理凭据变化时，先看代理清单。profile 变化时，先看 profile package。把所有问题混在一个 helper 脚本里会让支持变慢。

敏感工作流中，通用自动化日志不应记录请求内容。运行日志应关注 route decision、policy version、profile family 和高层结果。只有在授权支持审查需要时，才把详细证据放入受控支持包。

验证

验证应确认策略行为符合部署计划，但不需要把文档变成低层请求检查教程。

先建立简单 route matrix。列出工作流里重要的请求类别、每类请求预期的 route family，以及会运行会话的 profile family。把这个 matrix 放在部署配置附近。

用生产相同的 profile 和 route setup 运行工作流。一起检查页面行为、路由行为和浏览器信号一致性。只在合成页面上可用、但在真实导航链里变化的路由策略是不够的。

浏览器更新、profile 更新或代理清单变化前后都应重复同一验证。PAC policy 最有价值的地方，是成为 release process 的一部分，而不是一次性启动选项。

规模化时，不要只验证一台本地机器。主机网络、代理可用性、文件路径和服务启动顺序都会影响路由行为。能在真实 fleet 上稳定运行的策略才更有用。

常见错误

第一个错误是把 PAC 当成附属配置。如果浏览器网络路径关系到 privacy 和 consistency，PAC 文件就是产品环境的一部分。它应当被版本化、审查，并和启动配置放在一起。

第二个错误是把同一规则拆到太多层。若一个路由决定一部分在 PAC、一部分在 Playwright、一部分在旁路代理、一部分在任务代码中，支持排查就会变成猜测。为每个决定选定归属层，并保持在那里。

第三个错误是用 PAC 弥补 profile 不匹配。PAC 可以选择路径，但不能让不一致的 profile 变得一致。浏览器身份、locale、timezone、proxy region 和 route policy 仍然需要一起规划。

第四个错误是让策略过于聪明。覆盖实际需要路线的小策略，比包含大量少用分支的大策略更容易验证。先从最小 routing map 开始，只在运行需要时扩展。

第五个错误是忘记 headless 和 server deployment。如果生产在 Linux container 或 headless server 中运行，只做本地桌面测试不够。PAC loading、file access、loopback service startup 和 route behavior 都应在相同部署形态下验证。

FAQ

这和普通 PAC 文件一样吗？

它从标准 PAC 模型开始。标准 PAC 路由仍然可用。BotBrowser 在可信 PAC sources 周围增加了企业 request policy 运行模型，让 route policy 可以靠近 profile-backed browser session。

它会替代 --proxy-server 吗？

不会。一个代理路径足够时，使用 --proxy-server。当浏览器需要 request-aware routing 且策略需要审查时，使用 PAC。

可以从本地 PAC 文件运行吗？

可以。本地 PAC 文件适合稳定策略并随任务版本化。受控 loopback PAC 服务适合内部工具按 worker 动态提供策略。

能和自动化框架一起使用吗？

可以。框架负责启动和驱动浏览器，PAC 负责 route selection。这样路由策略对某个框架的请求处理 API 依赖更少。

每个工作流都应该用 PAC 吗？

不需要。请求类别或 context 需要不同路由决策时，PAC 才有价值。简单单一路由工作流应保持简单。

总结

PAC Request Policy 给企业团队一种浏览器级方式，把 request routing、profile identity 和 automation workflow 保持在同一个模型里。它保留标准 PAC 的优点，同时适配现代 BotBrowser 部署：profile-backed sessions、per-context operation、headless workers、proxy-aware routing 和 repeatable validation。

当 routing policy 是浏览器环境的一部分时，使用它。保持 policy 明确、可审查，并靠近 profile 和启动配置。用真实工作流验证它，而不仅是最小测试页面。对于把浏览器当作基础设施运行的团队，这能让 request-aware policy 留在 BotBrowser privacy protection stack 的同一个运行模型中。

配置细节请看 PAC Request Policy、Proxy Configuration 和 Per-Context Proxy。