如果 Chrome 无法使用以 file:// URL 形式提供的 PAC 脚本,请先检查这条投递路径,再改写脚本。某个位置加载失败,并不能说明不支持 PAC 路由。

Chrome 的代理 API 有 pac_script 模式,脚本 URL 或内联数据可通过受支持的扩展接口提供。通过操作系统设置提供的本地文件,只是投递脚本的一种具体方式。

沿着脚本一路追到浏览器

先确定是什么在控制受影响的浏览器:系统设置、受管策略、命令行配置还是某个扩展。macOS 设置里显示的值,并不能证明 Chrome 已获取并求值了那个脚本。

把被拒绝或无法访问的脚本位置与求值错误区分开,再把这两者与“无法连接有效脚本返回的代理”区分开。只有浏览器选定了那条路由之后,SOCKS 端口才会变得相关。

通过目标客户端支持的受认可机制分发受管 PAC。HTTP 或 HTTPS 投递 URL 必须在其描述的代理不可用时仍然可达。使用扩展提供的内联数据时,修改原始文件并不会自动更新已复制的脚本。启动时需要小型本地策略,可以把脚本嵌入 data URL,作为另一条投递路径。

内部 PAC 可能包含私有主机名和路由规则。应把它留在受认可的投递服务上,而不是为了绕开本地文件问题就搬到任意公共托管上。

相关文章