CloakBrowser Manager 使用教程：从部署到多账号自动化

同一台机器上的两个测试账号，不应因为共用浏览器目录而混用 Cookie、代理或页面状态。Profile 管理器把这些设置放到可辨认的身份中，再由自动化程序连接相应浏览器。

本文用 CloakBrowser Manager 创建两个测试 Profile，人工完成各自登录，再用 Playwright 连接读取账号标识。重点是账号与任务的对应关系，不讨论检测分数或隐身承诺。

部署前确认两类配置

Manager 的界面源码与所需浏览器引擎有不同许可。引擎需要 license key，账号可用容量也影响能否同时启动两个 Profile。按当前账户授权执行，必要时顺序启动，不把开源界面理解成无限制引擎服务。说明见 官方项目。

本文使用 Docker。先建立持久卷并配置管理认证：

docker volume create cloakprofiles
export MANAGER_TOKEN='replace-with-your-manager-token'
docker run --name profile-manager   -p 127.0.0.1:8080:8080   -v cloakprofiles:/data   -e AUTH_TOKEN="$MANAGER_TOKEN"   cloakhq/cloakbrowser-manager

打开 http://localhost:8080，用同一个管理 token 登录。在 Settings 中填写自己的引擎 license key，选择需要的发布通道并保存，等待浏览器引擎准备完成。

管理 token 控制谁能进入 UI/API；license key 控制引擎授权，它们不能互换。首次下载失败应先检查网络与引擎状态，不把它当成目标站账号失效。

创建两个有清楚用途的 Profile

在界面创建 account-a-test 和 account-b-test。各自记录名称、Profile ID、用途、网络设置与数据位置。

先用无代理或团队明确要求的固定代理建立基线。代理地址若包含认证，应按界面字段填写，不直接把凭据放进 Profile 名称。账号要求固定出口时，不在每次启动自动换一个无关节点。

依次启动 Profile，在其原生窗口或 Docker 提供的远程浏览器界面中登录自有测试系统。A 登录测试账号 A，B 登录账号 B，并分别确认页面上的账号标识。它们可以访问同一测试站，但不能指向同一个可写浏览器目录。

通过每个 Profile 的 CDP 地址读取结果

运行中的 Profile 页面提供 CDP 地址，其形状包含该 Profile ID。不要把 A 的地址复制给 B 后仅修改脚本中的显示名称。

准备 Node.js 24 与 Playwright 客户端：

mkdir profile-check
cd profile-check
npm init -y
npm install playwright

这里连接 Manager 已启动的浏览器，不需要额外启动本地 Chromium。设置所需配置：

export MANAGER_URL='http://localhost:8080'
export PROFILE_IDS='replace-with-profile-a-id,replace-with-profile-b-id'
export DASHBOARD_URL='https://example.16yun.cn/account'
export ACCOUNT_SELECTOR='[data-testid="account-name"]'

后台 URL 与选择器是占位示例，替换成你自己的测试系统。该页面需要有能识别当前账号的只读元素；例如 <span data-testid="account-name">account-a</span>。没有通用软件能凭空知道每个后台的账号字段在哪里。

创建 check_profiles.mts：

import { writeFile } from 'node:fs/promises';
import { chromium } from 'playwright';
 
const base = process.env.MANAGER_URL;
const token = process.env.MANAGER_TOKEN;
const dashboard = process.env.DASHBOARD_URL;
const selector = process.env.ACCOUNT_SELECTOR;
const ids = process.env.PROFILE_IDS?.split(',').filter(Boolean);
if (!base || !token || !dashboard || !selector || !ids?.length) {
    throw new Error('缺少 Manager、Profile 或后台配置');
}
const results: unknown[] = [];
for (const id of ids) {
    const endpoint = new URL(
        '/api/profiles/' + encodeURIComponent(id) + '/cdp', base,
    ).href;
    const browser = await chromium.connectOverCDP(endpoint, {
        headers: { Authorization: 'Bearer ' + token },
    });
    try {
        const context = browser.contexts()[0];
        if (!context) throw new Error('Profile 没有可用上下文');
        const page = await context.newPage();
        await page.goto(dashboard, { waitUntil: 'domcontentloaded' });
        const account = (await page.locator(selector).innerText()).trim();
        if (!account) throw new Error('未取得账号标识');
        results.push({ profile_id: id, account, source_url: page.url() });
        await page.close();
    } finally {
        await browser.close();
    }
}
await writeFile('profile-results.json', JSON.stringify(results, null, 2));
console.log({ profiles_checked: results.length });

执行 node check_profiles.mts，比较两个 Profile 的账号结果与人工登录预期。创建页面时复用已有 context，才能读取其登录状态；新建独立 context 不一定继承该 Profile 的 Cookie。

停止、重新启动和备份

客户端连接结束后回到 Manager 查看运行状态，并用其 Stop 操作结束不再使用的 Profile。不要仅根据 Playwright 代码执行完就推断 Profile 已停止；管理器仍是浏览器运行状态的所有者。

重新启动同一个 Profile，再检查账号是否保持登录。若目标站主动使会话过期，应按正常登录恢复，而不是保证持久目录能永久登录。

备份之前先停止相关 Profile，再停止 Manager，避免复制正在写入的目录。使用部署平台的卷备份能力保存 cloakprofiles，同时保存必要配置和版本信息。恢复时先用独立卷验证一个 Profile，不直接覆盖正在使用的正式目录。

不要把不同引擎、发布通道或升级前后的目录当成任意可互换的状态包。升级前保留可回退的数据副本，升级后先确认 UI、Profile 启动和后台账号三层结果。

常见问题与修复

UI 能打开但 Profile 起不来。 检查引擎下载、license 与账号容量。UI 可用不证明引擎已经准备好。

两个结果都显示同一账号。 检查是否用了同一个 Profile ID，是否共用目录或错误的 CDP 地址。先在界面分别确认账号，再看自动化结果。

CDP 返回认证错误。 核对 Manager 的 AUTH_TOKEN 与客户端 Bearer；license key 不能用作管理 API token。

创建了新 context 后登录丢失。 连接默认现有 context，确认后台 Cookie 所在的上下文。不要通过复制另一个账号的 Cookie 来掩盖身份混用。

更新容器后 Profile 消失。 检查是否仍挂载原来的 /data 卷，而不是新建了同名外观、不同数据的容器目录。没有持久卷的旧容器不能通过重新登录恢复全部历史状态。

脚本结束了但资源仍占用。 查看 Manager 的实际运行列表，停止属于本任务的 Profile，避免关闭其他人的浏览器。

Profile 管理的核心价值是让账号、数据目录、网络和运行状态有明确归属。只有这组关系不混用，多账号自动化结果才有解释基础。