PAC文件本质上是一段JavaScript，客户端对每个URL调用FindProxyForURL(url, host)，返回PROXY、SOCKS或DIRECT等结果。故障排查需分成两步：客户端是否成功获取并加载PAC，以及脚本对这个URL实际返回了什么。
PAC返回值的基本含义
| 返回项 | 含义 | 注意事项 |
|---|---|---|
| PROXY host:port | 使用HTTP代理 | HTTPS目标通常通过CONNECT |
| HTTPS host:port | 到代理本身使用TLS，依客户端支持 | 不能假定所有客户端支持 |
| SOCKS/SOCKS5 | 使用SOCKS代理 | 版本、认证与DNS行为需实测 |
| DIRECT | 直接连接目标 | 会绕过PAC列出的代理 |
第一步验证PAC是否被下载
检查自动配置URL、HTTP状态、Content-Type、证书和客户端日志。PAC服务器自身必须在尚未配置代理时可达，否则产生启动依赖循环。建议通过HTTPS和受控内网分发，并限制谁能修改文件。
为什么修改后仍使用旧规则
浏览器、操作系统和应用可能缓存PAC文件或单个主机的代理决策。缓存刷新方式因平台和版本不同。排查时使用新测试域名、重启相应网络进程或按管理机制刷新，但不要把清空全部系统缓存作为第一步。
脚本语法正确为何逻辑仍错
域名后缀匹配、大小写、点号、IPv6字面量和本地主机判断都可能出错。先构造一组固定输入，在独立PAC测试工具或客户端日志中验证返回值。复杂条件应拆成命名清晰的规则，避免几十个嵌套判断。
DNS函数为何拖慢浏览器
dnsResolve、isInNet等函数可能触发同步DNS解析，规则过多或DNS不稳定会阻塞请求。能用Host字符串判断时，不要无必要解析；内网/公网分流也应考虑Split DNS和IPv6。
DIRECT为何会造成IP旁路
脚本对目标返回DIRECT后，请求使用本地网络出口。规则写得过宽，外部API可能绕过企业审计；规则过窄，内部服务又被送到外部代理。每次变更应同时测试应代理与应直连清单。
代理故障回退顺序有什么风险
PAC可返回多个候选，例如先PROXY再DIRECT。这样提高可用性，却可能在代理故障时无声直连，违反出口要求。高安全业务应明确是否允许DIRECT回退；不允许时使用多个受控代理而不是最终DIRECT。
WPAD为什么需要谨慎
WPAD通过DHCP或DNS自动发现PAC。设备连接不可信网络时，恶意基础设施可能试图提供代理脚本。企业应明确WPAD信任域、DNS后缀和设备策略；不需要自动发现时应关闭，避免落入非受控PAC。
PAC能否控制命令行与非HTTP协议
不能普遍控制。浏览器和部分系统组件支持PAC，而curl、Git、Java应用或自定义客户端可能读取环境变量或自身配置。FTP、数据库、MQTT等非HTTP协议更不会因为PAC而自动转发。
日志和隐私怎样处理
PAC服务器日志可记录设备获取文件的时间、版本和状态，不必记录完整浏览URL。代理日志也应对查询参数和用户身份脱敏。脚本文件中不要包含账号密码、Token和内部秘密。
变更验证流程
- 为PAC文件建立版本号和回滚；
- 验证HTTPS分发与证书；
- 用固定URL矩阵测试脚本返回值；
- 分别验证PROXY、SOCKS与DIRECT目标；
- 测试代理故障时的回退行为；
- 检查缓存刷新与多浏览器差异；
- 审查WPAD和脚本修改权限。
延伸阅读
系统代理与应用独立设置的关系，可参考Windows系统、WinHTTP与应用代理区别。
结论
PAC排查要先证明确实加载了脚本，再检查每个URL的返回结果。缓存、DNS函数、DIRECT回退和WPAD信任是最容易被忽略的安全与稳定性边界。
