代理 PAC 故障转移测试：验证路由、备用顺序与 DIRECT 安全
代理自动配置文件是可执行的路由策略。FindProxyForURL(url, host) 可以让请求走主代理、尝试备用代理，或允许直连。语法通过并不能证明路由正确、切换仍符合政策，也不能证明所有浏览器会采用相同行为。
本指南用于在获准网络和代理服务中执行受控验收。重点是可观察的路由决策、故障边界和安全上线；不建议在不可信网络使用 WPAD，也不应为必须走代理的流量加入静默直连回退。
先把 PAC 转成决策表
每个分支都要变成测试行，不能只看注释或条件顺序。至少覆盖内部短主机名、内部域、公共 HTTPS、获准绕过目标、未知或异常主机，并为每行记录预期指令和是否允许 DIRECT。
HTTP 与 HTTPS 都要测试。现代浏览器可能只把 HTTPS 的协议和主机交给 PAC，而不包含路径和查询。因此，不应按密钥、租户 ID 或 URL 路径做路由决策。
先进行离线求值
在受限测试工具中运行 PAC 函数，固定时间并模拟 DNS 辅助函数。记录用例 ID、协议、主机类别、解析结果、期望指令、实际指令、求值耗时、异常类别和策略版本。
必须精确比较顺序。主代理; 备用代理 与相反顺序不是同一策略。遇到意外 DIRECT、空结果、不支持的协议或运行异常时应失败。
不得把代理凭据写入 PAC。文件可能被下载、缓存和查看，认证应由客户端或获准的秘密分发机制处理。
建立受控路由信标
测试目标必须自有或明确获准。响应只返回安全证据：目标标记、代理路由别名、观察到的地区与地址族、响应摘要、语义完成标记和必要时间戳。不得记录凭据、Cookie 或完整私人请求。
主、备和直连路径使用相同内容，低并发执行，避免把应用差异误判为路由差异。
先验证正常路由
逐行访问受控目标并确认真实网络路径。页面正确并不足够，因为它可能绕过了代理。分别记录 PAC 获取、求值、DNS、代理连接、CONNECT、TLS、首字节与完成时间。
旁路规则还要测试相似域名、欺骗性后缀和用户信息文本，避免边界匹配过宽。SOCKS 场景可参考 SOCKS5 远程 DNS 指南，不要把 PAC 的 DNS 辅助函数等同于 socks5h。
有意制造主备切换
至少测试四种状态：主备均正常、主代理拒绝 TCP、主代理接收连接但在有效响应前停顿、主代理正常而目标端点失败。
通常只有前几类代理连接故障应触发路由切换；目标已经通过正常代理到达后发生应用故障，不应无界遍历代理列表。测量客户端何时尝试备用代理，结合代理超时预算指南设置 DNS、连接、TLS 和应用阶段上限。
将 DIRECT 视为安全决策
如果返回序列最后包含 DIRECT，就意味着前序代理失败后流量可能不经代理离开。这可能违反地区、审计、访问控制或数据处理要求，不能为了表面可用性随意添加。
把策略分成两类：受监管、认证或地区敏感工作负载应失败关闭；只有明确批准的低风险目标才能失败开放，并且直连例外必须有监控和到期日。为直连路径设置独立信标，意外选择时立即告警。
测试 DNS 辅助函数
isResolvable()、isInNet() 等函数可能在求值时执行 DNS。分别测试成功、失败、缓慢和分视图解析，并记录是否阻塞、是否缓存以及使用哪个解析视图。
廉价的主机名规则应放在昂贵 DNS 检查之前。一个每次导航都增加数秒的 PAC，即使逻辑正确也不能上线。
IPv6 需要独立用例，包括 IPv6-only、双栈、支持时的字面地址和网络切换后的地址族变化。可结合 curl Happy Eyeballs 代理测试。
验证缓存、更新与回滚
PAC 文件和自动发现结果可能被缓存。每个测试版本应带内部策略版本，并记录客户端实际执行的版本。测试新配置与热配置、浏览器和系统重启、同 URL 内容变化、PAC URL 变化、PAC 服务暂时不可用以及回滚。
上传成功不等于全体客户端已经生效。混合版本可能让相同请求在数小时内走不同路径。
比较真实客户端
在每个受支持浏览器及使用系统代理设置的非浏览器运行时上执行同一矩阵。浏览器 PAC、WinHTTP、命令行工具和自动化框架的发现、缓存和故障转移行为可能不同；某些 WinHTTP 应用还需要自行遍历返回的代理列表。
记录客户端、精确版本、系统、管理策略、PAC 来源与结果，不能用一个客户端推断另一个。浏览器自动化应先用少量可观察灰度，再根据浏览器代理并发计划扩展。
故障分类
建议使用：PAC_FETCH、PAC_PARSE、PAC_DECISION、DNS_HELPER、PRIMARY_CONNECT、STANDBY_NOT_TRIED、DIRECT_UNEXPECTED、CACHE_STALE、CLIENT_VARIANCE 和 DESTINATION。
若证据指向求值或缓存，应隔离策略版本而不是整个代理池。只有重复的路由专属故障才使用代理池隔离与恢复指南。
验收门槛
- 所有决策行返回完全一致且顺序正确的指令；
- PAC 和日志中没有秘密或凭据；
- 主、备和获准直连路径均可独立观察；
- 切换在业务超时预算内完成；
- 目标错误不会触发无界路由循环；
- 失败关闭类别不含 DIRECT；
- DNS 正确性与延迟达标；
- 热缓存下更新和回滚都通过；
- 所有受支持客户端满足同一业务规则；
- 灰度监控能识别实际策略版本。
检查清单
- [ ] 每个分支都有正向、反向和边界用例。
- [ ] 精确断言代理指令顺序。
- [ ] 主代理与备用代理可独立制造故障。
- [ ] DIRECT 有明确审批、监控和到期日。
- [ ] HTTPS 规则不依赖路径或查询。
- [ ] PAC 与日志没有凭据或令牌。
- [ ] 已测试缓慢、失败和分视图 DNS。
- [ ] 包含 IPv4、IPv6 和双栈。
- [ ] 已验证冷缓存和热缓存。
- [ ] 大规模上线前已验证回滚。
- [ ] 每个受支持客户端均有证据。
- [ ] 只使用自有或获准目标。
常见问题
列出两个代理是否保证自动故障转移？
不保证。客户端对列表和不同故障的处理可能不同，必须测试实际浏览器或运行时。
每个 PAC 结果是否都应以 DIRECT 结尾？
不应。DIRECT 可能绕过地区与安全控制，只适合明确批准的失败开放流量。
PAC 能按 HTTPS 路径路由吗？
不应这样设计。浏览器通常会在 HTTPS PAC 求值前移除路径和查询。
公共网络上的 WPAD 安全吗？
自动发现会扩大信任边界。条件允许时应使用明确管理的 PAC URL 和受保护的配置分发。
合规说明
只在自有或获准网络部署和测试 PAC/WPAD。把 PAC 视为可执行策略，保护其分发、最小化日志，不能用路由规则绕过访问控制或地区限制，并定期复核所有 DIRECT 例外。
