PAC 自动代理不生效？脚本地址、DIRECT 与浏览器规则排查

PAC 自动代理不生效时，要按三个阶段排查：浏览器能否获取脚本、脚本为目标网址返回什么、返回的代理是否能连接。PAC 文件能下载，只说明第一阶段可能正常；也不能把某个网站直连直接判定为节点故障。

作者：小仓。资料核对日期：2026-10-08。本文讨论浏览器的代理自动配置，具体设置入口与执行行为以当前浏览器和组织策略为准。示例用于解释规则，不是完整的日常代理配置，也没有对机场或节点进行实测。

PAC 地址和代理地址有什么区别？

PAC 是一段代理选择脚本。浏览器调用 FindProxyForURL(url, host)，根据返回值决定直接访问还是使用代理；基本语法见 MDN 的 PAC 文档。填写前先区分以下对象：

对象	用途	常见误填
PAC 文件地址	获取包含脚本的文件	把代理入口当作文件地址
本地代理地址和端口	接收浏览器转交的请求	把远端节点端口直接填进来
订阅地址	供客户端导入配置	把订阅内容当作 PAC 脚本

地址里出现 .pac 后缀也不能证明响应内容正确。网站可能返回登录页、错误页或重定向后的普通网页，仍然需要查看实际响应。

第一步：确认浏览器实际采用哪份设置

先记录当前浏览器配置来源：系统设置、扩展、浏览器自己的启动设置，还是组织管理策略。不同来源可能相互影响，不能只看系统里已经填了 PAC 就认定浏览器采用了它。Chromium 官方说明列出了直连、手动代理、PAC 与自动发现等配置方式，参见 Chromium 代理文档。

在自己有权调整的设备上，核对实际生效的代理来源；受管理的设备应由管理员确认策略。先保存原来的脚本地址和模式，不要同时修改扩展、系统代理和客户端规则，否则下一次请求成功也难以判断是哪项变化起作用。

还要确认测试的是同一个浏览器、同一个配置文件。一个浏览器正常，另一个失败，只能作为配置差异的线索。手机 App、终端工具和 TUN 流量是否使用 PAC，要分别核对其支持方式，不能用浏览器测试代替。

第二步：检查脚本获取和内容

从发生问题的设备访问 PAC 地址，检查响应是否成功、是否发生跳转，以及最终内容是不是预期的脚本。公开托管文件若突然要求登录，浏览器的自动获取可能与手动登录后的访问不同。不要把带有私有令牌的地址上传到公共检测网站。

检查脚本是否包含函数定义、括号和有效返回值；服务器应提供适当的 PAC 内容类型。文件内容不能是套在 HTML 页里的代码块。这些文件格式要求可在前面的 MDN 文档中核对。

如果 PAC 文件由本机代理客户端提供，文件服务端口和代理入口端口可能不同。先确认客户端运行，再分别核对文件服务和代理入口，避免看到一个本地端口正常就推断另一个也正常。改过文件后需要确认浏览器实际加载了新内容；具体刷新方式与缓存行为依浏览器而定，不宜套用统一等待时间。

第三步：为一个固定目标检查返回值

下面是用于理解匹配过程的最小示例：

function FindProxyForURL(url, host) {
  if (host === "example.com") {
    return "PROXY 127.0.0.1:7890";
  }
  return "DIRECT";
}

这段示例只让指定主机使用示例代理，其余请求直接连接，不能复制后当作全站代理方案。应替换为自己的测试目标与实际端口，并在可信脚本中检查对应条件是否会命中。不要执行来源不明的脚本来验证地址。

先用一个明确的主机名判断规则，再扩展到子域名。example.com 与它的某个子域名并不满足相同的精确比较条件。依赖 HTTPS 完整路径的规则也需要格外核对：浏览器可能向 PAC 提供去掉路径的 URL，相关差异见 MDN 文档。不要据此更改浏览器安全设置，优先考虑主机层面的判断是否足够表达需求。

DIRECT 回退为什么容易误判？

DIRECT 表示直接连接。如果返回列表里写了 PROXY 地址:端口; DIRECT，规则允许在前面的代理不可用时尝试直连；列表与回退机制见 MDN 文档及 Chromium 官方说明。实际选择还受浏览器行为和策略影响，不能只凭脚本文本认定某次请求经过了哪条路径。

因此，“网站打开了”不能独立证明代理工作正常。测试时应结合目标主机、返回规则和客户端连接记录。反过来，删除某条 DIRECT 也不能保证整台设备所有流量都经过代理：其他程序可能根本不使用这份 PAC。

若规则使用 DNS 查询函数，还应把域名解析纳入排查。解析参与匹配，并不自动说明发生了隐私泄露，也不代表 DNS 一定被加密。可结合本站 DNS 与 Fake-IP 排障 分别确认解析方式和代理路径。

用两次受控请求验证修改

固定浏览器、测试主机与网络，先记录原规则下的结果，再只修改一项条件进行对照。尽量创建新的请求，已有连接可能继续承载后续访问。日志中没有对应记录时，要先检查日志是否开启、时间是否对齐，不能立即把它解释为直连。

如果规则已返回正确代理，浏览器仍失败，下一步转向代理入口的监听地址、协议和认证；继续改 PAC 匹配条件通常不能修复连接层问题。如果脚本获取失败，则先恢复文件可访问性，不必先轮换节点。

可以填写的检查记录

记录浏览器与版本、实际配置来源、PAC 获取时间和响应、目标主机、预期返回值、实际请求时间、代理日志以及本次唯一修改。测试结束后恢复不需要保留的设置，并确认浏览器采用了预期模式。这样下次排障能按获取、选择、连接三个阶段继续定位。

PAC 和规则模式、TUN 是同一种东西吗？

PAC 解决支持它的程序如何选择代理；客户端规则和 TUN 还涉及各自的流量处理范围。它们可能共同参与一次访问，但不能互相替代验证。模式范围可参考 规则、全局与 TUN 的区别，再针对实际使用的程序检查配置。