如何将配置文件从其他浏览器迁移到 Undetectable

迁移到另一款反检测浏览器时，你会希望保留熟悉的工作环境：账号、Cookie、代理连接，以及清晰的项目隔离。为了避免迁移后还要弄清楚哪个配置文件属于谁、为什么某个网站又要求授权，请先从一个环境开始——并且只在检查完成后，再迁移其余环境。

Undetectable 有三种主要迁移方法：Undetectable Converter 扩展、手动导入 Cookie，以及通过 本地 API 迁移。它们适用于不同情况。

我们来逐一查看这些方法，并通过一个示例演示：将工作配置文件 Client-A 从另一个浏览器迁移到 Undetectable。

选择哪种迁移方法

你现有的内容	如何迁移	你需要准备什么
旧浏览器中的配置文件可以打开，并且你可以在其中安装扩展	Undetectable Converter	正在运行的源配置文件，以及同一台电脑上的 Undetectable 应用
Cookie 已经保存为单独的文件	手动导入	在 Undetectable 中创建配置文件、上传 Cookie，并配置连接
你有很多配置文件、数据导出，或自己的脚本	本地 API	准备数据并自动化创建配置文件
此前从 Undetectable 导出的 .prof 文件	内置配置文件导入	打开配置文件管理器并导入文件

首次迁移时，Converter 通常更方便。如果旧配置文件已经无法启动，但你仍然有 Cookie，请使用手动导入。

Undetectable Converter 和 Cookies Converter 是不同的工具。 前者是一个会在应用中创建配置文件的扩展。后者是用于转换 Cookie 格式的服务；它本身不会迁移配置文件。

会迁移哪些内容，以及哪些需要单独准备

通过 Converter 迁移不会创建旧浏览器的完整副本。它会迁移 Cookie，并在创建新配置文件时使用源环境中可用的参数。

数据	会如何处理
Cookie	迁移到新配置文件
浏览器和设备参数	用于创建环境；结果需要检查
代理	单独连接
配置文件名称	在迁移过程中设置
文件夹、标签和备注	手动迁移或通过 API 迁移
扩展及其数据	Converter 不会迁移；需要单独安装和配置
书签和已打开的标签页	Converter 不会迁移
localStorage, sessionStorage, IndexedDB	Converter 不会迁移
已保存的密码	不应指望它们会通过 Converter 被迁移

新配置文件也不会获得旧数字指纹的精确副本。尤其不应期待 Canvas、WebGL、Audio 或字体列表完全一致。在规划迁移到 Undetectable 时，务必要考虑这些限制。

这也引出另一个要点：导入 Cookie 可能会保留授权状态，但并不保证在每个网站上都有效。有些服务会使用额外存储、检查新环境，或再次要求登录确认。

迁移前需要准备什么

制作配置文件清单

对于多个环境，一个简单的表格就足够：

源配置文件	Undetectable 中的名称	代理	状态
Client-A	Client-A	Proxy-A	待迁移
Client-B	Client-B	Proxy-B	待迁移
Client-C	Client-C	Proxy-C	待迁移

如果你在团队中工作，请添加负责人。

当旧浏览器中的配置文件名称与客户名称不一致时，这类表格尤其有用。它能帮助你避免混淆 Cookie、连接和检查结果。

保留对源数据的访问

创建新配置文件后，不要立即删除旧配置文件。先检查必要的账号能否在 Undetectable 中打开、连接是否正常，以及日常任务所需工具是否可用。

请提前确保你可以访问密码和登录确认方式。Cookie 不能替代恢复授权的能力。

记录代理参数：连接类型、地址、端口、登录名和密码（如果使用）。对于移动代理，请保存 IP 更换链接。

检查所需套餐功能

通过本地 API 迁移（Converter 使用的就是它）时，应使用付费套餐——从 Base 起即可。仅进行这种迁移并不需要 Professional。

不要将它与从 Undetectable 导出本地配置文件混淆：后者有单独的套餐条件。

选择一个配置文件进行测试

从一个能代表你日常工作流程的环境开始。例如，它可能包含客户仪表板、有效授权、代理，以及一个必需扩展。

这样，你检查的不只是列表中是否出现了新行，还能确认是否可以继续工作。

方法 1. 通过 Undetectable Converter 迁移

该扩展安装在你要从中迁移数据的浏览器配置文件中。例如，如果你是从另一款反检测浏览器迁移，请先在其中启动所需环境，然后在打开的浏览器中安装 Converter。

将它安装到电脑上的普通 Chrome 中，并不会让扩展访问另一个反检测浏览器中各个配置文件的 Cookie。

步骤 1. 启动 Undetectable

打开应用并登录你的账号。迁移期间应用必须保持运行。

源浏览器和 Undetectable 必须在同一台电脑上运行：Converter 会连接到本地应用。

步骤 2. 找到本地 API 地址

在 Undetectable 中打开：

Settings → Main → API address 在我们的示例界面中，地址如下：

127.0.0.1 : 25325

127.0.0.1 表示你的电脑，冒号后的数字是连接到应用的端口。

这不是代理地址。 扩展必须使用 Undetectable 设置中的端口。如果你的程序中端口不同，请使用你自己的值。

你不需要为了与说明中的示例一致而更改应用的工作端口。

步骤 3. 打开源配置文件

在我们的示例中，在旧浏览器中启动 Client-A。

确保这是正确的环境：打开工作网站并检查账号。完成当前操作，以免迁移期间在两个浏览器中同时更改数据。

不要为了迁移而特意退出账号——目标正是保留可用的会话数据。

步骤 4. 在此配置文件中安装扩展

打开相应的官方商店：

• 适用于 Chromium 浏览器的 Undetectable Converter；
• 适用于 Firefox 的 Undetectable Converter。

安装后，在扩展菜单中找到 Converter。如有需要，将其图标固定到浏览器工具栏。

该扩展会从当前浏览器配置文件收集 Cookie，而不仅仅是从活动标签页中的网站收集。 如果个人账号和工作账号混在同一个普通 Chrome 配置文件中，仅打开正确的标签页并不能将它们彼此分离。

当你只需要迁移某一组特定 Cookie 时，更方便的做法是准备单独导出并使用手动导入。

步骤 5. 指定名称和端口

点击 Converter 图标。

在 Profile name 字段中，输入一个清晰的名称，例如：

Client-A

在 Undetectable local API Address 字段中，对照应用设置检查端口。

对于多个客户，请保持命名一致。如果所有新配置文件都叫 Test 或 New profile，检查结果会困难得多。

步骤 6. 点击 Create profile

扩展会将数据发送到 Undetectable 并创建新配置文件。等待操作完成。

看到 Profile is created 消息后，在应用中按指定名称找到该配置文件。

已验证的字段名称和操作顺序与 Undetectable Converter 界面一致。

如果结果不明确，先检查配置文件列表。不要反复点击按钮：再次创建可能会产生重复项。

步骤 7. 在首次工作启动前连接代理

打开新 Client-A 的设置，并为其分配所需代理。 如果之前的连接仍然有效，请在首次测试时使用它。这样，在迁移过程中同时变化的条件更少，也更容易定位可能的问题。

检查代理类型、地址、端口和授权数据。运行连接检查并保存设置。

也要检查起始页：在你配置好连接之前，配置文件不应意外打开工作仪表板。

步骤 8. 检查配置文件参数

将主要设置与你计划迁移的内容进行比较：

• 操作系统和浏览器环境类型；
• 屏幕分辨率；
• CPU 和内存；
• 语言和时区；
• 已分配的代理。

不要期待 User-Agent 或其他参数逐字节完全匹配。Converter 会基于可用数据帮助创建新环境，但迁移并不等同于克隆旧浏览器。

如果你还要更换电脑或操作系统，请在大规模迁移前单独测试该场景。

如何检查已迁移的配置文件

配置文件出现在列表中，说明它已经创建。要开始工作，还需要再做几项检查。

检查 Cookie

在配置文件设置中，打开 Cookie → View 标签页，并找到所需网站的域名。 有记录存在说明数据已经进入配置文件。但授权是否有效，需要在网站本身检查。

检查连接

启动配置文件并检查出口 IP。确保正在使用已分配的代理，并且连接符合你的工作场景。

如果页面打不开，先处理连接问题。重新导入 Cookie 无法修复不可用的代理。

打开工作网站

检查：

• 打开的是正确账号；
• 必要的部分可用；
• 你可以执行正常的工作操作；
• 没有未完成的登录确认请求。

对于 Client-A 示例，这可能意味着打开客户仪表板并查看其设置，但不更改数据。

如果网站要求授权，请按通常方式完成。再次要求登录本身并不意味着迁移操作有误。

关闭后重复检查

按常规方式关闭配置文件，然后再次打开。

确保连接和工作状态已保存。之后，将 Client-A 标记为已检查，并继续处理下一个环境。

方法 2. 通过 Cookie 手动迁移

如果你已经有 Cookie 导出文件，或者想自己准备新配置文件，此选项适用。

流程如下：

导出 Cookie → 创建环境 → 配置代理 → 导入 → 检查网站。

步骤 1. 从源配置文件导出 Cookie

使用旧浏览器中可用的导出工具。

为每个环境单独保存数据：

Client-A.cookies.json

Client-B.cookies.json

Client-C.cookies.txt

不要将不同客户的 Cookie 合并到一个文件中再上传到同一个配置文件。

导出命令名称取决于源浏览器。关键是你要获得 Cookie 本身，而不是其自有格式的配置文件归档。

步骤 2. 检查格式

Undetectable 支持以 JSON 和 Netscape 格式导入 Cookie。如果你已经有这两种格式之一的有效文件，则无需额外转换。

你可以通过文件浏览器选择文件、将其拖入导入字段，或以文本形式粘贴 Cookie。这些方法都可在 Cookie 工具 中使用。

如果需要将 Netscape 转换为 JSON，请使用 Cookies Converter：

1. 以文本形式打开 Cookie 文件。
2. 将内容复制到 Netscape format 字段中。
3. 点击 Convert。
4. 复制生成的 JSON。
5. 在导入到配置文件时使用该结果。

该转换器会更改数据结构。它不会恢复已过期的授权，也不会从第三方浏览器的任意归档中提取 Cookie。

步骤 3. 在 Undetectable 中创建配置文件

点击 New Profile 并设置名称，例如 Client-A。

选择合适的配置，检查主要参数，并配置代理连接。

对于手动迁移，这些操作尤其重要：Cookie 文件本身不会设置新配置文件的 IP、配置、语言或时区。

首次测试时，更方便的做法是创建一个单独的新环境，以免导入的数据与现有 Cookie 混在一起。

步骤 4. 上传 Cookie

在配置文件设置中，转到：

Cookie → Import 选择文件或粘贴准备好的数据。完成导入并保存配置文件。

注意 Import expired cookies 设置。如果禁用了导入过期 Cookie，这类条目将被跳过。启用此选项并不会延长网站端的会话有效期。

处理现有配置文件时，请先关闭其浏览器窗口，并确保你正在编辑正确的环境。

步骤 5. 检查结果

打开 Cookie → View，找到域名，然后启动配置文件并检查工作网站。

手动迁移适用与 Converter 相同的检查：连接、正确账号、正常工作操作，以及重新启动配置文件。

方法 3. 通过本地 API 进行批量迁移

如果你有数百个环境，并且数据可以以结构化形式获取，手动迁移会耗费大量时间。

本地 API 允许你自动化创建包含 Cookie、代理和组织数据的配置文件。但它不会自行从另一个浏览器提取信息：你需要先获得可用的导出，或准备自己的导出。

如何组织这类迁移

1. 准备源数据。 为每个环境保存其标识符、名称、Cookie、连接参数和必要设置。
2. 定义字段映射。 决定旧名称、文件夹、标签和备注在 Undetectable 中如何表示。
3. 创建一个配置文件。 这会使用 POST /profile/create 请求。
4. 保存收到的 ID。 将其与源配置文件的标识符关联。
5. 检查结果。 读取已创建环境的参数和 Cookie，然后检查工作场景。
6. 分批迁移其余配置文件。 分别记录成功和错误。

字段名称和可用方法汇总在 本地 API 参考 中。

像下面这样的表格足以跟踪结果：

源 ID	名称	新 ID	创建	检查
source-001	Client-A	API 响应中的 ID	成功	通过
source-002	Client-B	API 响应中的 ID	成功	需要重新登录
source-003	Client-C	—	错误	未启动

将配置文件创建成功与可投入工作区分开来。这是两个不同阶段。

如果请求超时，先检查配置文件是否已经出现。不检查就重新发送可能会创建重复项。

如果你已经在旧浏览器中有自动化，请单独适配创建、启动和停止配置文件的命令。页面内的工作场景也应先在一个新环境中检查，再进行批量启动。

能否直接导入另一个浏览器的归档

Undetectable 的内置配置文件导入和通过 Converter 迁移解决的是不同任务。

如果你有从 Undetectable 导出的 .prof 文件，请打开 Profile Manager → Import，选择文件，并等待配置文件出现。导入从 Base 起可用。更多详情见配置文件导入和导出说明。

第三方浏览器归档不能仅仅因为里面也包含配置文件数据，就被视为兼容。重命名文件扩展名并不会转换其结构。

对于第三方格式，请使用 Converter、可用的 Cookie 导出，或为 API 准备数据。

迁移后需要配置什么

扩展

重新安装所需的工作工具。安装扩展不会自动恢复其内部数据、设置或授权。

常用扩展组合可以通过 Extensions Manager 添加。请注意，以这种方式添加的扩展会应用到现有和新的配置文件。对于单独工具，在特定环境中安装可能更方便。

对于钱包扩展和其他拥有自己存储的工具，请使用它们提供的恢复流程。Cookie 迁移不能替代该流程。

书签和起始页

恢复你每天使用的链接。如果源浏览器允许导出书签，请单独保存。

检查起始页和启动行为，确保新配置文件会打开所需工作资源。

文件夹、标签和备注

重新创建你熟悉的项目组织方式。例如：

• 文件夹 — 客户；
• 标签 — 迁移阶段；
• 备注 — 仍需检查的内容。

不要在迁移完成前把所有已迁移环境都堆在一起。事后凭记忆整理会更困难。

团队访问

检查完成后，确定哪些配置文件应供同事使用。为它们配置云存储、组和用户权限。

本地创建的配置文件不会仅因为其他员工使用同一个订阅，就自动对他们可用。

如果迁移过程中出现问题

情况	检查什么
Converter 显示 Run Undetectable or check port number	应用是否正在运行、你是否已登录、端口是否匹配，以及两个浏览器是否都在同一台电脑上运行
Converter 提示无法创建配置文件	套餐功能、配置是否可用，以及你是否可以手动创建普通配置文件
看不到新配置文件	按名称搜索、活动筛选器、所选文件夹，以及扩展中的操作结果
创建了相同的配置文件	你是否在检查第一次结果之前又发送了请求
网站要求你重新登录	所需域名的 Cookie 是否存在、它们是否过期，以及网站的额外要求
打开了另一个账号	是否选择了正确的源配置文件，以及 Cookie 文件是否混淆
Cookie 无法导入	它是否确实是 JSON/Netscape、文件是否损坏，以及是否把文件路径而不是数据粘贴了进去
工作网站打不开	代理、与提供商的授权，以及这台电脑上的连接可用性
扩展或其设置缺失	它们需要单独安装和恢复；Converter 不会迁移它们

如果存在代理问题，请在同一台电脑上分别在使用和不使用 VPN 的情况下检查，或在另一个程序中检查。代理提供商面板中显示工作状态，并不等于连接一定能从你的网络访问。

如果错误仍然存在，请保存其准确文本和发生阶段。这比重复迁移整组配置文件更有助于诊断。

什么时候可以结束迁移

当你能够在配置文件中继续正常工作时，可以认为它已完成迁移：

• 环境具有清晰名称；
• 所需代理已分配并检查；
• 正确账号可以打开；
• 必要扩展可以工作；
• 工作链接和设置已恢复；
• 关闭并重新启动后状态会保存；
• 如果该配置文件由团队使用，员工已获得所需访问权限。

检查完第一个配置文件后，迁移一小组并重复相同流程。然后再继续处理其余配置文件。

这样可以让迁移保持可控：对于每个环境，都能清楚知道哪些数据已迁移、哪些内容已检查，以及还有哪些内容需要配置。