迁移前先冻结哪些东西？
迁移前先把原环境冻结下来：原 profile 名称、代理编号、登录人、团队权限、最近一次正常登录时间。不要一边迁移，一边改密码、换代理、交接 owner、修改收款资料。
最容易出事的不是某个字段错了，而是没人知道「迁移前是什么样」。如果旧环境还能打开，先保存旧 profile 的截图、导出文件名、代理表和权限表；如果旧环境已经打不开，也要保留错误提示和时间点。
| 要冻结的对象 | 记录什么 | 为什么要先记 |
|---|---|---|
| 原 profile | 名称、ID、分组、创建人 | 防止迁移后找不到对应关系 |
| 代理 | IP、国家、ASN、协议、账号密码 | 判断登录地区是否突变 |
| 团队权限 | owner、可编辑成员、最近操作者 | 排查多人同时登录 |
| 平台后台 | 最近正常登录时间、二次验证状态 | 判断异常是否由迁移触发 |
| 导出文件 | 文件名、导出时间、保存位置 | 方便回滚和追责 |
哪 7 个字段必须逐项验？
迁移验收不要只问「Cookie 在不在」。Cookie 能让页面看起来已登录，但平台看到的是一整套环境：出口、浏览器指纹、系统语言、时区和团队操作轨迹。
| 字段 | 具体看什么 | 异常信号 |
|---|---|---|
| Proxy | IP、国家、ASN、协议和认证方式 | 国家突变、代理连不上、认证失败 |
| Cookie | 低风险页面的登录态 | 一进后台就要求重新验证 |
| WebRTC | 是否暴露本机地址 | 本机地址和代理出口不一致 |
| DNS | DNS 出口和代理地区 | DNS 落到本地网络或其他国家 |
| Timezone | 系统时区和历史地区 | 美国店突然显示亚洲时区 |
| Language | 浏览器语言和平台语言 | 语言从英文变成中文或混杂 |
| UA/内核 | 浏览器内核、UA、版本跨度 | 老账号突然换成很新的浏览器指纹 |
把这 7 项截图放在同一份记录里，不要分散在聊天窗口。后面如果出现二次验证、支付风控或广告账户安全提示，至少能回看是哪一项先变了。
先拿哪 3 个 profile 试水？
第一批不要选主店、收款后台、广告高消耗账户。选 3 个低风险 profile：只登录邮箱、素材库、普通报表或无资金动作的后台页面。
这 3 个 profile 的价值不是「迁移成功」，而是帮你观察新环境会不会触发二次验证。24 小时里只做打开、停留、退出，不要改资料、不要清 Cookie、不要批量登录同一平台。
如果 3 个样本里有 1 个触发验证，先暂停扩大批次。把代理、WebRTC、DNS、时区、语言和 UA 回看一遍，再决定是修复当前 profile，还是回到旧环境重新导出。
处理顺序怎么排？
先处理会继续制造风险的变量，再处理页面体验问题。代理连不上、地区突变、DNS 跑偏、WebRTC 暴露本机地址，这类问题会影响后续所有登录，优先级高于书签、插件和窗口大小。
建议按这个顺序走：
- 先确认旧环境是否还能打开，能打开就不要立刻删除。
- 再确认新 profile 的代理和 DNS 是否在同一地区逻辑内。
- 接着看 WebRTC、时区、语言、UA 是否和历史使用习惯冲突。
- 最后用低风险页面测试 Cookie 和登录态，不要直接进资金、税务、收款页面。
今天只改一个主变量，观察结果后再动下一项。一次同时改代理、UA、语言和密码，第二天没人能判断是哪一步触发了异常。
团队后台登录要怎么管？
Profile 迁移期间，最怕同一个店铺在旧浏览器、新浏览器、不同城市设备之间来回跳。迁移窗口里固定一名 owner 操作，其他成员只看截图和记录，不要用自己的电脑试登录。
跨境团队如果多人管理广告、收款、店铺或平台后台，可以使用静态原生 IP + 真实 ISP承载核心后台操作。这里的重点是固定操作者、设备和关键改动记录，不是用线路替代平台审核材料。
权限也要一起收口。迁移当天先停掉离职成员、外包临时账号和不必要的编辑权限；等低风险样本跑完，再恢复必须的协作成员。
什么时候要暂停新增动作？
只要出现二次验证、支付资料确认、广告账户安全提示、店铺健康警告，就先暂停新增动作。暂停不是放弃，而是避免把问题从「一次迁移异常」扩大成「连续多次高敏感操作」。
暂停后只做三件事：保存提示页、标记触发时间、回看 7 项字段。不要马上删 profile、换密码、换代理、重新创建店铺资料；这些动作会让原本能解释的问题变得更难复盘。
哪些记录要保留到复盘？
复盘只留能被第三方核对的记录：后台截图、导出文件名、代理表、成员权限、case ID、邮件原文、操作时间和负责人。口头承诺可以放备注，不能当主证据。
建议每个迁移批次建一张表，字段至少包括：原 profile、目标 profile、代理编号、owner、迁移时间、首次登录时间、是否触发验证、处理结果。下一批迁移前先看上一批表格，不要凭感觉扩大范围。
相关阅读
FAQ
只迁 Cookie 可以吗？
不够。Cookie 只能说明登录态可能还在，不能证明代理、WebRTC、DNS、时区、语言和 UA 连续。核心店铺至少要做一轮低风险页面观察。
迁移后立刻要求二次验证怎么办？
先停用该 profile 的后续操作，记录验证页面、时间和代理信息。不要马上换密码或换设备，先回看原 profile 是否还能稳定访问。
WebRTC 和 DNS 哪个更优先？
两个都要看。WebRTC 暴露本机地址会让环境不一致，DNS 出口和代理地区不一致也会造成解释成本。排查时不要只看 IP 检测页。
迁移能批量做吗？
可以批量准备，但不要批量登录核心后台。先选 3 个低风险 profile 跑完整流程，通过后再扩大批次。
迁移失败要不要删掉重建？
不要急着重建。先保留原 profile、迁移文件和错误截图。重建会丢掉连续性，除非你已经确认原数据不可用。
来源与时间戳
- AdsPower docs: transferring profiles to AdsPower，访问核对：2026-05-22。
- AdsPower docs: Global Settings，访问核对：2026-05-22。
- AdsPower docs: profile migration，访问核对：2026-05-22。