PAC 在应用侧决定用哪个代理入口
PAC 是代理自动配置脚本。支持它的应用取得脚本后，调用 FindProxyForURL(url, host)，根据返回值决定直接访问，还是连接某个 HTTP 或 SOCKS 入口。
它与客户端内核的规则不是同一层。PAC 返回代理入口，只表示应用准备把请求交过去；客户端收到请求后，仍可能按自己的规则直连、选择节点或拒绝连接。
一个只按主机名判断的简单例子
下面是用于理解逻辑的 PAC 脚本，假设本机已有 HTTP 入口 127.0.0.1:2080。先替换为实际端口，再由自己的系统或应用加载；这不是客户端订阅配置。
function FindProxyForURL(url, host) {
host = host.toLowerCase();
if (host === "localhost" ||
host === "127.0.0.1" ||
host === "intranet.example.invalid") {
return "DIRECT";
}
return "PROXY 127.0.0.1:2080";
}例子仅让列出的三个主机名直接访问，其余目标交给本机 HTTP 入口。intranet.example.invalid 是保留示例名称，需要换成自己的目标；它不会自动涵盖所有内网地址或子域。
优先按主机名写条件。有些浏览器在处理 HTTPS URL 时，会移除路径和查询参数；依赖完整 URL 路径判断，可能在不同环境中产生不同结果。
DIRECT 和代理回退要看返回的顺序
| 返回字符串 | 应用侧的意图 |
|---|---|
| DIRECT | 不使用显式代理入口 |
| PROXY 127.0.0.1:2080 | 使用这个 HTTP 代理入口 |
| PROXY 127.0.0.1:2080; DIRECT | 先尝试代理，按应用的失败处理逻辑允许再尝试直连 |
第三种写法允许代理不可用时尝试直连，可能改变你预期的访问路径。是否加入 DIRECT，应按实际需要决定。应用重试、失败判断和缓存行为也可能不同，需在目标环境验证。
DIRECT 只代表应用不使用 PAC 指定的入口。如果系统路由仍有 TUN 接管，流量还可能进入客户端；不能单凭返回值证明请求绕过所有代理。
脚本地址可访问，不代表应用已经用了新版本
- 检查自动配置地址是否填写正确，应用是否启用了 PAC，而不是同时选了手动代理。
- 确认应用能取得脚本内容；错误页、登录页或空响应不能当成有效 PAC。
- 更新脚本后按应用支持的方式重新加载。已有连接或缓存可能暂时继续使用旧路径。
- 在客户端观察实际目标请求。如果 PAC 为它返回 DIRECT，客户端的显式代理入口可能根本收不到这次请求。
脚本里写 127.0.0.1 时，它指的是运行应用的这台设备。手机加载电脑提供的 PAC，却把入口写成 127.0.0.1，手机就会尝试连接自己；共享入口要改为电脑可达的局域网地址。
curl 不会直接执行 PAC 脚本
curl/libcurl 没有内置 PAC JavaScript 执行功能。把 PAC 文件 URL 填给 --proxy，不会让 curl 自动计算目标该走哪个入口。
用 curl 排查入口时，明确写 HTTP 或 SOCKS 地址。排查 PAC 本身则要在支持它的浏览器或应用里确认返回结果，再对照客户端连接记录。这两项测试分别回答脚本选择和入口是否可用。
什么时候需要 PAC，什么时候直接配入口
若只需要一个固定代理入口，应用自己的手动代理设置通常更容易核对。需要按目标让部分应用直连、部分使用指定入口，并且应用支持 PAC 时，再考虑脚本。
已经把所有请求交给客户端内核分流时，也要理解两层规则如何衔接。故障排查先问“应用有没有交给入口”，再问“内核最后选择了哪个出站”，避免只修改其中一层。
常见问题
PAC 等于 Clash 或 mihomo 的规则模式吗？
不等于。PAC 由支持它的应用执行，选择入口；mihomo 规则由内核在收到连接后执行，选择最终出站。两层可以同时存在。
开了系统自动代理，所有命令行工具都会读取吗？
不会。程序是否读取系统 PAC 要看它的支持情况。curl 没有内置 PAC 执行功能，可以使用显式入口或它支持的代理环境变量。
参考资料
原理和协议定义可查以下标准与官方文档。文中的流程图由 AFQKit 绘制。