PAC 请求策略：保持浏览器路由一致

代理自动配置通常简称为 PAC，它为浏览器提供选择网络路由的策略。决策发生在浏览器的网络路径中，因此同一份策略可以覆盖导航、重定向、子资源和浏览器自行管理的请求，而不依赖页面框架。

当一个部署使用多条获批准的代理路由时，这种位置很有价值。区域浏览、内部应用测试、媒体验证和多上下文任务可能各自需要不同类型的路由。PAC 策略让这些选择靠近浏览器配置文件和启动配置。

BotBrowser 通过 --proxy-pac-url 提供标准 PAC 路由，并为获批准的企业配置文件提供写在同一个 PAC 脚本中的额外请求回调。标准 PAC 仍是默认模型。回调是可选的附加层，帮助获得授权的团队在 PAC 来源、代理清单和配置文件一并接受审核的前提下，保持一致的请求处理。

TL;DR

• 将 PAC 路由留在浏览器网络层，并让 FindProxyForURL(url, host) 可供审核。
• 记录 proxy、direct 或 blocked，同时保留用于回滚的 policyVersion。
• BotBrowser 可以应用已批准的 PAC 能力，但不会修复代理健康状况或批准目标站点。

Contents

• 为什么路由应该由浏览器管理
• 运行模型与请求回调
• PAC 请求策略的适用场景
• 保护措施与基于结果的验证
• 责任归属、上线与记录
• 恢复与维护
• Practical conclusion

为什么路由应该由浏览器管理

在策略记录中保留 FindProxyForURL(url, host) 以及 DIRECT 回退结果。

对简单会话来说，静态代理通常就够了。当同一个浏览器工作流需要多条获批准的路径时，静态代理就不太合适。把路由选择放进框架处理器还可能让 Playwright、Puppeteer、原始 CDP 与浏览器自行管理的流量表现不一致，而且在自动化层拦截请求，在某些工作流中还可能打断 HTTP/2 的连接和流连续性。

PAC 给浏览器提供一套统一的路由策略。自动化代码负责驱动页面，浏览器负责网络选择。由于策略不绑定框架，同一份策略可以服务不同的自动化工具。这样的分工让部署更容易审核，因为配置文件、代理清单和路由策略各有明确的职责。关于大型部署中如何为各网络层分配责任，可参阅企业浏览器网络边界：明确责任，避免遗漏。

这种做法也有助于隐私一致性。浏览器配置文件可以定义地区、语言、时区和设备类型，但如果流量走的是毫不相关的网络路径，这些设置就会失去意义。把路由策略放在配置文件旁边，可以减少配置文件设置与获批准出口之间的配置漂移。

何时静态代理就够了

并非每个部署都需要 PAC。当所有流量都应使用同一条路由，且没有需要维护的按请求类别划分的策略时，应优先选择静态代理。只有一条路由的上下文不需要 PAC，配置越小越容易运维，可变部分也越少。

只有当路由选择确实是浏览器层面的需求时才使用 PAC。不要仅仅为了复刻框架中已经是单一稳定路由的逻辑而加入它。策略应当降低运维复杂度，而不是把同样的复杂度搬到另一个文件里。

运行模型与请求回调

可维护的部署会把四项职责分开：

1. 浏览器配置文件定义预期的浏览器设置。
2. 代理清单定义获批准的网络路径。
3. PAC 策略为每个相关的请求类别选择路径。
4. 自动化工作流执行获授权的浏览器任务。

这种安排避免把路由规则复制到每个脚本里，也让支持团队和隐私团队有一个稳定的位置来审核路由变更，而无需阅读页面自动化代码。请使用有描述性的策略名称，并让每份策略只服务一个部署目的，因为区域验证任务、内部应用测试和媒体工作流不应仅仅因为运行在同一个工作节点上就共用一份庞大的策略。较小的策略更容易审核、版本化和回滚。

标准 PAC 脚本继续使用 FindProxyForURL(url, host) 完成常规的代理选择。对于获批准的 ENT Tier3 配置文件，同一个受信任的 PAC 脚本还可以定义 BotBrowserFindProxyForRequest，这是 BotBrowser 的回调，会收到请求的 URL、主机、方法、请求头和请求体状态。回调不会替代标准 PAC。当它返回 CONTINUE 或没有有效结果时，路由会回到标准函数。回调可以执行以下操作：

• 继续请求，并保留标准 PAC 路由。
• 阻止请求。
• 向获批准的绝对路径写入一条带标签的简短捕获记录。
• 仅让当前请求改走另一个标准 PAC 结果，例如 DIRECT、HTTPS 或 SOCKS5。
• 用受控的合成响应完成请求。

多个结果可以用分号组合。捕获记录最先写入。随后，受控响应会完成请求，并优先于阻止和路由；没有响应时，阻止优先于路由。格式错误、过大、不安全或不受支持的响应输入会以关闭方式失败，绝不会发送给目标站点或代理。

回调只适用于获批准的配置文件和明确指定的 PAC 来源：file: PAC 文件、data: PAC URL、回环 HTTP(S) PAC 服务，以及由你的团队控制的远程 HTTP(S) PAC 服务。PAC 自动检测和 WPAD 对标准 PAC 路由仍然有效，但不会收到回调。本地工作节点优先使用 file: 或回环来源，来源在远程时使用 HTTPS。

受控响应的来源策略比回调本身更窄。它们仅限于加载 file: 或 data: PAC 来源的获批准配置文件。HTTP(S) PAC 来源仍然可以路由、捕获和阻止请求，但不能返回受控响应。管理员应让策略与配置文件包处于相同的访问控制之下，并拒绝未经审核的分发途径。

受控响应适用于部署自己拥有的端点和固定测试资源，例如就绪状态结果、稳定的测试资产，或获授权质量保证流程中使用的确定性回复。请把自有测试资源与真实目标站点的流量分开。它们应当支持可重复的测试和运维检查，而不是取代对第三方服务的正常导航。

PAC 请求策略的适用场景

区域路由一致性

由配置文件支撑的会话可能需要与其所选地区相匹配的路由。PAC 可以让导航和辅助请求保持在获批准的路由类型上，而无需在各个自动化框架中重复路由选择逻辑。

内部与外部应用路径

企业测试可能同时涉及内部服务和公共网页依赖项。一份小型 PAC 策略可以让内部流量保持在预期的专用路径上，而外部流量使用获批准的代理路由。

多上下文工作节点

创建并关闭浏览器上下文的工作节点需要可预期的归属关系。把每个上下文的配置与其配置文件和策略配对，会让之后的审核更容易，并减少对进程级假设的依赖。按上下文代理指南介绍了如何为独立的上下文分配路由。

可重复的质量保证

自有测试资源可以消除所选测试路径中不必要的网络波动。借助获批准的本地策略来源，受控响应可以支持这一狭窄的用途，而页面的其余部分仍遵循标准的浏览器网络行为。

保护措施与基于结果的验证

为每个 URL 记录 proxy、direct 和 blocked 三种预期结果。

请把 PAC 来源、浏览器配置文件和代理清单视为同一个经过审核的发布单元。

• 限制谁可以修改策略来源。
• 在部署配置中明确保留已批准策略的引用。
• 对稳定的策略文件使用版本控制。
• 在更改代理凭据或地区之前，先审核路由归属。
• 作业配置发生变化时，启动全新的浏览器会话。
• 让受控测试资源与测试工作流处于相同的访问控制之下。
• 优先使用小范围的请求类别允许列表，而不是宽泛的兜底策略。

远程策略分发需要与其他生产配置相同的传输与访问审核。不要把标准 PAC 路由所允许的更广来源，误认为可以使用受控响应的许可。

验证应当确认部署结果，而不是收集不必要的页面数据。先从路由计划开始，记录哪些请求类别应使用各条获批准的路由，哪些应保持标准 PAC 行为。运行正常的授权工作流，并把可观察的网络结果与该计划进行比较。

请同时检查配置文件与路由是否一致。地区、语言、时区和代理出口应当描述一个连贯的环境。对于多上下文任务，请分别审核每个上下文，避免某一个上下文成功而掩盖另一个上下文的配置问题。

对于自有的受控测试资源，请通过常规的应用检查确认预期的应用行为。把生效的策略标识、配置文件分配、访问记录和浏览器结果放在一起审核。这些观察结果能说明部署是否遵循其已批准的路由计划。请把结果附到用于发布和回滚决策的同一份发布记录上。

验证证据应当简明。策略版本、配置文件类型、预期的路由类型、观察到的出口以及工作流结果，通常就足以写入发布记录。

责任归属、上线与记录

每次上线都保存 policyVersion、effectiveAt、owner 和 rollbackTarget。

路由策略会在页面自动化评估结果之前影响浏览器流量。请为每份策略指定一名明确的负责人，此人要了解该策略管辖的应用路径。负责人应当能够解释每个路由类别为何存在、哪些配置文件类型使用它，以及由哪个团队批准变更。代理运维可以保持为独立的职责，但路由选择与路由可用性之间的界限必须以书面形式确定。

请把策略当作生产配置项来审核。一份有用的审核记录包含策略名称、修订版本、受影响的部署组、分配给它的配置文件类型，以及每个获批准路由类别的预期结果。它还应当标明回滚版本和负责做出该决定的人。这些上下文足以让运维人员采取行动，而无需把策略复制到工单里，也不会暴露不属于运维记录的细节。

避免在作业之间随意共享策略。适用于某个应用的策略，可能包含对地区、专用服务或代理归属的假设，而这些假设在其他地方并不成立。用途改变时，应另建一份经过审核的策略。多出来的这份记录，比起在两个部署各自演变之后追查一条无法解释的路由，成本要低得多。

凭据不应嵌入会被复制到工单或浏览器自动化中的策略文本里。请使用部署的常规密钥管理途径，并把访问权限限制在运行获批准作业的服务账号上。在平台允许时，让凭据的轮换与路由逻辑相互独立，并在轮换之后运行与正常发布相同的授权应用检查。代理认证与凭据管理指南更详细地介绍了这一做法。

先从一个能代表生产环境的小型部署组开始。使用预期的浏览器版本、配置文件类型、操作系统、代理清单和自动化版本。在开发者笔记本上测试可以确认语法，但无法证明生产环境的路由归属、凭据和访问控制是正确的。

在同一时间段内，把分阶段的部署组与未改动的部署组进行比较。有用的观察项包括应用是否成功完成、浏览器启动与退出状态、代理可用性、路由类型的结果，以及退回队列的作业数量。请让页面集合和作业组合保持可比。如果同时更改多项输入，比较结果就无法说明策略是真的有帮助，还是恰好赶上了不同的工作负载。

请按部署组逐步扩大范围，而不是一次更改所有工作节点。当应用结果、浏览器稳定性或路由归属记录不再符合发布计划时，请暂停上线。在尝试第二项更改之前，先恢复之前经过审核的策略。这样可以让回滚可预期，并为下一次比较保留清晰的基线。

长时间运行的工作节点应通过与配置文件和浏览器更新相同的生命周期接收策略变更。按照应用的常规关闭规则完成或停止已分配的工作，然后使用新的发布单元启动全新的浏览器会话。把旧的浏览器会话与新的策略分配混在一起，会让支持记录难以解读。

即使路由记录不包含页面内容，它们也可能泄露敏感的运维信息。请把收集范围限制在支持或隐私审核所需的内容：策略修订版本、配置文件类型、获批准的路由类型、部署组、时间窗口和应用结果。不要仅仅为了证明某份策略处于生效状态，就保留完整的目标站点历史记录。

对这些记录适用组织的常规保留计划。短期的预发布记录可能只需要保留发布窗口，而受监管的生产工作流可能需要更长的审计线索。部署负责人应在上线前确定保留期限，并记录谁可以读取或导出这些记录。不要让浏览器日志变成一份无人管理的网络历史副本。回调写入的捕获记录遵循同样的规则，因此其路径、标签和保留期限应当纳入经过审核的策略。

访问审核应同时覆盖策略编辑和策略分配。无法修改策略文本的人，仍可能把现有策略挂到错误的部署组上。请一并审核这些权限。移除不再有活跃负责人的分配，并淘汰已不能用于回滚的策略修订版本。

恢复与维护

使用 lastKnownGood、errorCode 和 retryAt 区分恢复操作与新上线。

当获授权的工作流产生意外的路由结果时，请停止向受影响的部署组派发新任务。保留最近一次成功的策略修订版本和发布记录以备使用。确认所分配的配置文件类型、浏览器版本、代理清单和策略修订版本与已批准的变更一致。这第一步比较往往无需深入到页面层面的调查，就能发现配置漂移。

请通过组织常规的基础设施监控，独立检查获批准代理路由的健康状况。即使策略没有变化，路由也可能不可用。同样，代理健康并不能证明已分配了预期的策略。请把策略选择与路由可用性视为两个独立的事实，再把二者与应用结果进行比较。代理故障转移指南介绍了路由本身不可用时该怎么做。

恢复期间，请一次只更改一个发布组件。在恢复之前策略的同时又更改配置文件包、浏览器版本和代理地区，会破坏基线。请先回到最近一次经过审核的发布单元。待常规应用检查通过后，再通过分阶段上线流程引入下一项更改。

事件记录应写明用户可见的结果、受影响的部署组、最近一次已知良好的版本、纠正措施以及发布验证结果。请概述观察到的行为，而不是保留逐个请求的页面数据。这份范围更窄的记录既支持问责，也尊重浏览会话的隐私边界。

请定期审核正在使用的策略，并在应用、浏览器、配置文件或网络发生重大变化之后再次审核。确认每个路由类别仍有当前的用途和负责人。请移除不用的类别，而不是为了可能的未来工作而保留。较短的策略在发布时更容易推理，也更不容易沿用过时的假设。

确认文档链接指向当前的产品版本，并确认部署模板引用的是有效的策略修订版本。请趁回滚材料仍然有效时测试它。如果某个修订版本只存在于旧工单中，而其代理清单或配置文件分配已被撤销，它就不是可靠的恢复选项。

请让隐私和支持负责人参与维护审核。运维可以确认路由健康状况，隐私审核人员可以确认收集与保留仍然适度。支持团队可以找出反复出现的配置问题，并在部署模板中解决。这种共同审核能让策略保持实用，又不扩大其范围。

常见配置错误

• 把所有策略来源视为等同。不同能力对来源的要求不同，因此请为预期的工作流选择有文档记录且获批准的来源，并在浏览器或策略包发生变化时重新审核这一选择。
• 在多个层级之间分散路由归属。当 PAC、框架处理器和外部转发服务都在选择路由时，最终路径就难以解释，因此请为每项决策指定唯一的负责方。
• 为互不相关的配置文件复用同一份策略。为某个地区或浏览器类型创建的策略可能不适合另一个，因此当配置文件类型、代理地区或工作节点角色发生变化时，请重新审核。
• 对真实网站流量使用受控响应。它们面向自有测试资源和获授权的测试路径，普通的目标站点流量应继续使用标准的浏览器网络。

BotBrowser 支持什么，边界在哪里

BotBrowser 支持通过 --proxy-pac-url 进行标准 PAC 路由，并且对于获批准的 ENT Tier3 配置文件，支持写在同一个 PAC 脚本中的受信任请求回调，该回调可以继续、阻止、捕获、为单个请求选路，或从 file: 或 data: PAC 来源返回受控的合成响应。这让路由策略保持在浏览器的网络路径中，你的团队只需审核与每个配置文件配套的一份策略，而不必审核分散在各个自动化脚本中的路由逻辑。BotBrowser 不能让代理路由变得可用或健康，不能代表你的组织批准策略，不允许从 HTTP(S) PAC 来源返回受控响应，也不会检查目标站点归谁所有，因此把受控响应限定在自有测试资源而不用于真实的第三方流量，需要由你的团队通过策略来规定。

支持的来源、返回值和运维要求请参阅 PAC 请求回调文档，底层的代理选择请参阅代理配置指南。代理配置文章说明了这些选择如何配合。

公开来源

• MDN：代理自动配置（PAC）文件
• BotBrowser PAC-Like Request Callback 文档

Practical conclusion

在同一份审核记录中保存 PAC 来源、已批准的代理清单、配置文件和回滚版本。让工作流进入生产流量前，先验证路由结果。