多账户浏览器隔离：为每个身份设置独立配置
了解哪些信号会让账户相互关联，上下文与独立实例有何区别，以及如何检查每个身份都有自己的网络路由、指纹设置和存储。
BotBrowser Team
多账户隔离意味着为每个获授权身份分别分配路由、Profile、存储边界和复核记录。BotBrowser 可以按 Profile 和上下文隔离已批准的账户，但不能授权账户使用、绕过平台规则，也不能保证平台永远不会关联账户。
要点
使用 BrowserContext 隔离存储，并以按上下文的身份设置或独立实例覆盖其余已批准边界。每次配置或浏览器版本变更后，都应分别核对每个身份的 exitIp、locale、渲染读数和存储分区。
内容
能把一个账户与另一个账户关联起来的五类信号
有意同时运营多个账户的人，比如替客户管理页面的代理机构、需要复现地区性问题的支持团队，或是对比本地化内容的研究人员，都会遇到同一个问题：这些账户共享的东西，比账户背后的那个人还要多。网站不需要知道姓名，就能察觉两个会话有共同点，只需要几个反复出现的值。因此，隔离工作的核心是先确定哪些值必须对每个身份保持独立，再确保每个值都是有意设置的，而不是无意中从机器上继承而来。下面的建议以一个前提为基础：每个账户都属于你，或者经账户所有者许可、并在平台条款允许的范围内运营。BotBrowser 可以让每个获授权的账户保持在各自独立的配置和上下文中，但不能授予操作账户的许可，也不能替代平台的条款。
实际中有五个维度。它们按通常引发问题的先后顺序排列。
- 网络路由。 两个账户从同一个 IP 地址登录，很容易被关联。每个身份都需要自己经过批准的路由，而且路由应来自你审核过的服务商。
- 指纹信号。 Canvas 和 WebGL 的渲染输出、音频特征、屏幕尺寸以及 navigator 值都来自硬件和操作系统，所以在同一台机器上运行的所有内容里都会重复出现，除非有东西改变它们。
- Cookie 与存储。 Cookie、localStorage、IndexedDB、缓存和 service worker 都保存状态。这里的任何共享都会直接关联账户，无需任何推断。
- 地理元数据。 时区、区域设置和语言应当彼此一致，也要与路由一致。一个看起来从柏林登录、却报告纽约时区的账户，本身就前后矛盾。
- 活动时间。 总是在相同时刻从同一台机器启动、暂停和操作的账户，会形成一种任何浏览器设置都无法消除的规律。
前四项是配置问题，浏览器可以帮上忙。第五项关乎人和日程的行为方式，所以下文把它当作一种操作习惯，而不是一个设置项。
在后续讨论中请始终记住一点：隔离能降低这些维度上的可关联性，但永远降不到零。配置得当的一组身份可以消除廉价而偶然的关联，却无法阻止一位执着的分析者通过行为、共用的付款信息，或同一个人的写作方式来关联账户。以这个限度为前提做规划，比假设完美隔离更能得出好的决定。
独立性只是目标的一半，每个身份还必须自身一致。一个描述桌面设备的配置文件，加上属于另一个国家的区域设置，再加上位于第三个地区的路由，会让同一个身份显得自相矛盾，而这本身就是一种信号。设置身份时请问自己两个问题：它在每个维度上是否都不同于其他身份，它自己的设置是否描述了一台处在同一个地点的同一台设备。两个答案都必须是肯定的。
一个实例多个上下文，还是多个实例
| 布局 | 存储边界 | 身份配置边界 | 运维取舍 |
|---|---|---|---|
一个实例，多个 BrowserContext 对象 | 每个上下文一个隔离存储 | 每个上下文各有 profile、路由、locale 和 seed | 内存成本较低；逐上下文指纹需要 ENT Tier3 许可 |
| 每个身份一个实例 | 每个进程一个用户数据目录 | 每个实例一个配置文件和一条路由 | 影响范围更清晰；启动和内存成本更高 |
基于 Chromium 的浏览器按浏览器上下文来隔离存储。Playwright 把上下文描述为隔离的浏览器会话：每个上下文都有自己的 Cookie、本地存储、IndexedDB 数据、缓存和 service worker，测试可以在同一个浏览器里以很低的成本打开很多个上下文。这是标准行为，不依赖任何特殊构建。它覆盖了上面列表中的第三个维度，也是把上下文作为单个身份自然单位的原因。
标准上下文不会隔离来自硬件和操作系统的信号。渲染输出、音频特征、屏幕尺寸和 navigator 值在普通浏览器的每个上下文中都相同，因为每个上下文都运行在同一台机器上。因此，原生配置只提供存储隔离，别无其他。Firefox 容器和独立的用户数据目录也处于同一条边界：Cookie 被分开，而来自设备的信号保持不变。
在另一端还有更重的选项。独立的浏览器安装和虚拟机能提供很强的隔离，因为每一个都有自己的二进制文件、操作系统或硬件配置，但它们会成倍增加更新、监控和存储每个环境的工作量，而且每台虚拟机都要为完整的操作系统预留内存。它们适合合规规则要求各身份完全不共用主机的情形。对大多数多账户工作而言，上下文和独立的浏览器实例以更低的运维成本就能满足需求。
常见的有两种布局。第一种，一个浏览器实例容纳多个上下文，每个上下文分配给一个身份。它启动快，分摊实例成本，每个身份占用的内存更少。BotBrowser 的逐上下文指纹功能就是为这种布局设计的：每个上下文都可以带有自己的配置文件、时区、区域设置、噪声种子和代理，文档列出了大多数 BotBrowser 命令行参数支持按上下文设置。该功能需要 ENT Tier3 许可，所以在围绕它做设计之前，请先确认你的许可级别。
第二种，每个身份都有自己的浏览器实例，带有自己的配置文件和自己的用户数据目录。实例之间不共享任何东西，隔离最干净，对审计人员来说也最容易解释。代价是成本：每个实例都有自己的启动时间和内存占用，一台机器能容纳多少实例取决于硬件而不是浏览器。一次崩溃或一个卡住的页面也只会影响一个身份，这是实实在在的运维优势。
请根据风险和规模来选择。如果身份不多而且一旦混淆代价很高，独立实例最容易理解。如果需要在有限的硬件上放很多身份，一个实例搭配多个上下文更高效，前提是你接受这些上下文共用一个浏览器实例，并依靠逐上下文设置来处理其他一切。许多团队两者并用：相关身份放在同一个实例的各个上下文中，必须永远不共用基础设施的分组则使用独立实例。无论选择哪种布局，都要给每个实例各自的用户数据目录，避免配置数据互相冲突。
容量是测量出来的，而不是承诺出来的。一台机器能承载多少身份，取决于可用内存、处理器核心数以及每个上下文中页面的重量，所以请用你的真实工作负载来测试，不要照搬别人环境里的数字。浏览器上下文容量规划介绍了随着上下文数量增长如何规划并观察资源使用。逐步增加身份，观察内存和页面加载时间，在机器开始变慢时停下。
为每个身份分配独立设置
在动任何配置之前，先建立一份朴素的身份记录。为每个身份写下配置文件、路由、时区、区域设置与语言、噪声种子，以及保存其状态的数据目录或上下文。这份记录很短，却能避免最常见的失误：仅仅因为某个值已经在命令行里就重复使用它。把每一行当作一个单元，除非你已决定允许共享，否则它不与任何其他行共用同一个值。
配置文件决定基础指纹。独立的配置文件提供最强的隔离，因为每一个都描述一台不同的设备，而同一个配置文件搭配不同的噪声种子，则会在同一个基础上得到不同的输出。噪声种子控制渲染和音频输出中的细微变化。相同的种子总是产生相同的结果，所以身份在多次会话之间保持稳定，换一个种子则让另一个身份得到不同的结果。种子只选一次，与身份记录一起保存，没有理由就不要更改。噪声种子的可复现性对此有详细说明。
路由与地理元数据必须一致。当你通过 BotBrowser 的设置为某个上下文分配代理时，BotBrowser 会根据该路由的出口地址推导时区、区域设置和语言。文档还允许你自行提供出口地址，这样可以跳过查询并加快上下文创建。文档也提醒，仅通过 Playwright 内置选项设置的代理会让时区与路由不一致，所以按上下文设置路由时请使用 BotBrowser 的 --proxy-server 设置。需要覆盖推导值时，仍然可以使用显式的时区、区域设置和语言值，详见时区、区域设置与语言配置。
长期稳定是设计的一部分。一个账户从一次会话到下一次始终保持相同的配置文件、种子、路由地区和数据目录，看起来就像同一个人回到同一台设备。设置在各次会话间变化的账户则像是多台设备，在关注新设备的平台上可能触发额外验证。如果某个身份需要新的路由，比如更换了服务商，请保持地区和地理元数据不变并更新记录。只有在你有意停用该身份时，才更换配置文件或种子。
在同一个实例内，顺序很重要。逐上下文设置必须在上下文创建之后、其第一个页面打开之前应用，因为页面在启动时读取这些设置，对已经有页面的上下文应用的设置不会生效。由该上下文中的页面创建的 worker，包括专用 worker、共享 worker 和 service worker，会继承该上下文的身份，不需要额外步骤。先创建每个上下文，应用其设置，然后再打开页面。
路由细节值得单独留意。为每个身份提供各自经批准的路由，并检查你的服务商和浏览器如何处理 DNS 和 WebRTC，确保你选择的路由承载每一条连接。BotBrowser 在网络方面记录了针对这两者的控制项，按上下文设置代理说明了如何按上下文分配并验证路由。请把每条路由的凭据放在密钥管理器中，不要放在多个身份共用的脚本里。
分别检查每个身份
| 读取项 | 预期比较 | 记录字段 |
|---|---|---|
| 公网地址 | 与其他身份不同，并与获准路由一致 | exitIp |
| 浏览器 locale 和时区 | 与获准路由的地区一致 | locale 和 timeZone |
| Canvas 和 WebGL 输出 | 所选 profile 或 seed 应不同的地方应当不同 | canvasHash 和 webglRenderer |
| Cookie 和存储 | 在所属上下文以外不存在 | storagePartition |
验证就是为每个身份读取可观察的值，并与你的记录比对。每次配置变更之后，以及浏览器版本变化时，都要做一次。请使用你自己控制的测试页面或中立的公开页面，并保持检查简短。目的是确认你的设置已经落到每个上下文，而不是研究某个具体网站如何运作。在每个身份中运行相同的检查，这样结果可以逐行对比。
- 各身份的公网 IP 地址互不相同，并与各自分配的路由一致。
- 报告的时区、区域设置和语言与该路由所在地区一致。
- 使用不同配置文件或噪声种子的身份，其 Canvas 渲染输出互不相同。
- 使用不同配置文件的身份，其 WebGL 渲染器字符串互不相同。
- 在一个身份中写入的 Cookie 和存储，在其他每个身份中都不存在。
请带着正确的预期解读结果。渲染器字符串的差异来自独立的配置文件，而噪声种子主要改变渲染输出，所以使用同一个配置文件的两个身份报告相同的渲染器字符串是正常的。如果预期的差异缺失，先看记录：种子重复、共用同一个配置文件，或是设置在其第一个页面之后才应用的上下文，都是常见原因，而共用数据目录则解释了存储被共享。
让检查与身份的正常会话分开。在同一个上下文中新开一个页面打开验证页，记录数值后关闭，这样检查不会在账户的存储、历史记录或时间上留下额外状态。检查期间不要登录任何东西，也不要加载属于真实账户的页面。把记录的数值与身份记录一起保存，以便之后的变更可以与之对比。
为检查安排时间。创建身份时、配置文件、路由或种子发生任何变更后、浏览器更新后，以及对长期使用的身份按固定日程（比如每月一次）运行检查。一份简短可重复的清单，比一份没人做完的长清单更有用。当某个值发生变化而记录中没有对应条目时，把它当作一项发现：弄清是谁改了什么，并在该身份再次使用之前，修正配置或记录。
请记住通过检查意味着什么。这些读数确认设置按预期生效，并且身份在你读取的值上彼此不同。它们并不能证明某个网站无法关联两个身份，因为网站可能使用你没有读取的信号，而且关联也可能来自行为而不是浏览器的值。把干净的结果当作配置正确的证据，而不是对任何平台行为的保证。
实践结论
时间是第一个缺口。总是在同一分钟行动、一个接一个登录，或遵循完全相同日常流程的账户，会呈现出与浏览器无关的规律。请错开日程，改变会话时长，让每个账户遵循适合其用途的节奏。不要用一个脚本同步驱动多个账户。
第二个缺口是共用材料。相同的电子邮箱、电话号码、付款方式、恢复联系人或上传的文件，会在平台层面把账户连在一起。Cookie 值得特别提一下：把一个身份的 Cookie 复制到另一个身份，会连同会话及其标识符一起带过去，抵消存储隔离提供的分离。切勿在身份之间转移 Cookie、导出的会话或保存的密码。
日常卫生习惯覆盖其余缺口。关闭已完成的上下文，以便释放内存，避免状态不断累积。只为必须在多次运行之间保留状态的身份使用持久数据目录，并且每个身份一个目录。把路由凭据、配置文件和种子放在有访问控制的存储中，并指定负责人。阅读你所使用的每个平台的条款：有些平台限制一个人可运营的账户数量，任何浏览器配置都不会改变这些规则，也不会改变平台执行规则的方式。
要为失误做好计划，因为它们一定会发生。如果手动复制了 Cookie，复用了配置文件，或者用相同设置打开了两个上下文，就把涉及的两个身份都视为已混合。停止把它们用于受影响的工作，记录发生了什么，并用全新的数据目录和独立设置重建受影响的身份，而不是就地修补。重建在当下更慢，但留下的记录容易让人信任，而被修补的身份会保留所有泄漏进去的状态。
在添加新身份之前，对照这五个维度和上面的共用材料逐项检查。它是否有自己的路由、自己的配置文件和种子、自己的数据目录、自己的日程，以及自己的一套账户资料？只要有一个问题答不上来，这个新身份就还没有被隔离，即使浏览器设置是正确的。
BotBrowser 支持在一个浏览器实例中为每个 BrowserContext 分配独立的配置文件、代理、时区、区域设置和噪声种子（逐上下文指纹需要文档所述的 ENT Tier3 许可），或者运行各自带有配置文件和用户数据目录的独立实例，使每个身份呈现独立的指纹和网络设置，你无需维护整套机器也能把账户分开。BotBrowser 不能保证账户永远不会被关联：它不提供代理或 IP 信誉，不控制行为或时间上的关联、你处理 Cookie 的方式，也不控制平台的账户政策，并且不能替代对账户做合理的运营隔离。
公开来源
本文属于指南： 浏览器身份表面：一致性实用总览