自动代理 URL 详解：PAC 文件与 WPAD 设置

自动代理 URL 指向一个 PAC 文件，这是一种小型脚本，通常命名为 proxy.pac，用于决定每个请求是直接连接，还是通过代理连接。这种方法源自 Netscape 1996 年的浏览器设计，当时的目的是自动选择路由方式。

你可能见过这种故障情况。团队里有人把一项设置粘贴到浏览器中，检查 IP 查询页面，看到显示的是预期国家/地区，便宣布任务完成。几小时后，QA 流程却显示本地定价，广告检查返回了错误的广告素材，或者后台 API 调用暴露了你的办公室网络。设置看起来没问题，但并非所有流量都遵循了它。大多数困惑都由此而来，因为自动代理 URL其实并不是流量的地址，而是一个决策的地址。

自动代理 URL 实际指向什么

你的广告验证负责人在里昂打开一个测试浏览器，看到的广告活动正是法国移动用户应当看到的样子。一位同事用另一台笔记本运行同样的检查，却看到默认的全球页面。两人都坚称自己“用了代理”。实际上，一台设备获取了路由脚本并应用了它，而另一台设备仍使用手动设置，或者根本没有获取脚本。

这就是核心区别。普通代理设置指向一台服务器，例如主机和端口。自动代理 URL指向一个代理自动配置文件，通常称为 proxy.pac，浏览器或操作系统会下载并运行它。可以把固定代理想成一条你始终要走的路，而 PAC 文件更像导航应用，会根据目的地为每次出行重新规划路线。

为什么集中管理决策很重要

这套系统基于 Netscape 最初于 1996 年为 Netscape Navigator 2.0 设计的代理自动配置方法。PAC 文件包含一个名为 FindProxyForURL(url, host) 的 JavaScript 函数，用于决定每个请求是直接发送，还是通过一个或多个代理发送，详见Mozilla 的 PAC 文件指南。互联网工程任务组后来于 2001 年 1 月在RFC 3040中记录了 PAC。

这段历史并非无关紧要的冷知识。RFC 3040 指出，PAC 通过将代理策略集中到一个脚本中简化了管理，管理员因此可以更新脚本，而不必手动重新配置每个用户代理。它还提醒说，互操作性并不完美，因为不同浏览器对同一脚本的解释可能有所不同。

有效的自动代理 URL 能证明设备可以获取路由指令，但不能证明该设备上的每个应用都会遵循这些指令。

将这个 URL 粘贴到设置界面时，你选择的并不是一个出口服务器，而是由谁来决定每个请求的出口，以及如何在不逐一手动操作每台笔记本、手机或浏览器配置文件的情况下，快速为所有人更改这个决策。

PAC 文件如何决定每个请求的去向

跟踪一个请求的过程。浏览器要打开一个产品页面。在建立连接之前，它会将 URL 和主机交给 FindProxyForURL(url, host)。该函数会评估简单规则，并返回 DIRECT 或某个指定代理之类的指令，有时还会附带备用代理，以便第一个代理失效时浏览器可以尝试其他代理。

看一个简单的例子就容易理解了。内部工具可以返回 DIRECT，因为它们本来就在你的网络中。公开的研究目标可以返回一个具有所需地理位置的代理。返回列表中的第二个代理是备用选项，而不是同一个请求要经过的第二个跳点。

主机名缓存限制

不要以为可以根据不同路径进行路由。当前指南指出，自动代理结果会按主机名进行索引和缓存，这限制了根据 URL 路径或其他 URL 组成部分选择不同代理的能力。实际上，即使你希望结账路径与主页采用不同的路由方式，同一主机上的两个页面也通常会复用同一个路由结果。

HTTPS 会带来哪些变化

自动代理 URL 不会改变 HTTP 隧道语义。对于 HTTPS 目标，符合规范的客户端会连接到已配置的代理并发出 CONNECT destination-host:port；成功收到响应后，代理会盲目转发加密字节，而TLS 仍在客户端与目标之间端到端运行，具体规定见RFC 9110 中的 HTTP 语义。

弄清这一点可以节省排查时间：

• 400 Bad Request：CONNECT 中必须包含明确的端口；端口无效或为空时，应以此方式拒绝请求。
• 407 Proxy Authentication Required：代理需要凭据，并会返回一个 Proxy-Authenticate 挑战。
• CONNECT 成功但 TLS 失败：隧道已建立，因此应检查目标服务器的握手过程，而不是归咎于代理带宽。
• CONNECT 反复失败：首先检查身份验证、允许列表、端口或目标策略。

以 ` 开头的代理 URL 仍然可以通过 CONNECT 承载 HTTPS 流量。这并不意味着代理能够检查加密页面内容。请分别测量DNS 耗时、TCP 连接时间、CONNECT 成功率、TLS 握手延迟和持续吞吐量，否则你可能会修错层面。

托管 PAC 文件并让客户端找到它

即使脚本逻辑完美，只要设备无法获取它，脚本就毫无用处。托管工作并不起眼，却是团队能否轻松更新，还是意外造成一个毫无征兆的单点故障的关键。

将 proxy.pac 放在所有目标设备都能访问的 Web 服务器上，而且访问时不应依赖你正试图配置的那个代理。远程员工很容易遇到这个常见问题：笔记本必须使用代理才能访问 PAC 文件，却又需要 PAC 文件才能获知代理配置，于是整个流程根本无法启动。

客户端发现脚本的两种方式

显式配置是最容易理解的方式。管理员或用户直接在系统或浏览器设置中输入自动代理 URL。这样你就能明确知道设备应该获取哪个脚本，还可以在同一网络中的干净设备上测试这个 URL。

自动发现方式是WPAD，即 Web 代理自动发现的缩写。客户端通过 DNS 或 DHCP 查找 wpad.dat 的位置，然后从该位置获取配置。WPAD 可以减少受管办公网络中的手动设置，但也提高了对名称控制的要求。如果错误的主机响应了 WPAD 名称，设备就可能被指向你并未发布的路由指令。

实用规则：如果你无法完全控制设备所接入的每个网络中的 DNS 和 DHCP，请优先使用显式自动代理 URL。

更改也不会立即生效。客户端只有在重新获取文件后才会应用新版本，而这可能取决于缓存、重新连接或重启应用。不要在广告活动检查开始前几分钟修改生产规则，就假设所有用户端都已采用新行为。

简要托管检查清单

• 将文件纳入版本控制：像审查代码一样审查路由更改，因为一条错误规则就可能把本应直连的流量送到代理，或让本应经过代理的流量直连。
• 限制发布权限：任何能够替换 PAC 文件的人，都能影响浏览器流量的去向。
• 使用稳定的 URL：更改文件位置意味着要重新配置客户端，这会违背集中更新的初衷。
• 保留测试 URL：在管理网络之外使用一台干净设备打开该 URL，并确认加载了预期脚本。
• 让规则易于阅读：如果没人知道为什么几个月前要强制某个主机直连，后续排查就会更加困难。

在常见平台中设置自动代理 URL

在打开菜单之前，先做一个决定：这项路由应应用于整台设备，还是仅应用于用于特定任务的一个浏览器配置文件？检查地区内容的社交媒体管理员可能需要隔离的配置文件。测试完整用户流程的 QA 设备通常需要系统级行为，但要注意，并非所有应用都会遵循这一设置。

不同版本的菜单标签可能有所变化，因此请查阅平台当前的官方文档，而不要依赖记忆中的点击路径。即使具体措辞有所变化，下面这些概念仍然适用。

桌面设备和浏览器

在 Windows 和 macOS 上，查找系统网络或代理设置，看看其中是否提供自动配置脚本或自动代理配置选项。启用该选项，粘贴自动代理 URL，保存，然后彻底重启正在测试的浏览器。有些浏览器会沿用操作系统设置，另一些则允许单独选择，因此请确认由哪一层控制。

如果你是在浏览器层面进行设置，请先查看更改 Chrome 代理设置的步骤，不要想当然地认为浏览器和操作系统的设置一致。某个配置文件中的过时手动代理可能会覆盖新脚本。这种不一致可以解释为什么有些反馈中，不同人提供的截图和结果对不上。

在团队范围内推广时，请在操作手册中记录以下三项：

• 适用范围：系统级、单个浏览器，还是单个受管理的配置文件。
• 预期出口：任务所需的国家、网络类型和会话行为。
• 回滚方式：如何停用脚本，并在 PAC 主机故障时恢复为 DIRECT。

移动设备

在移动设备上，如果有相应选项，请为特定 Wi-Fi 网络配置代理，选择自动设置，然后输入 PAC URL。当前的实现指南指出，iOS 可以接收系统级 PAC 处理，而 Android 上的 OkHttp 等自定义客户端可能需要显式解析 PAC 并执行 JavaScript。这份移动端企业代理集成指南解释了两者的区别。

这会影响你的验证方式。在手机浏览器中检查成功，并不能证明你的应用、嵌入式 WebView 或分析 SDK 使用了相同的路由。

在每个平台上执行简短的验证流程。打开已知的测试页面，通过可信的检查页面确认路由后的 IP，然后在第二台设备上重复完全相同的工作流。请在用户实际会使用的网络上测试，而不要只在编写脚本的人员身旁、连接办公室 Wi-Fi 时测试。

代理类型、粘性会话和移动 IP

PAC 文件负责选择路由，但路由的特性取决于终点的代理。首先要了解三个术语。IP 轮换是指按时间或按需更改出口地址。粘性会话会在设定的时间段内保持同一地址，确保登录或结账流程保持一致。ASN（自治系统编号）用于标识发布某个地址块的网络运营商；地理定位则用于选择国家或地区。

目标网站通常最容易识别数据中心地址并将其判定为非家庭流量，因为这些地址的 ASN 属于托管网络。住宅地址看起来更像普通家庭连接。移动地址来自运营商网络，而共享地址会影响屏蔽判断。

为什么运营商级 NAT 很重要

运营商级 NAT（CGNAT）允许运营商通过较小的公共 IPv4 地址池，为大量用户设备转换地址。RFC 6598 为服务提供商 CGN 设备使用的共享地址空间预留了 100.64.0.0/10 网段，其中包含1,048,576 个地址。根据RFC 6598 关于共享地址空间的规定，该网段不具备全球路由能力。

由于许多真实用户可能共享同一个公共移动 IP，目标网站如果严厉屏蔽该地址，就可能影响许多互不相关的人。这就是移动 IP 更难被识别为单一行为者、也更不适合直接屏蔽的原因。因此，单靠 IP 并不能准确识别身份。

设计会话时，请阅读会话持久性如何保持代理地址稳定，并判断哪些场景需要保持一致。对于合法的账户管理、多步骤 QA，以及出口地址在流程中途改变就会出错的广告流程，请使用粘性行为。对于大范围、无状态的公开信息调研，则使用轮换。无论采用哪种方式，都要记录时间戳、目标网站、响应状态和会话上下文，因为共享的运营商出口地址与用户并非一一对应。

HTTP 代理可处理 Web 请求和 CONNECT 隧道，而 SOCKS5 是一种更通用的代理协议，能够承载更广泛的 TCP 流量。PAC 返回值、客户端支持情况和任务需求都必须与这一选择相匹配。

投入生产使用前的测试覆盖范围和安全性

IP 检查页面显示绿色结果，是你能做的最弱测试。它只能证明某一时刻的一次浏览器请求使用了预期出口，却无法说明重定向、上传、后台请求是否正常，也无法证明所选代理明天仍然可信。

PAC 是浏览器或操作系统的路由机制。自定义移动应用和 HTTP 客户端可能不会自动执行 PAC 逻辑。浏览器测试可能使用了预期代理，但嵌入式 WebView、SDK、后台请求或 API 客户端却可能直接连接。对于地理位置相关的 QA，这个盲点可能让整个测试结果失效。

请围绕实际工作流设计检查，并采用结构化的代理测试环境设置，而不是临时抽查：

• DNS 解析：确认查询不会泄露非预期位置，也不会在代理路径启用时失败。
• 重定向和 HTTPS：跟踪完整的重定向链，并验证所有目标主机的 CONNECT 均成功。
• WebSocket 和上传：测试长连接和文件上传，而不只是浏览页面。
• 后台请求：触发分析、API 和 SDK 请求，并检查它们从哪里出网。
• 故障切换行为：在脚本的测试副本中停用第一个代理，确认客户端会使用预期备用代理，或明确报告失败。

为什么需要仔细审查代理来源

自动化并不会让一个端点变得安全。在一项对超过 107,000 个公开列出的开放代理进行的研究中，约有 92% 无法使用或不允许代理流量；这一数据来自针对公开列出的开放代理进行的大规模测量。同一系列经核实的研究结果还显示，五个国家占可用开放代理的近 60%，而 41% 的代理仅托管在 10 个自治系统中。

这些研究结果中的另一项为期九个月的分析发现了超过 436,000 个代理，其中有 104,000 个可响应；在可响应的代理中，7.17% 会修改网页内容，而在这些会修改内容的代理中，76.42% 会执行恶意操作。你不必记住这些数字，但一定要记住其中的教训。

不要通过未经健康检查且未实施访问控制的自动选取端点，来路由生产环境中的调研、品牌保护或账户操作流量。

在投入生产使用前，请持续检查可用性，在 PAC 文件中保留备用逻辑，在已知测试页面上监控内容完整性，并在设置支持的情况下要求身份验证。记录每项任务由哪个代理处理、处理时间以及返回的状态。结果看起来不对时，这些记录有助于你区分路由故障和端点异常。

为团队选择合适的设置

根据工作流程选择，而不是沿用习惯。对于内部系统和公开检查（测试时需要使用真实位置），直接连接就足够了。手动设置代理适合一个人完成短期、稳定的任务；但当十个人都需要遵循相同规则，而这些规则每周都会变化时，这种方式就会变得脆弱。

当不同目标地址需要采用不同路由时，基于 PAC 的设置就值得承担其复杂性。例如，内部工具可以直接连接，公开价格监控可以使用目标市场的住宅出口，而备用代理可以应对服务中断。更新一次脚本即可更改策略，无需逐台检查每个工作站。

当目标网站上的体验取决于运营商网络时，移动 4G 源就很有意义。广告验证专家可能需要以移动用户的视角查看广告活动。QA 团队可能需要通过法国运营商出口来测试本地化注册流程。负责管理合法客户账号的社交媒体经理，可能需要位置稳定的粘性会话，避免任务进行到一半时切换网络。品牌保护和 SEO 监控团队可能也需要相同的地理定位能力，同时避免将每次检查都绑定到一个办公室连接上。

在做出选择前，请对照以下标准：

• 所需覆盖范围：仅浏览器、整个设备，还是使用自带 HTTP 客户端的应用。
• 会话行为：无状态研究使用轮换会话；多步骤合法工作流程使用粘性会话。
• 网络身份：数据中心速度、住宅网络环境，还是通过移动 IP 实现运营商出口。
• 运维控制：身份验证访问、健康检查、备用规则和易于使用的日志。
• 合规边界：平台规则、适用法律、客户授权以及有据可查的业务目的。

在此模式下，Evoproxy 是一家总部位于法国南部的移动代理提供商，可接入超过 1,500,000 个移动 IP 地址。其个人套餐运行在专用移动硬件上，每月流量为 250 GB，轮换间隔为一到五分钟；共享端口则提供 50 GB 流量，并支持定时轮换，适合短期测试。

不要只根据代理池规模来购买。通过设置运行一个真实工作流程，应用上述覆盖范围和安全检查，并确认每个组件都遵循了预期路由。保持 PAC 规则清晰易读，记录会话配置，并确保所有使用行为都符合平台规则和适用法律。这样，Auto Proxy URL 才能成为可靠的路由策略，而不是几个月前有人粘贴到设置中的一串神秘字符。

如果你的下一次测试需要真正的运营商出口，而不是仅限浏览器的模拟方案，可以使用来自 Evoproxy 的移动 4G 设置，针对一个真实的广告验证、QA 或市场研究工作流程进行测试。配置所需的会话行为，确认覆盖范围不止于可见的 IP 检查，并且只有在自己的日志证实端到端路由正常后才扩大规模。