WhatsApp 扫号任务说明
本文介绍一套基于移动端注册探测接口的「扫号」能力：批量判断手机号是否已在 WhatsApp 上注册，并给出任务侧可配置项与使用注意。
演示视频
以下为本方案的使用演示（若无法播放，可 在 YouTube 打开）：
能做什么
扫号任务会批量处理号码列表，对每个号码发起存在性探测，并汇总：
- 存在：服务端信号表明该号已注册（或可通过旧设备通道验证）
- 不存在：当前探测未给出已注册信号
- 失败：网络、限流或其它异常导致本次未完成判定
适合注册前筛号、批次核对等场景。任务采用与批量注册相同的思路：一个进程内生产者生成单号任务，多个消费者并发执行，而不是「一号一进程」。
号码怎么写
支持两种写法，可混用：
国际号（带
+）
例如+639956527641。已含国家码，不必再选国家号。国内号（不带
+）
例如13800138000。需在任务里配置国家号，系统再拼成完整国际号。
每行一个号码即可。
判定逻辑（概念层）
探测主要依赖 WhatsApp 移动端注册链路中的 存在性查询（/exist）：
- 若返回允许「旧设备 WhatsApp 验证码」等已注册相关信号，可直接记为存在。
- 部分情况下服务端会同时给出迁移等相关标记，也会计入存在统计。
可选开启 旧设备验证码兜底：当存在性查询未给出明确已注册信号时，再尝试向该号已登录的客户端发验证码（wa_old）。能成功发出，可作为二次存在证据；未开启则只看存在性查询，更快、对设备侧压力更小。
需要强调：存在性查询里的「是否允许某种验证方式」，并不总是稳定的「是否注册」布尔值。同一号码在不同时间、不同代理、不同探测强度下，服务端可能给出不同资格。大批量、高并发时更容易出现限流或资格收紧，因此统计结果应以当次任务为准，并做好重试与代理策略。
任务里可配置的项
| 配置 | 说明 |
|---|---|
| 代理 | 出网代理，探测走该通道 |
| 国家号 | 仅国内号（无 +）需要 |
| 设备类型 / App 版本 | 模拟的客户端环境 |
| 消费者线程 | 并发探测数量 |
| wa_old 兜底 | 是否在存在性查询未命中时再走旧设备验证码探测 |
| 重启 WhatsApp | 仅在需要设备完整性租约的路径上生效；默认关闭，复用已启动实例 |
完整性网关（Integrity）主要用于需要设备侧凭证的步骤（例如开启 wa_old 兜底时）。纯存在性查询通常不必重启客户端。
结果怎么看
任务过程中会持续上报进度。统计上常见维度包括：
- 总数 / 存在 / 不存在 / 失败 / 进行中
- migration：存在性查询中带迁移相关信号的号码
- banned：存在性查询中出现封禁类原因的号码
也可下载任务相关配置与中间结果，便于核对与归档。
使用建议
- 先小批量验证代理与号码格式，再放大并发。
- 国内号务必选对国家号；国际号用
+开头，避免重复拼码。 - 若只需粗筛，可先关闭 wa_old 兜底；漏报较多或需二次确认时再打开。
- 出现大量「资格为 0」或限流类失败时，降低线程数、更换代理或间隔重试，往往比反复加大并发更有效。
- 遵守当地法律法规与平台条款；仅在合法授权范围内使用。
小结
扫号任务把「逐号探测」收成可配置的批量作业：统一入口、多线程消费、实时统计。核心信号来自注册存在性查询，可选旧设备验证码兜底；服务端资格会随风控与探测强度变化，解读结果时请结合当次环境，而不是把单次字段当成永久标签。