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

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

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

BotBrowser 150.0.7871.46 为企业 PAC 请求策略流程增加了受控响应支持。标准 PAC 路由保持不变，额外的策略层帮助获得授权的团队维持一致的请求处理，并遵守明确的来源和配置文件要求。

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

简单会话通常只需要一个静态代理。如果同一浏览器流程需要多个获批准的路径，静态代理就不再合适。把选择逻辑放进自动化框架，也可能让 Playwright、Puppeteer、原始 CDP 和浏览器自行管理的流量产生不同结果。

PAC 为浏览器提供统一的路由策略。自动化代码负责操作页面，浏览器负责网络选择。配置文件、代理清单和路由策略的职责因此更清楚，部署也更容易审查。

这种方式也有助于隐私一致性。浏览器配置文件可以定义区域、语言、时区和设备类型。如果流量经过无关的网络路径，这些设置就会互相冲突。将路由策略与配置文件放在一起，可以减少浏览器身份与出口之间的配置偏差。

BotBrowser 150.0.7871.46 的变化

BotBrowser 150.0.7871.46 扩展了获批准的企业 PAC 流程：

• 经过认证的代理路由可以留在浏览器管理的网络路径中。
• 受控响应可以在更严格的来源策略下支持自有测试资源和可重复的质量验证流程。

标准 PAC 选择继续处理普通流量。部署无需把每个请求都移入额外策略层。新能力适合少量需要比路由选择更多控制的请求类别。

这些能力仍与获批准的企业配置文件绑定。PAC 来源属于生产配置，因为它会影响浏览器流量的方向，以及特定自有资源是否在本地提供。

清楚的运行模型

便于维护的部署会分开四项职责：

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

这样可以避免把路由规则复制到每个脚本中。支持和隐私团队也能在不阅读页面自动化代码的情况下检查路径变化。

策略名称应直白，每份策略只服务一个部署目的。区域验证、内部应用测试和媒体流程不应仅因为共用工作节点就使用同一份大型策略。小型策略更容易审查、版本管理和回退。

受控响应及策略边界

受控响应适用于部署方拥有的端点和测试资源，例如就绪状态、稳定的测试资源，或授权质量验证流程中的确定性结果。

这项能力使用比普通 PAC 路由更严格的信任策略。管理员应根据当前产品文档选择受支持的来源，让策略与配置文件接受相同的访问控制，并拒绝未经审核的策略交付方式。实际需要确认的是来源是否获准用于所选能力，而不是应用能够看到的传输标签。

自有测试资源应与真实目标流量分开。受控响应适合可重复测试和运行检查，不应用来替代对第三方服务的普通访问。

PAC 请求策略的合适场景

区域路由一致性

配置文件支持的会话可能需要与所选区域匹配的路径。PAC 可以让导航及相关请求使用获批准的路由类型，而无需在不同自动化框架中重复选择逻辑。

内部与外部应用路径

企业测试可能同时访问内部服务和公开依赖。小型 PAC 策略可以让内部流量使用指定的私有路径，让外部流量使用获批准的代理路径。

多上下文工作节点

不断创建和关闭浏览器上下文的工作节点需要清楚的配置归属。把每个上下文的配置文件和策略配在一起，便于后续审查，并减少对进程级假设的依赖。

可重复的质量验证

自有测试资源可以减少特定测试路径中的网络波动。在获批准的策略来源下，受控响应可以服务这一有限用途，其余页面仍遵循标准浏览器网络行为。

何时使用静态代理

并非每个部署都需要 PAC。当所有流量都应使用同一路径，而且不需要维护请求分类策略时，应优先使用静态代理。配置越小，运行越简单。

只有在浏览器确实需要按请求选择路径时才使用 PAC。如果自动化流程始终只有一个稳定路径，就不必为了复制现有逻辑而增加 PAC。策略应降低运行复杂度，而不是换一个文件继续保存同样的复杂度。

部署保护措施

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

• 限制可以修改策略来源的人员。
• 在部署配置中明确记录获批准的策略引用。
• 对稳定策略文件使用版本管理。
• 更改代理凭据或区域前先确认路径归属。
• 作业配置变化后启动新的浏览器会话。
• 对受控测试资源应用与测试流程相同的访问控制。
• 优先使用少量明确的请求类别，不采用宽泛的兜底策略。

远程策略分发需要与其他生产配置相同的传输和访问审查。标准 PAC 路由可以支持更多来源类型，但这不代表这些来源可以使用受控响应。

以结果为中心的验证

验证应确认部署结果，同时避免收集不必要的页面数据。

先准备路由计划，记录哪些请求类别应使用各类获批准路径，哪些应保持标准 PAC 行为。运行正常的授权流程，将可观察到的网络结果与计划比较。

配置文件与路径应一起检查。区域、语言、时区和代理出口需要描述同一个环境。多上下文作业应分别检查每个上下文，避免一个成功结果掩盖其他上下文的配置问题。

对于自有受控测试资源，应通过应用的常规检查确认预期行为。把实际策略标识、配置文件分配、访问记录和浏览器结果放在一起复核。这些结果可以说明部署是否符合获批准的路由计划。

验证记录保持简洁即可，通常只需策略版本、配置文件类型、预期路径类型、观察到的出口和流程结果。

变更归属与审核

每份策略都应有了解相关应用路径的负责人。代理运行可以由另一个团队管理，但路径选择与路径可用性之间的边界必须写清楚。审核记录应包含策略名称与修订版本、受影响的部署组、分配的配置文件类型、预期结果和回退版本。

不要在作业之间随意共享策略。适用于一个应用的配置可能依赖特定区域、内部服务或责任归属。用途变化时，应建立单独审核的策略。凭据不要写入策略正文或自动化代码，应使用部署环境已有的密钥管理方式，并只授权执行相关作业的服务账号。

分阶段上线

先选择能够代表生产环境的小型部署组，并使用计划上线的浏览器版本、配置文件、操作系统、代理清单和自动化版本。开发机器上的测试可以确认基本配置，但不能证明生产环境的访问控制与分配关系正确。

在相同时段把试运行组与未改动组进行比较，并保持页面集合与作业类型接近。记录应用是否完成、浏览器启动与退出状态、代理可用性和路径类型结果。按部署组逐步扩大范围。如果结果不再符合发布计划，应暂停上线并先恢复上一份经过审核的策略。

长时间运行的工作节点应按照配置文件与浏览器更新所使用的生命周期接收策略变化。先依照应用规则完成或停止现有工作，再用新的发布单元启动浏览器会话。不要让旧会话继续使用新的策略分配。

记录、访问与保留

路由记录即使不包含页面内容，也可能暴露敏感的运行信息。仅保留支持与隐私审核所需的策略版本、配置文件类型、获批准的路径类型、部署组、时间范围和应用结果。不要为了证明策略生效而长期保存完整目标历史。

按照组织已有的保留规则处理这些记录，并提前明确读取与导出权限。访问审核既要检查谁能修改策略，也要检查谁能把现有策略分配给部署组。移除没有当前负责人的分配，并停用已经不能用于回退的旧版本。

处理异常结果

授权流程出现异常路径结果时，先停止向受影响部署组分配新工作。把浏览器版本、配置文件、代理清单和策略版本与最后一项批准记录逐项比较。代理路径的健康状态应通过正常基础设施监控单独确认，不能把代理可用与策略分配正确视为同一件事。

恢复期间一次只改变一个发布组件。先回到最后一个经过审核的发布单元，应用常规检查通过后，再通过分阶段流程引入下一项变化。事件记录应包含可观察结果、受影响组、最后正常版本、处理动作和发布验证结果，并以用户可见行为概括问题。

定期检查所有启用的策略，并在应用、浏览器、配置文件或网络发生较大变化后重新审核。移除没有当前用途或负责人的路径类别。让运行、隐私和支持团队共同确认路径健康、记录保留范围与部署模板仍然有效。

常见配置问题

把所有策略来源视为相同

来源要求会随能力和版本变化。应为当前流程选择文档明确支持并获批准的来源，并在浏览器或策略包变化时重新审核。

在多个层级重复决定路由

如果 PAC、框架处理器和外部转发服务都在选择路径，最终结果就难以解释。应为每类决定指定一个负责方，并记录边界。

为无关配置文件复用策略

面向某一区域或浏览器类型的策略未必适合另一种配置。配置文件类型、代理区域或工作节点职责变化时，都要重新审查策略。

对真实网站流量使用受控响应

受控响应用于自有测试资源和授权测试路径。普通目标流量应继续使用标准浏览器网络行为。

常见问题

PAC 请求策略会替代标准 PAC 吗？

不会。普通代理选择仍由标准 PAC 路由处理。企业策略流程只为获批准的部署增加特定请求处理能力。

如何选择受控响应的来源？

使用当前产品文档支持且经部署负责人批准的来源。把访问控制、修订版本和配置文件分配记录在同一项变更中。

每个浏览器上下文都需要 PAC 吗？

不需要。仅在上下文需要浏览器级路径选择时使用 PAC。对于单一路径，静态代理更清楚。

不同自动化框架可以共用策略吗？

可以。策略属于浏览器网络路径，外部自动化框架不必复制路由规则。

在哪里查看具体配置？

请参阅 PAC 请求策略文档，了解支持的来源、配置和运行要求。代理配置指南 介绍基础代理选择。

当 PAC 请求策略让浏览器路由更容易解释时，它才最有价值。保持策略精简，使其与配置文件一致，并只在使用获批准来源的自有流程中使用受控响应。