面向隐私保护的网络层浏览器一致性

浏览器隐私常被当作 JavaScript 问题来讨论，但这只覆盖了真实会话的一部分。在任何脚本运行之前，浏览器已经建立连接、发送请求头，并沿着某条路由到达目的地。网站既能观察这条路由的结果，也能观察页面运行环境的结果；只验证其中一个的团队，无法判断两者是否一致。BotBrowser 可以在受控上下文中让所选配置、代理路由和地理设置彼此保持一致，但不能改变目标服务器或网络如何处理连接。

网络层一致性是指：浏览器在页面内呈现的身份，与它在网络上的传输方式，描述的是同一套配置。所选配置文件、代理路由以及地理相关设置（时区、区域设置和语言）应当指向同一个自洽的配置。两者不一致时，问题通常出在团队自己身上：为某个地区准备的配置文件从另一个地区的出口出去，或者语言列表跟随宿主机器而不是跟随路由。

需要反复运行同一批工作流的团队，需要一个防御性的高层模型：哪些层必须一致，如何在更新前后验证这种一致，以及案例进入支持流程后如何判断由谁负责。这里有意不涉及低层网络数值。可重复的运营实践比任何一次孤立观察更重要，而且无论具体数值如何，这种实践都同样适用。

要点

• 让配置文件身份、网络路由、出口位置和页面报告的区域设置保持一致。
• 浏览器、配置文件、代理或宿主机发生变化后，同时验证页面信号和路由证据。
• 把支持案例分派给发生变化的层；BotBrowser 无法控制代理质量或目的地策略。

目录

• 页面运行环境与网络路由为何必须一致
• 一次会话暴露的各个层
• 地理位置、语言和时间跟随出口地址
• 可重复的验证工作流
• 按责任方划分支持案例
• BotBrowser 的适用范围与边界
• 实践结论

页面运行环境与网络路由为何必须一致

浏览器身份在页面的第一行 JavaScript 执行之前就已经到达网站。首个请求、随之发送的请求头以及它所走的路由，都是第一印象的一部分。之后，页面运行环境会补充更多信息：语言偏好、时区、与区域相关的格式化以及能力报告。同时检查这两半的审阅者可以提出一个简单的问题：它们描述的是同一个环境吗？

可直接比较的页面字段包括 Intl.DateTimeFormat().resolvedOptions().timeZone、navigator.language 和 navigator.languages；它们应与本次运行记录的出口地区相符，而不是宿主机的默认值。

各层之间的分歧很少来自某一个戏剧性的错误，而是由不同位置做出的普通决定逐步累积而成。基础设施团队轮换了代理凭据，浏览器团队刷新了配置文件，维护自动化脚本的人修改了区域默认值。每一项改动单独看都合理。合在一起，却可能得到这样的会话：网络出口在一个国家，而页面报告的语言列表和时区来自另一个国家。因此，一致性是整套配置的属性，而不是某个单独设置的属性。

生产流量还会带来单次手动测试永远覆盖不到的条件：

• 会话经过团队无法控制其行为的认证代理。
• 配置文件运行在与其所描述平台不同的宿主操作系统上。
• 工作流包含重定向、嵌入式媒体、账号页面和很长的导航链。
• 同一个浏览器实例中的多个 context 可能带有不同的身份和路由设置。
• 浏览器和配置文件的更新可能改变普通截图看不到的行为。

这些条件中的每一个，都是各层可能逐渐偏离的位置。一套覆盖真实导航路径、并按计划重复执行的验证实践，可以在偏离还只是配置问题时发现它，而不是等它变成生产事故。

设想一个定期检查区域商店的团队。它的配置文件描述的是桌面平台；由于提供商重新平衡了地址池，路由现在从邻国出口；而自动化脚本仍在传入从旧项目复制来的固定语言列表。所有页面都能加载，所以简单的冒烟测试通过。然而时区跟随新的出口，语言列表跟随脚本，结账页面显示的却是第三个市场的内容。只有逐层比较才能解释结果为何变化，只有保存下来的早期运行才能说明它何时发生变化。相关场景可参阅电商价格监控的指纹保护。

一次会话暴露的各个层

明确命名这些层，有助于团队成员在讨论案例时使用同一套词汇：

• 配置文件身份：所选配置文件描述的浏览器身份，包括平台和能力报告。
• 路由：承载连接的代理路径或直连路径，以及与之相关的凭据和 DNS 行为。
• 出口位置：目的地看到的地址，以及该地址对应的国家、地区和网络运营方。
• 区域行为：页面可以读取的时区、区域设置和语言偏好。
• 发布状态：采集证据时所使用的浏览器构建和配置文件版本。

MDN 关于代理服务器和隧道的概述为路由层提供了词汇。正向代理位于浏览器与目的地之间，反向代理位于目的地之前，HTTP 隧道则通过 CONNECT 方法让连接穿过中间节点。代理还可能添加转发请求头，代理自动配置脚本可以为每个请求选择路由。弄清其中哪一种在起作用，审阅者就能知道路径上的每一段由哪一方控制。DNS 处理和实时连接同样遵循路由，DNS 泄漏防护和 WebRTC 泄漏防护文档介绍了相关设置。关于同一问题中地址族的部分，请参阅浏览器工作流中的 IPv4 与 IPv6 代理一致性。

示意图概括了这个思路。配置文件、路由和出口位置共同决定页面报告的区域行为，发布记录则把证据与同一个构建关联起来。团队自己的检查清单中缺少的任何一条箭头，都对应一个可能藏着不一致的位置。

地理位置、语言和时间跟随出口地址

地理设置是路由与页面最明显的交汇处。页面可以读取浏览器的时区、区域设置和有序的语言列表。如果这些值描述的地区与出口地址不符，会话中就存在团队自己制造的矛盾。最简单的避免方法，是从路由推导这些值，而不是在路由旁边手动维护它们。

BotBrowser 文档描述了这种推导。启动时可用 --proxy-server 指定代理，并用 --proxy-ip 声明已知出口 IP；后者可跳过 GeoIP 查询。Per-context proxy 也受支持，每个带路由的 context 可使用自己的代理和出口声明。代理与地理位置与 Per-Context Proxy 列出相应配置方式。不要把框架传入的代理选项与 BotBrowser 的地理推导能力混为一谈；验证时应记录实际生效的路由层及其出口。

每项设置都独立解析。显式指定的时区、区域设置或语言列表，对它所定义的设置优先生效，而保持 auto 的设置则继续跟随路由。因此团队可以为了某项报表要求固定区域设置，同时让时区和语言继续跟随出口。固定某个值的决定应当写入验证记录，因为路由变化后，已固定的值不再匹配，是日后常见的困惑来源。

时机和取值同样重要。地理推导发生在 context 被激活时，所以如果工作流在路由和出口地址确定之前就创建页面，可能从不完整的信息开始。声明已知的出口 IP 可以省去激活时的一次外部查询，让启动更可预测，这在验证运行会创建大量短生命周期 context 时很有帮助。出口 IP 事先未知时，验证记录应当说明该值是推导得到的，并且运行应当等 context 完成代理和地理更新之后再导航。

Per-context 路由把同样的思路扩展到同一个浏览器实例中的多个身份。根据 BotBrowser 文档，每个带有自己代理的浏览器 context 都有自己的连接和自己的地理推导，该功能对应 ENT Tier3 许可。没有自己路由的 context 继承启动路由及其地理身份。Per-Context Proxy 指南建议在创建 context 时提供代理和任何 --proxy-ip 声明，并在打开依赖页面或导航之前，等待代理和地理更新完成。

地理推导有明确的局限。根据 GeoIP 数据库文档，国家级映射通常比较可靠，城市级映射可能只是近似，坐标也是近似值，达不到 GPS 级精度。工作流依赖城市级精度的团队，应当为这些设置指定显式值并加以验证，而不是假定地址查询是精确的。出口地址的质量和注册数据来自代理提供商和地址注册机构，任何浏览器设置都无法改变它们。

可重复的验证工作流

验证工作流应当小到可以在每次发布前运行，同时具体到两个人能得出相同的结论。下面的步骤保持在高层，不依赖任何低层网络数值：

1. 选择与生产环境一致的配置文件、路由和工作流。使用相同的代理类型、相同的宿主操作系统系列，以及真实会话所经过的相同页面序列。
2. 记录发布状态：浏览器构建、配置文件版本，以及被固定而非推导得到的设置。
3. 运行一次工作流并采集页面行为：页面是否加载、登录和媒体是否可用，以及页面报告了哪些时区、区域设置和语言。
4. 采集路由行为：哪条路由承载了流量、它对应哪个出口位置，以及 DNS 和实时功能是否走了预期路径。
5. 比较整体信号的一致性。页面报告的地理位置和语言应当与出口位置一致，配置文件身份应当与已记录的宿主平台选择一致。
6. 每次浏览器或配置文件更新之后，以及更换代理提供商之后，重复同一次运行，并把两次运行放在一起保存。

记录表至少应有 browser_build、profile_version、proxy_route、observed_exit_ip、timeZone、language、languages 和 workflow_result 列。预期是 workflow_result 为 pass，页面的时区与语言/区域设置符合该出口位置的预定配置；若某值被显式固定，应标记为 pinned，不能误记为自动推导。

价值在于比较，而不在于任何一次运行。仅有一个输入不同（例如浏览器构建）的两次运行，能告诉团队是哪项变化造成了差异。多个输入同时变化的运行，则几乎说明不了什么。因此，路由、配置文件和工作流的矩阵应当缓慢增长，每个条目都应指定一位负责人，由其判断条目何时过期。关于浏览器发布验证的文章更详细地介绍了这一实践中与发布相关的部分。

请提前确定哪些变化会触发重新运行。新的浏览器构建、配置文件刷新、代理提供商或路由池的变化、新的宿主操作系统镜像，以及修改区域或语言选项的自动化脚本，都属于这一类。目标网站的变化不在清单之内，因为团队无法控制它们；它们归入外部条件类别，在原本通过的工作流开始失败时才会被发现。把触发清单写下来，可以避免验证沦为只有出了问题才会执行的例行仪式。

证据应当与发布包或支持案例一起保存，以便后来的读者重复这次比较。有用的材料包括：

• 一份简短说明，写明配置文件、路由标签、工作流和被固定的设置。
• 每个 context 中页面报告的时区、区域设置和语言值。
• 每条路由观察到的出口位置，以及查询的日期和来源。
• 工作流每一步的功能结果，记为通过、失败或有变化。
• 前后两次运行所对应的浏览器构建和配置文件版本。

这项工作只需要合成账号和测试目的地。只采集比较所需的内容，审阅期结束后删除临时采集物。一份简短、有日期、有负责人的验证记录，比没人阅读的庞大归档更有用。

按责任方划分支持案例

会话出现意外行为时，第一个有用的问题是原因归谁负责。分别查看路由和页面运行环境，不需要冗长的调查就能回答这个问题，因为每一层都有不同的负责方和不同的下一步：

• 配置文件设置：所选配置文件、被固定的设置或 per-context 参数没有描述预期的配置。由浏览器团队修正配置并重新运行工作流。
• 路由对齐：实际使用的路由不是预期的路由，或者出口位置在配置文件准备好之后发生了变化。由管理路由的团队纠正分配。
• 浏览器运行时行为：配置和路由都正确，但页面报告的内容与其他层相矛盾。这类案例应连同证据包一起提交给浏览器厂商。
• 外部页面条件：目的地修改了流程，第三方脚本出错，或者源站对该会话应用了自己的策略。这些原因不在团队的浏览器配置范围之内，应当如此标注。

代理质量和出口 IP 的位置需要单独说明。提供商的行为、地址信誉，以及源站如何对待某个地址，都不由浏览器控制。如果案例的结论是“路由正常、配置自洽，但源站仍然拒绝该会话”，应当附上证据，作为外部条件上报，而不是重新作为浏览器缺陷打开。路由凭据的处理是一个相关话题，见浏览器代理认证与凭据管理规范。

如果对每个案例的第一次回复都索取同一小组信息，分诊会更快：配置文件和发布状态、路由标签、页面报告的地理信息，以及观察到的出口位置。带着这些信息到达的案例通常一步就能分派，没有带齐的案例应当退回补充，而不是盲目调查。

案例模板可固定为 profile_version、browser_build、proxy_route、observed_exit_ip、timeZone、language、languages 与 workflow_result。例如，若代理记录的出口与预期地区不符而页面字段仍是已固定值，应交给路由负责人核对分配；若路由与出口正确但页面字段偏离预期，则附上这些字段和运行记录交由浏览器团队排查。

一个简短的例子可以说明这个模式。某个支持案例报告说，工作流显示了错误地区的内容。配置中固定的时区仍然与预期地区一致，但观察到的出口位置却不一致。因此配置文件设置是正确的，页面运行环境遵循该配置，发生变化的是路由这一层。案例连同两次运行的记录一起转给管理路由的团队，浏览器团队无需改动任何内容。

BotBrowser 的适用范围与边界

BotBrowser 支持为每个浏览器 context 提供各自的代理路由（由团队事先批准的路由），并根据该 context 的出口 IP 推导其时区、区域设置和语言，因此团队可以在更新前后重复同一套配置文件加路由的工作流，并检查网络身份与页面运行环境身份是否保持一致。当多个身份共用一个浏览器实例，或者按计划验证发布版本时，这一点最有帮助。BotBrowser 无法提升代理提供商的质量，无法选择或控制出口 IP 的信誉，无法保证任何网站接受某个会话，也无法替代团队自己的发布验证和证据审阅。

一致性减少的是团队自己造成的不一致。它并不决定源站如何对待会话，因为是否接受取决于各个源站及其自身策略。请把自洽的结果视为诊断的干净基线，并在修改路由或地理设置之前，重新核对 per-context 代理和代理配置文档，以及 MDN 的最新指南。

公开来源

• MDN: Proxy servers and tunneling
• BotBrowser 文档：Per-Context Proxy

实践结论

在工作流运行前，把配置文件、路由、出口位置和页面报告的区域设置放在同一份记录中比较。每次相关更新后重复比较，并将不一致交给发生变化的层的负责人。把 BotBrowser 的一致性控制视为浏览器 context 的证据，而不是代理质量或目的地接受会话的保证。