浏览器走机场、其他软件却直连？检查 PAC 自动代理规则

同一台电脑上，浏览器走机场代理，另一个软件却直连，原因可能不是客户端失效，而是系统使用了 PAC 自动代理脚本。PAC 会对每个 URL 执行规则，决定返回代理、直连或备用路径；不同应用对 PAC 的支持也不完全相同。

PAC 实际决定什么

PAC 的核心是 FindProxyForURL(url, host)。Mozilla 的文档说明，该函数根据请求 URL 和主机名，返回 PROXY、SOCKS 或 DIRECT 等结果。规则可以按域名、通配符、IP 网段和协议分流。

这意味着“系统代理已开启”不等于所有请求都经过同一个端口。脚本可能让内网域名直连、外网走代理，或者在主代理失败时尝试备用代理。某些非浏览器应用只支持固定代理，不读取 PAC，于是出现浏览器正常、应用直连的差异。

在系统代理设置里记录 PAC 地址，不要把地址或脚本中的令牌公开。确认脚本能正常下载、更新时间合理，并查看返回规则是否包含当前目标域名。不要从陌生网站复制 PAC；脚本能影响大量请求的路径。

如果客户端提供“设置系统代理”和“规则模式”，还要确认退出客户端后 PAC 地址是否被清除。残留地址指向已经停止的本地服务，会让浏览器持续报连接失败。

第一组使用浏览器访问测试域名，记录最终出口。第二组临时切换到固定 HTTP 代理端口，保持其他条件不变。第三组关闭系统代理并确认直连。每组只测试公开的小页面，不登录账号或提交表单。

若 PAC 组与固定代理组出口不同，检查 DIRECT、域名匹配和备用代理顺序。若浏览器读取 PAC、命令行不读取，就在命令行显式指定合适代理，不要默认它会继承浏览器设置。

域名判断应使用主机名，而不是假设 HTTPS 的完整路径始终可见；不同浏览器可能会对传入 PAC 的 HTTPS URL 去掉路径和查询部分。依赖路径做 HTTPS 分流的规则可能失效。DNS 类函数还会增加解析依赖，故障时应检查脚本究竟在本地解析了什么。

验收时确认：目标域名命中预期分支；备用顺序明确；客户端退出后系统设置恢复；浏览器和需要代理的应用分别验证。完成这些检查后，才适合把问题归因于机场节点。