复盘｜TikTok 云机自动登录 workflow（GeeLark 网页远控

00速览

六个问题，一屏看懂

给没时间读全文的人：每张卡对应下面一个章节。

Q1问题有多严重

第一次登录被锁，这个号基本作废

锁后过 9 天仍可能不解锁，换 IP、换设备、换登录方式都救不回。10-22 批次 11 个号只成 3 个，成功率约 27%。

看问题 →

Q2根因怎么判断的

同一云机、同一 IP，人手动登录就成功了

11-05 运营同学手动登录 10-28 失败的两个号成功；一度怀疑「号到手前已被锁」，11-07 推翻，判断为登录太像机器人。

看时间线 →

Q3新办法是什么

驱动网页远控，按人的节奏点和打

真实触摸按压 65–140ms、曲线轨迹；逐字输入每字 110–300ms；只看画面截图 + OCR，云机里不抓树、不注入命令。

看新旧对比 →

Q4效果如何

新号首登全部一次通过

新路线首测 2/2，默认模型独立验收 3/3，都是一次密码、一次验证码。11-08 定为默认路线。

看实测 →

Q5还剩什么风险

样本小，不证明不会再被锁

已锁的号救不回；「同出口一次一个」还只是编排规则，没有中央硬门禁；TikTok 改版会增加人工判断次数。

看风险 →

Q6下一步做什么

按出口轮转扩大样本，补硬门禁

剩余新号「每个出口轮转、一次一个」推进；同出口互斥做成硬门禁；登录完成后接装修、回填，交夜班发布。

看下一步 →

01业务背景

登录是开号链路的瓶颈

号买得到、云机建得好，但第一次登录一旦被锁，这个号基本作废——前面的投入一起报废。

STEP 1

购买

开号起点

瓶颈

STEP 2

登录

首次登录，被锁即作废

STEP 3

装修

登录后接手

STEP 4

回填名额

开号完成

之后

夜班模式

Night Shift 出片与发布

规模

需求表初始盘点

32条

需求

127个

名额

一号一机一出口

每个账号独占一套运行环境：

云手机独占一台 GeeLark 云机

出口 IP绑定一条海外代理

TikTok装对应地区版本

10-09 一批 54 个新号 · 按地区分布

单位：个

阿联酋

15

巴西

11

墨西哥

10

美国

5

法国

4

西班牙

3

德国

3

沙特

3

8 个国家 / 地区合计 54

02问题

首次提交密码，直接被锁

2026 年 10 月至 11 月多次出现。锁定几乎不可逆，所以关键不是「锁了怎么救」，而是「第一次登录别触发」。

10-22 采购批次 · 试登 11 个号

每格代表一个账号

✓✓✓ ××××× ???

成功 3 被锁 5 账号不存在 3

≈27%

成功率。被锁的数量（5）
比成功的（3）还多。

Maximum number of attempts reachedGeeLark 返回码 20125 · 首次提交密码时出现

9天之后仍可能不解锁

以下手段都救不回已锁的号：

换 IP换设备换登录方式

→ 关键是：第一次登录别触发。

出口 IP 目标进度（11-05 前后）

目标：11 条出口 IP，每条至少登成 1 个号

3 / 11 条

✓✓✓4567891011

03根因判断

多轮排查，一次推翻，一个转折

从工具版本、官方 RPA、慢速单次提交一路排查都没定位；11-05 的人工登录成功是关键线索，11-07 晚推翻「供应商侧已锁」，落到「操作太像机器人」。

10-27

升级 GeeLark CLI？

未证明能解除

10-28

改用官方 RPA 登录任务

仍报 20125

11-03

放慢：逐页约 110 秒，只提交一次密码

仍 Maximum

11-05/06

号在供应商侧到手前就已被锁

已推翻

11-07 22:15

登录动作太像机器人

采纳 · 已验证

10-09
起点
54 个新号入库，进入登录波次。
10-27
排查
登录专项：核查 GeeLark CLI 版本（本机 1.0.10，官方最新 1.0.27），新版未证明能解除 Maximum。
10-28
排查
两个号用 GeeLark 官方 RPA 登录任务，报 20125。
10-29
调整
取消「同一出口两次登录间隔 30 分钟」的固定排班。
11-03
排查
独立慢速诊断：一个旧号逐页约 110 秒、只提交一次密码，仍然 Maximum；无法区分账号、IP、自动化哪个是根因。
11-05
关键线索
运营同学在同一台云机、同一个 IP 上手动登录 10-28 失败的那两个号，成功。（中间隔了 8 天，冷却因素不能完全排除）
11-05/06
误判 · 后被推翻
一度判断「号在供应商侧到手前就已被锁」。
11-0722:15
转折
推翻上一条：判断根因是登录太像机器人，要求换成人的操作方式。
11-07晚
验证
新路线实测：新号 2/2 成功；已被锁的号 0/1（9 天后仍 Maximum）。
11-0801:46
落地
登录技能 geelark-tiktok-login 改为「网页远控人工节奏优先」，官方 RPA 不再用于首次登录。
11-07～08
验收
默认模型验收：3/3 成功。

04新办法

从「系统注入」换成「像人一样操作」

旧路线的每个动作都带着自动化痕迹；新路线通过 GeeLark 网页远控操作云机，点击和输入都按人的节奏来，云机里不留额外痕迹。

维度

✕ 旧路线 · 系统注入 / 官方 RPA

✓ 新路线 · 网页远控 + 人工节奏

点击

旧路线

input tap 系统注入，没有按压过程。

示意：一个时间点，没有按下—抬起

新路线

远控点按写入云机的真实触摸设备，按压 65–140ms，贝塞尔曲线移动轨迹，±2px 抖动。

示意：曲线移动 → 带抖动落点 → 有时长的按压

打字

旧路线

input text 一次性注入整串，退格和验证码按键连发。

新路线

逐字输入，每字 110–300ms，偶有停顿；远控打字不产生按键事件。

看页面

旧路线

反复执行 uiautomator dump 抓 UI 树。

新路线

只看远控画面截图 + OCR，云机里不抓树、不注入命令。

附加痕迹

旧路线

官方 RPA 会装 GeeAuto 并开启 GeeLark 无障碍服务。

新路线

✓ 无

要点旧路线的四类痕迹（注入式点击、整串输入、反复抓 UI 树、附加 GeeAuto 与无障碍服务）在新路线里全部去掉。图形为示意，数值取自上表。

05实测效果

新号首登：一次密码、一次验证码

每个方块代表一个账号。绿色 = 成功，红色 = 失败，斜纹 = 验证码没打全而停手（问题已修复）。

新号 · 新路线

新路线 · 新号（11-07 首测）每个号一次密码、一次验证码

2/2

默认模型只看技能，独立登录新号deepseek-flash + vlab-worker · 一次密码一次验证码

3/3

此前强模型登录新号另 2 个因验证码没打全而停手，问题已修复

5/7

边界样本 · 换方式救不回已锁的号

已被锁的号9 天后仍 Maximum

0/1

密码已通过但中途放弃，20 多分钟后重登1 成 1 败，败的是 Maximum

1/2

新购测试号成本

¥2.5 / 单号

结论边界

样本小，只说明这条路可用，不证明以后不会再 Maximum；已锁的号换方式救不回来。各组只有个位数个号，组间可能有重叠，不宜相加。

06workflow

每个账号一条流水线

准入之后五步走完，无论成败都要收尾关机。截图或页面跳转不算登录成功的证据。

0 · 准入读共用台账：这个号或它的出口 IP 有没有 hold、有没有正在进行的登录。同一个出口 IP 同时只登一个号，不同出口可以并行。

01

open

开机（30 分钟无操作自动关机），打开远控页，核对出口 IP 是该号的代理出口、TikTok 已装好。不对就停。

03

onboard

关掉登录后的引导页，停在推荐流。

04

sync

核对云机内登录身份与台账用户名一致，回写「账号状态 = 已登录」，备注追加不覆盖，回读一致才算完成。

05

close

关远控页并关机，看到关机确认才算收尾。

成功或失败都必须执行

login 自动序列密码只提交一次 · 完整验证码只填一次

打开 TikTok
登录
用户名
密码
同意条款
Authenticator
填码

完成判据三件齐才算完成

身份核验通过

回写成功

已关机

✕ 不算证据：截图、页面跳转。

07结果码

login 返回什么，就按什么处理

五类结果，处理方式事先写死：终态不重试、不换 IP 或设备；只有「可恢复」一类允许 agent 看画面介入。

SUCCESS

成功

logged_inalready_logged_in

处理进入 onboard / sync

TERMINAL

终态 · 不重试

maximum_attemptsaccount_not_existaccount_suspendedpassword_rejectedrate_limitedcode_rejected

处理不重试、不换 IP 或设备，记录后关机

HANDOFF

交给本人

captcha

处理人机验证：保持开机，本人接管后再跑

NETWORK

网络问题

network_error

处理代理 / 网络问题，不是账号问题

RECOVERABLE

可恢复

unknown_pagestuck_same_page_3xstream_frozen密码未提交类

处理agent 看画面做一个动作再重跑；同一页面连做 3 个动作没变化就停

08护栏

写进工具里的约束，agent 判断错了也拦得住

安全约束由工具强制执行；节奏与准入规则决定什么时候能登、什么时候必须停。

工具内置安全约束

工具强制

1密码只能提交一次，完整验证码只能填一次；agent 判断错了工具也会拒绝。
2提交密码前核对密码框圆点数等于密码长度，不一致不提交。
3验证码先点第一个格子、等键盘出来再逐位填；填完重开远控页数格子，不足 6 位允许清空重填一次。
4凭据只在脚本进程内读取，不进聊天、日志、文件、命令行参数；远控链接带令牌，只在内存里，不落盘。
5远控画面会冻住或滞后（最长约 5 分钟），工具按状态栏时钟检测，冻住就自动重开远控页。

节奏与准入规则

编排规则

1同一出口 IP 同时只登一个号；不同出口可并行。
2同出口下一个号不设固定等待间隔（10-29 取消 30 分钟排班），上一条有终态即可；平台给倒计时就遵守。
3出现 Maximum、安全警告或结果未知：该号与同出口后续登录暂停（hold）。不通过换 IP / 设备绕过平台限制。
4连续 3 个日历日各有明确限流证据，标为需替换，交给换号流程。

常见报错分型

报错	含义	处理
Account doesn't exist	账号不存在	只记录，不重试
Maximum number of attempts reached	限流 / 锁定	等冷却或换号，硬试会加深锁定
Account is currently suspended	停用 / 封禁	白号 24 小时内首登封号有售后，超期无
No internet connection（红字）	设备网络 / 代理未就绪	强停重开 TikTok，必要时重启云机

09风险 · 下一步

路线可用，但还没到「放心」

五项未解决的问题，三件接下来要做的事。

仍未解决 / 风险

样本小，不能当「防限流」的证明每组只有个位数个号，各组之间可能有重叠。
已被锁的号救不回来库存里的旧锁号只能放弃或等更久。
同出口互斥还没有硬门禁「同出口一次一个」目前是 agent 遵守的编排规则，还没有中央进程级的硬门禁。
Outlook 邮箱型账号暂缓新采购和批量登录暂缓，这条路线单独验收。
TikTok 改版会增加人工判断自动驾驶会更频繁地停下交给 agent 看画面，流程不会断，但人工判断次数会上升。

下一步（建议）

三项建议

扩大样本用新路线把剩余待登录的新号按「每个出口轮转、一次一个」推进，累积更大样本。
互斥做成硬门禁把同出口互斥从编排规则变成真正的硬门禁。
接通后续链路登录完成后接装修和回填，交给夜班发布。

新路线已是登录技能默认路线（11-08 起），官方 RPA 不再用于首次登录。