浏览器自动化中的代理绕过与 PAC 规则审计指南
浏览器显示“已配置代理”，并不代表所有流量都会经过代理。PAC 规则、操作系统例外、NO_PROXY、扩展程序、Service Worker、WebSocket 客户端以及独立网络库，都可能让部分请求直连。页面能打开，只能证明页面打开了，不能证明购买的代理覆盖了所有关键请求。
本指南面向获得授权的数据采集、市场研究、本地化 QA 与广告验证团队，提供一套可复现的代理绕过验收方法。
先定义路由承诺
测试前写清楚哪些请求必须走代理，哪些允许直连，并注明浏览器版本、自动化运行时、协议、目标域组、会话模式和 IP 地址族。把结果分为三类：
- 已代理：请求使用预期代理出口；
- 批准直连：例如已记录的本地健康检查；
- 意外直连：任何其他绕过代理的请求。
不要把“浏览器使用代理”作为验收条件。这个说法无法覆盖 DNS、子资源、后台请求和 WebSocket。
建立受控观察点
使用自有或获授权的测试端点，记录来源地址、请求时间、协议、主机名和随机运行编号。编号中不要放凭据、Cookie 或客户数据。如代理网关提供日志，再用同一编号关联浏览器、网关与端点证据。
每次运行至少保留以下字段：
| 字段 | 用途 |
|---|---|
| 运行与请求编号 | 关联三处证据 |
| 目标主机 | 找到规则特定的绕过 |
| 资源类型 | 区分文档、图片、脚本、API 与 WebSocket |
| 观察到的来源 IP | 区分代理出口与客户端网络 |
| 请求的会话模式 | 发现静默切换 |
| IPv4 或 IPv6 | 暴露双栈差异 |
| 时间戳 | 分析轮换与配置变更 |
测试端点应返回最小响应并设置保守限速。它是测量工具，不是制造流量的工具。
设计路由矩阵
不要只测试顶层页面。矩阵应包含：
- HTTPS 文档与同源子资源；
- 在自有域名上的跨域图片、脚本和 API；
- 业务使用时的 WebSocket；
- 新 DNS 名称与已解析名称；
- 同时涉及两种地址族时的 IPv4 与 IPv6 主机；
- 预期直连的 localhost 或私有端点；
- 能明确命中每条 PAC 或绕过规则的主机名。
先在全新浏览器配置中运行，再在热缓存配置中重复。两者对比可以发现 Service Worker、缓存与持久连接造成的差异。
逐层检查绕过来源
代理例外可能来自多个层级。要记录运行时的最终生效值，而不是只看配置文件。
PAC 决策
按实际评估顺序列出规则，并测试精确主机、子域名、大小写、尾随点、不同端口以及业务使用的国际化域名。谨慎处理宽泛的后缀匹配：为一个内部服务设置的例外，可能误伤无关域名。
环境与操作系统
检查代理环境变量、操作系统网络设置和自动化启动参数。继承的 NO_PROXY 或平台默认值，可能覆盖正确的浏览器设置。
浏览器与扩展
扩展程序可能在启动后修改代理设置；Service Worker 能发起后台请求；预连接和预取也可能出现在可见页面流程之外。应使用生产环境相同的扩展集合进行测试。
外部网络库
下载器、媒体组件、原生消息助手或独立 HTTP 客户端不一定使用浏览器网络栈。只要工作流会调用它们，就应作为独立客户端测试。
在不泄露客户端地址的前提下证明路由
使用两个独立受控端点：一个预期收到代理流量，另一个作为明确的直连金丝雀。把观察到的来源与已知代理出口及经过脱敏的客户端网络指纹比较。报告只保留“是否匹配”，不要长期保存操作者的精确住宅地址。
如果生产并不需要直连金丝雀，就把它留在隔离测试环境内。不要为了证明故障，让真实客户站点意外收到直连请求。
分开测试轮换与粘性会话
轮换会话应创建新的、有记录的会话键，并确认一次逻辑事务中的所有资源遵循预期策略。粘性会话则应在承诺时长内重复矩阵，记录出口变化与路由类别变化。
新的代理 IP 不等于绕过，应分别分类：
- 出口改变，但流量仍经过代理；
- 流量从代理切换为直连；
- 只有某种协议绕过；
- IPv6 直连，而 IPv4 经过代理；
- 首次失败后的重试改变了路由。
可以结合住宅代理会话粘性测试与代理重试预算指南复核。
计算能支持采购决策的指标
报告必须给出分母，并按浏览器版本、路由规则、目标域组、协议和地址族分段：
- 代理覆盖率：已代理请求数除以必须代理的请求数；
- 意外直连率：未批准直连请求数除以全部观察请求数；
- 事务完整率：所有必需请求都走预期路径的事务占比；
- PAC 决策准确率：得到预期直连或代理结果的规则用例占比；
- 路由稳定率：没有无法解释的路由类别变化的会话占比；
- 证据完整率：能跨浏览器、网关和端点关联的请求占比。
对于涉及隐私或地域准确性的任务，即使总体比例很低，一次意外直连也可能成为上线阻断项。
设置上线门槛
一个实用的门槛可以要求：
- 必须代理的矩阵中意外直连为零；
- 每条批准直连都有负责人和理由；
- 生产主机模式的 PAC 决策 100% 正确；
- 除非明确设计，不允许 IPv4 与 IPv6 走不同路由；
- 全新与热缓存配置表现一致；
- 证据不包含秘密与个人载荷；
- PAC 或浏览器变更后的回滚流程已验证。
使用通过、条件通过、失败、证据不足四种结论。条件通过必须限定浏览器版本、市场、协议和禁用功能；证据不足应补齐测量，而不是扩大无效流量。
排错顺序
发现直连请求时：
- 确认主机名、协议、资源类型和地址族；
- 用全新配置与单个请求复现；
- 评估该精确主机名的 PAC 结果；
- 检查环境、系统和浏览器例外；
- 确认是否由扩展或外部助手发起；
- 对齐客户端、网关与端点时间戳；
- 缩小到具体规则，再重跑完整矩阵；
- 记录修复方式与回归用例。
在理解合法的本地和内部流量前，不要急于添加“一律走代理”的宽泛规则，否则可能破坏健康检查和私有服务。
采购检查清单
- 定义必须代理与批准直连的范围。
- 覆盖文档、子资源、API 与 WebSocket。
- 同时测试全新与热缓存配置。
- 显式命中每条 PAC 与绕过模式。
- 分开统计 IPv4 与 IPv6。
- 发现会静默改变路由的重试。
- 用脱敏编号关联三处证据。
- 对重大直连风险设置零容忍门槛。
- 浏览器、扩展、PAC 或操作系统更新后重测。
- 测试日志不保存凭据、Cookie 和个人数据。
常见问题
查看浏览器公网 IP，能否证明全部请求都走代理？
不能。它只证明这一次查询显示了该地址，子资源、WebSocket、DNS 行为或外部助手仍可能走不同路径。
localhost 是否总应直连？
经常如此，但并非绝对。应记录预期并测试所有名称与地址形式，避免宽泛例外覆盖生产域名。
PAC 文件会制造间歇性故障吗？
会。依赖 DNS 的规则、缓存决策、回退指令和不同主机名形式都可能造成不一致，应使用确定性用例并记录最终决策。
连接失败是否算绕过？
可用性与路由应分开统计。失败本身不能证明绕过，但失败后的重试若改为直连，就必须计为意外路由变化。
合规说明
仅在自有或获授权的系统与目标上执行路由审计，遵守供应商合同、目标条款、隐私要求与速率限制。不得利用代理规避访问控制、隐藏滥用行为、伪装身份或制造流量。只保留工程和采购决策所需的最少脱敏证据。
