Chrome 代理服务器设置：系统、PAC 和扩展程序

你已选择代理、输入连接详情，并在 Chrome 中打开了一个地区价格页面。页面仍显示你的办公地点，或者一位同事在设置看似完全相同的情况下得到了不同结果。在更换服务商或凭据之前，先检查是哪项设置在控制浏览器。

可靠的 Chrome 代理设置应从作用范围和优先级入手，最后用证据验证。选择满足任务需求的最小配置范围，确认代理地址背后的网络，并核实公网 IP 和 DNS 行为，而不是只相信设置界面显示的内容。

哪种 Chrome 代理方式适合你的任务

Chrome 提供五种实用的代理方式。正确的选择取决于你希望设置影响多大范围，以及是否需要在不同目标、配置文件或受管理设备之间更改路由。

代理是一种转发请求的中间服务器。网站通过代理收到请求时，通常看到的是代理的公网 IP 地址，而不是你的连接所使用的公网地址。

Chrome 代理方式对比

如果希望由 Windows 或 macOS 为 Chrome 提供路由设置，使用系统代理会很方便。临时测试更适合使用启动标志，因为它会在启动时明确指定预期配置。

PAC 脚本可以在无需手动切换的情况下做出条件判断。扩展程序管理器让基于配置文件的切换更加方便，而企业策略则让 IT 能够集中强制管理。

先确定作用范围，再考虑便利性

假设一位社交媒体经理在获得平台许可的情况下管理五个品牌账号。在每个配置文件中使用代理扩展程序的独立 Chrome 配置文件，更便于检查账号与路由之间的对应关系，但配置文件并不能替代账号授权。

而要通过脚本测试依赖地理位置的价格页面，数据工程师可以使用启动标志并指定单独的用户数据目录。这样测试环境就能与日常浏览分开。

实用原则：选择能完成任务的最小作用范围。系统级更改可能会影响所有遵循操作系统代理设置的其他应用。

哪种代理类型会影响你的结果

即使 Chrome 使用相同的代理设置，地区价格检查也可能返回不同结果，因为代理类型会改变目标网站看到的网络身份。选择与测试相匹配的类型，然后比较观察到的路由和会话行为，再得出结论。

ASN（自治系统编号）用于标识对某个地址块进行通告的网络。查询 ASN 有助于区分托管网络、家庭互联网服务提供商或移动运营商，但无法据此识别使用该地址的人。

代理类型及其代表的网络

了解会话情况，而不只是地址

IP 轮换会按计划或根据请求更改对外显示的地址。粘性会话会在规定时间内保持同一地址，而地理位置定向则用于选择国家或地区。对于基于登录的工作流程，请确认会话期间地址是否保持一致，因为意外轮换会让结果更难解读。

了解移动地址还需要一些背景信息。IETF 的运营商级 NAT 指南说明了服务提供商如何让多个订户共享一个公网 IPv4 地址，并通过端口映射区分各自的连接。这种称为运营商级 NAT（CGN）的机制意味着，一个观测到的地址可能代表许多互不相关的客户。因此，针对地址的封禁可能会影响不止一个订户。

要解读移动路由，应在根据观测到的 IP 得出结论之前，比较ASN、会话行为和位置背景。检查 ASN 是否表明该网络属于移动运营商、工作流程期间地址是否变化，以及显示的位置是否符合测试预期。这些检查有助于确定路由中的哪个环节影响了结果。

连接协议也必须与工具相匹配。HTTP 代理处理 Web 代理请求；SOCKS5 代理可以转发更广泛类型的连接。选择代理端点之前，请确认应用支持哪种协议。

在受控工作中，移动代理可用于遵循平台规则的账号管理、市场调研、广告验证和依赖位置的 QA。它们并非用于规避检测或绕过访问控制。单凭 IP 地址也无法确定某个人的身份、账号所有权或设备。

如何通过系统设置或启动标志设置代理

需要在设备级别更改时，使用操作系统设置。需要进行明确且隔离的浏览器测试会话时，使用启动标志。

设置操作系统代理

1. 打开相应设置。在 Windows 中，打开“设置”，选择“网络和 Internet”，然后选择“代理”，并启用“手动设置代理”。在 macOS 中，打开“系统设置”，选择“网络”，选中当前使用的连接，然后打开“详细信息”和“代理”。
2. 输入端点。在相应字段中填写代理主机和端口。除非界面明确支持其他格式，否则请将身份验证凭据与主机名分开填写。
3. 保存并测试。Chrome 默认遵循系统配置，因此无需单独设置 Chrome 选项。如果路由没有变化，请先排查扩展程序控制或受管理策略，而不是反复编辑相同字段。

不同版本的操作系统可能使用不同的菜单名称。关键在于区分手动输入的端点和自动配置脚本。

启动隔离的 Chrome 会话

1. 完全退出 Chrome。关闭所有窗口，并检查后台进程。现有浏览器进程可能会接收启动请求，而不采用新的标志。
2. 准备启动项。编辑指向 Chrome 可执行文件的快捷方式，或在 macOS 或 Linux 上使用终端。
3. 指定代理。对于 SOCKS5，添加 --proxy-server="socks5://myproxy:8080"，并替换为你的实际端点。对于 HTTP 代理，使用其 HTTP 协议方案、主机名和端口。
4. 有意设置例外。为应直接连接的目标添加 --proxy-bypass-list，例如本地开发服务或获准访问的内部域名。
5. 分离浏览器数据。添加 --user-data-dir，将其指向专用测试文件夹，然后启动 Chrome 并验证路由。

Chromium 代理文档说明，上面的 SOCKS5 示例会将 HTTP 和 HTTPS URL 请求通过代理路由到端口 8080。SOCKS5 会中继连接，但不会解读应用的网页内容；它本身并不保证加密。

DNS（将主机名转换为地址的系统）需要单独检查。网页请求经过代理，并不足以证明每次查询都在远程完成，因此不要把公网 IP 发生变化视为完整验证。

如何使用 PAC 脚本有条件地路由流量

PAC（代理自动配置）脚本适用于部分目标需要使用代理、其他目标则应直接连接的工作流程。例如，广告验证团队需要通过特定地区的店面路由访问，但希望内部报告流量仍使用办公室连接时，就可以使用 PAC 脚本。

该脚本包含一个名为 FindProxyForURL 的 JavaScript 函数。一个最简示例函数为 function FindProxyForURL(url, host) { if (host === "shop.example.com") return "PROXY proxy.example.net:8080"; return "DIRECT"; }。

此示例会将指定主机名的流量通过代理发送，并对其他目标返回 DIRECT，表示不使用代理。这些名称只是占位符，并非可用的服务配置。

部署易于检查的规则

1. 有意匹配主机名。使用 host 值匹配目标，不要假设主机名与其解析出的地址可以互换。除页面的主主机名外，也要包含必需的辅助主机。
2. 可靠地发布文件。将文件托管在测试设备可访问的内部服务器或稳定的 HTTPS 地址上。
3. 选择自动配置。在 Windows 上，使用系统代理中的“使用设置脚本”选项。在 macOS 上，选择自动代理配置选项。
4. 选择故障处理策略。使用 PROXY proxy.example.net:8080; DIRECT 这样的顺序返回值，可在代理不可用时回退到直接连接。仅当直接访问可以接受时才使用此设置；否则可能导致区域测试失效。
5. 重新加载并检查。编辑后刷新配置，然后分别测试一个明确应通过代理访问的主机和一个明确应直接访问的主机。

WPAD（Web 代理自动发现）是另一种方式，在启用自动发现后，可通过 DHCP 或 DNS 发现配置。对于需要在自动发现与指定脚本 URL 之间做出选择的团队，了解这一区别有助于审查自动代理设置。

Chrome 代理 API 文档区分了 pac_script（使用脚本或嵌入式 PAC 数据）和 fixed_servers（应用显式代理规则）。文档还定义了 system 和 direct 模式。

直接连接回退是一项可用性决策，而非中性默认设置。如果测试要求所有匹配的请求都使用区域代理，请勿添加此回退。

PAC 会针对每个 URL 做出决策。如果会话期间出现意料之外的变化，应先检查匹配规则、辅助目标和回退设置，再判断是否为网络问题。

如何使用扩展程序管理多个代理

基于扩展程序的代理管理器可让桌面版 Chrome 按配置文件更轻松地管理路由。关键在于区分扩展程序中保存的代理配置和Chrome 配置文件：后者保存浏览器的账号和浏览状态。

明确账号与路由的对应关系

1. 安装前检查扩展程序。通过 Chrome 网上应用店安装，并阅读其权限。代理控制需要 proxy 权限；对于无关权限，应仔细审查。
2. 创建命名连接配置。记录主机、端口、协议和身份验证信息。使用“客户区域 QA”之类的名称，比使用未标记的端点更有帮助。
3. 定义获准的例外。添加应直接连接的内部网站和本地地址。避免设置过于宽泛的例外，以免意外包含待测试的目标。
4. 将配置与 Chrome 配置文件对应起来。将每个账号、市场或客户分配给相应的配置文件，并在其中选择对应的连接。
5. 开始工作前检查。查看工具栏中当前启用的配置，然后在打开敏感会话前确认实际路由。

更改端点前先解决控制冲突

假设你将某个配置文件切换到新代理，但浏览器仍使用旧路由。打开 Chrome 设置，搜索“代理”，并查找指明控制扩展程序的提示。停用其他控制扩展程序，或重置受影响配置文件的路由配置。

调用 chrome.proxy 的扩展程序会提供一个 ProxyConfig 对象，其清单必须声明代理权限。在未受管理的桌面版 Chrome 上，处于启用状态的代理控制扩展程序可以覆盖操作系统配置。

每个配置文件只保留一个处于启用状态的代理控制扩展程序。即使 Chrome 能确定性地处理优先级，使用多个控制扩展程序也会让控制权归属更难厘清。

受管理设备群需要单独审查策略。对于 ChromeOS，Google 的企业代理指南列出的优先级依次为：全局用户 ProxySettings、全局扩展程序、按网络应用的用户策略、按网络应用的设备策略，以及用户配置的网络接口。

本地更改无法覆盖优先级更高的策略。IT 部门应在试点设备上检查生效策略，测试相关流量路径，并在扩大部署范围前保留回滚配置。

如何逐步测试代理路由

配置了代理并不能证明路由正常。你需要从实际执行工作的浏览器会话中获取观察结果，而不只是代理管理器显示的连接成功消息。

从受控会话中收集证据

1. 检查有效配置。在可用时，尝试访问 chrome://net-internals/#proxy。如果你的 Chrome 版本已不再显示有用的详细信息，请捕获浏览器网络日志，并结合当前启用的扩展程序或策略检查代理解析情况。
2. 检查 HTTPS 和公共 IP。打开一个获准使用且会报告请求方地址的 HTTPS 端点。记录它检测到的地址，而不要只依赖代理配置的主机名。
3. 测试例外规则。测试一个绕过代理的主机名，以及一个预期通过代理访问的主机名。记录每个主机名使用的是 DIRECT 还是代理。
4. 比较 DNS 行为。在正常路径和代理路径中使用同一个主机名。仅仅是解析结果不同，并不能证明存在泄漏；不同区域的解析器完全可能返回不同结果。检查解析发生的位置。
5. 测试身份验证。将代理身份验证与受登录保护的应用页面分开检查。反复出现的提示可能来自不同的凭据系统。
6. 测试故障处理。在受控环境中禁用主路由，并检查是否按配置触发备用路由，包括是否因此可以直接访问。

对于生产环境的 QA，请在至少 30 次冷启动浏览器会话中重复测试，记录连接时间、TLS 错误、HTTP 状态、最终公共 IP 和所选路由，并遵循 Chromium 的路由和绕过行为中所述的验证方法。

测试结果及其通常含义

将 代理检测测试作为补充证据，而不要将其作为唯一验收标准。对于移动端用户流程，可将浏览器路由检查与 99tests 的面向发布团队的真机测试指南结合起来，因为桌面代理测试无法复现完整的手机环境。

将无法解释的路由变化视为需要调查的配置缺陷。将日志与配置一并保存，以便日后将编辑内容与已知正常的基线进行比较。

验证路由并采取下一步行动

当配置的适用范围、控制代理的方法和观察到的路由都有记录时，该配置就可以重复使用。将配置、控制方式和测试结果一并记录，因为扩展程序更新或策略变更都可能改变结果。将凭据存放在获准使用的密钥存储中，并与普通测试记录分开。

在团队范围内采用该配置之前，请确认预期活动符合平台条款、授权要求、隐私义务和内部审批规则。对配置进行版本管理并注明审批状态，以便之后根据当前使用的版本审核变更。

有关移动代理的使用场景和合规性考量，请参阅前文关于代理类型的章节。只有在获准的需求确实涉及移动网络环境、会话连续性或独占性时，才选择移动路由；不要将其用作规避检测或访问控制的手段。

代理的可靠性，取决于上一次验证路由的时间。

Evoproxy 在法国提供个人和共享移动代理端口，个人套餐配备专用硬件并支持自动设置。如果你的 Chrome 工作流需要移动网络环境、会话连续性或独占性，请访问 Evoproxy，根据目标网络条件评估配置。