从 PAC 测试结果到浏览器的实际路径
把 PAC 函数返回的路径，与文件下发、浏览器采纳、代理可达性和请求的最终走向区分开来。
PAC 测试工具返回 PROXY proxy.example:8080。这是有用的结果。但在宣称浏览器配置已验证之前，还有几个问题要回答。
| 问题 | 该检查什么 |
|---|---|
| 这个脚本对这份输入返回什么？ | 求值器、输入 URL 以及辅助函数的结果 |
| 浏览器是否拿到了这份副本？ | 配置的 PAC URL 以及下发或缓存的证据 |
| 浏览器是否使用了返回的路径？ | 浏览器在代理判定与连接方面的诊断信息 |
| 那条路径能否承载请求？ | 所选端点的连接情况以及与代理的交互 |
pacparser 这类工具用它自己支持的辅助函数来求值 PAC 逻辑。它并不会运行目标浏览器完整的配置发现、策略、缓存与连接机制。
让输入保持可比。不同的 URL 方案、主机名写法、DNS 应答或给出的客户端地址都可能改变一个本来合法的结果。换一个网络测试，也可能在脚本毫无缺陷的情况下走到另一个分支。
浏览器策略也可能选择另一个 PAC URL 或固定代理。在磁盘上修改文件，并不能证明浏览器重新获取了它。在 Chrome 中，刷新 PAC 与清除记住的坏代理并不相同。请把文件的确切版本和相关使用方设置连同结果一并记录下来。
用离线求值来缩小逻辑问题的范围。用真实客户端的诊断来确认采纳与路由。如果脚本结果正确，但代理看不到任何事务，请先查清这一落差，再重写一条本来能用的规则。