multi-account-isolation

配置隔离——验证，而非假设

看起来已隔离的配置，通常并没有真正隔离。出问题的原因既乏味又机械：时区与出口 IP 不匹配，WebRTC 候选项携带真实地址，Canvas 哈希每次读取都会变化，两个配置最终使用了相同的身份。这份检查清单旨在趁问题尚未造成影响时将其找出。

仅限授权用途。 本技能适用于你拥有或获准操作的身份：你自己的账户、测试夹具、QA 设备群和反欺诈系统。不得用于未经授权访问系统、访问不属于你的账户，或创建虚假账户、虚假互动。请遵守你自动化操作的网站条款及适用法律——参见可接受用途。

本说明不作此类保证。 通过以下所有检查，意味着浏览器层内部一致。但这并不意味着某个网站会将两个配置视为毫无关联：完全在浏览器之外的因素——共享支付工具、共享联系方式、相同的活动模式——并非任何浏览器设置所能影响。请将良好结果理解为“技术层没有问题”，而非保证。

有关用于创建和启动这些配置的 SDK，请参阅 anti-detect-browser 技能。

配置不变量

一个身份对应一套独有配置。两个身份之间任何共享项都是需要排查的问题：

identity  →  profile  →  persona  →  proxy  →  timezone
   1      :     1     :     1     :    1    :     1

每个 antibrow 方案都提供无限量免费配置，因此没有理由重复使用配置。在同一个配置中“注销，再以另一个身份登录”，会破坏整个设置——Cookie 存储区和 localStorage 正是关键所在。

被测设置

import { AntiDetectBrowser } from 'anti-detect-browser'

const ab = new AntiDetectBrowser({ key: process.env.ANTI_DETECT_BROWSER_KEY })

const identities = [
  { profile: 'fixture-us-01', proxy: process.env.PROXY_US_1, tags: ['Windows 10', 'Chrome'] },
  { profile: 'fixture-us-02', proxy: process.env.PROXY_US_2, tags: ['Apple Mac', 'Safari'] },
  { profile: 'fixture-de-01', proxy: process.env.PROXY_DE_1, tags: ['Windows 10', 'Edge'] },
]

for (const id of identities) {
  const { browser, page } = await ab.launch({
    profile: id.profile,              // isolated cookies, storage, login state
    proxy: id.proxy,                  // from the environment, one per identity
    fingerprint: { tags: id.tags },   // drawn once, frozen, replayed after
    label: id.profile,                // address-bar tag drawn by the kernel, unreadable from the page
  })
  // ... run the checks below, then ...
  await browser.close()
}

Python 使用相同的磁盘配置格式：

import os
from antibrow import launch

with launch(
    profile="fixture-us-01",
    proxy=os.environ["PROXY_US_1"],   # from the environment, never a literal
    geoip=True,            # timezone + WebRTC follow the proxy exit
    label="fixture-us-01",
) as browser:
    page = browser.new_page()
    print(browser.timezone, browser.public_ip)

检查项

通过每个配置文件自己的代理运行检查，并通过断言验证，而不是凭肉眼判断。

#	检查项	方法	失败情形
1	时区与出口 IP 匹配	对比 browser.timezone 与 browser.public_ip 所属国家/地区	禁用了 geoip，或强制设置的 timezone 与 IP 矛盾。这是最常见的问题。
2	WebRTC 仅暴露代理	browserleaks.com/webrtc	ICE 候选项仍包含本地地址或真实公网地址
3	Canvas 哈希在多次启动间保持稳定	读取哈希，关闭浏览器，重新启动同一配置文件，再次读取	两次读取结果不同——每次读取都会变化本身就是异常，也意味着该身份信息未被冻结
4	Worker 与主线程结果一致	CreepJS	在 Web Worker 中重新读取时，UA、languages、hardwareConcurrency、时区或 GPU 信息不一致
5	三种接口报告同一 GPU	使用 CreepJS，或直接读取 WebGL / WebGL2 / WebGPU	adapter.info.vendor 与未屏蔽的 WebGL 渲染器所属系列不匹配
6	没有两个配置文件共用同一身份信息	比较整个配置文件集中的 browser.persona	两个配置文件报告了相同的 UA、屏幕尺寸和种子
7	没有两个配置文件共用同一地址	收集整个配置文件集中的 browser.public_ip	两个身份使用了同一出口地址，或同一个 /24 网段
8	Cookie 储存区相互隔离	比较整个配置文件集中的 browser.profile_dir，然后检查各自目录中的 user-data/	两个身份指向同一个目录，或某个目录中存有属于另一身份的状态
9	一个身份对应一棵配置文件目录树	确认每次启动同一个名称时都使用相同的 temporary 值	托管的 gmail 和临时的 gmail 是两个不同的配置文件，拥有两套身份信息和两个 Cookie 储存区。脚本对 temporary 的设置前后不一致，就会让同一个名称对应两个身份，表现为未登录状态，而不是程序错误
10	整个技术栈保持一致	whoer.net、pixelscan.net	IP、时区和地区设置一眼就能看出不一致
11	在 CI 中执行一致性规则	npx liarjs（liarjs.dev）	约 40 条跨层开源规则中有任何一条未通过——这是唯一一项可无人值守运行的检查

值得接入 CI 的是第 1、3 和 7 项：它们成本低、结果确定，而且能发现实际反复出现的问题。

排查失败

按以下顺序逐项排查，先从成本最低的开始——指纹几乎从来都不是实际原因：

1. 是否重复使用了配置文件名称？ 使用 list_profiles，或按身份比较 browser.profile_dir。两个身份共用一个目录，就能解释其他所有问题。目录按配置文件的 id 命名，而不是按名称命名，因此应检查其中的 profile.json 进行匹配，而不是根据文件夹名称判断。
2. 是否重复使用了同一地址？ 确认每个 public_ip 都不相同。
3. 系统时钟与地址是否不一致？ 同时输出 browser.timezone 和 browser.public_ip。
4. 身份信息是否重新生成？ 如果 Canvas 哈希在两次启动之间发生变化，说明配置文件未被冻结——检查 profile_dir 或缓存目录是否发生了变化。
5. 只有到这一步，才检查指纹本身；应使用上述检测套件验证，而不是想当然。

运行时会接触哪些内容，以及如何检查

任何驱动已登录会话的工具都会接收 Cookie 和代理凭据，因此询问它如何处理这些信息是合理的。对于 antibrow：

项目	存放位置	谁能看到
Cookie、localStorage、登录状态	你磁盘上的 ~/.anti-detect-browser/profiles/<id>/user-data/，或临时配置文件使用的 profiles-temp/<id>/	本地。云同步需按配置文件选择启用：启动操作本身不会创建云端配置文件，只有设置 sync: true 才会将其存入云端。请先检查哪些配置文件启用了同步，再假设它们只保留在本机
Persona（persona.json）	同一配置文件目录中，仅写入一次，之后固定不变	本地
配置文件身份记录（profile.json）	同一配置文件目录中；其中保存的 ID 用作目录名称	本地。这就是重命名不会导致 Persona 丢失的原因，也是文件夹名称并非配置文件名称的原因
代理 URL 及其凭据	启动时传递给内核；在网络栈中响应（HTTP 407 / SOCKS5 RFC 1929），因此没有扩展会持有这些信息	内核进程和你的代理提供商
API 密钥	你的环境中，或 ~/.antibrow/license.key	与 antibrow.com 交换短期许可证令牌，大约每天一次

内核是闭源的 Chromium 构建版本——这是将欺骗逻辑放在 C++ 而不是可注入脚本中的代价——因此请验证其行为，不要盲目信任：

python -m antibrow info          # kernels, profiles, license state, cache dir

browser.plan.redacted_args()     # exact kernel command line, secrets masked - safe to paste in a bug report

将它指向一个你能查看日志的代理，或本地 MITM 代理，并观察启动期间有哪些数据离开本机。固定 SDK 版本并检查已发布的哈希（npm view [email protected] dist.integrity），确保你审计的代码就是实际运行的代码。如果部署必须完全禁止回连，则这不是合适的工具：许可证验证已编译进内核，而且没有离线模式。

隔离无法涵盖的内容

值得明确说明这一点，因为一份干净的检查清单容易让人得出错误结论：

• 浏览器之外的一切。 共用的支付工具、联系信息、收款目的地——任何浏览器设置都无法影响这些，而它们是最强的关联因素。
• 活动模式。 相同的时间安排、相同的内容、相同的交互目标。这并非技术属性。
• 身份验证。 文件验证不是指纹问题。
• 平台自身的决定。 本文所述内容不会改变网站决定如何对待某个账户。

如果所有检查都通过，但仍有问题，则原因在此列表中，而非浏览器层。

可接受的使用方式

预期用途： 验证你拥有的身份之间是否隔离；在账户持有人授权的情况下管理客户账户；构建模拟不同设备的 QA 测试数据；测试你自己的反欺诈和关联逻辑；审计浏览器运行时如何处理你的凭据。

不在适用范围内，且不受支持： 未经授权访问任何系统；登录不属于你的账户；撞库或账户接管；创建虚假账户、评论或互动；绕过身份验证、支付或授权控制；违反适用法律抓取个人数据；规避平台的执行决定。

遵守所使用平台的条款及适用法律，是运营者的责任。如需举报滥用行为或安全问题，请通过 https://antibrow.com 联系我们。

相关技能

• anti-detect-browser - 用于创建此处所验证设置的 SDK、配置文件、Persona、代理和 REST API
• browser-mcp-agent - MCP 服务模式，可让 AI Agent 自行驱动单个配置文件