基于 MTProto 协议的移动端 SDK 接入踩坑笔记

前言

最近在维护一个海外项目的消息推送模块时，需要接入某基于 MTProto 协议的 IM 服务（内部习惯称其为纸飞机）进行 Bot 日志监控。在移动端 SDK 登录环节遇到了典型的验证码下发失败问题，排查过程持续约 40 分钟。现将完整的链路分析记录如下，供后续遇到类似协议层接入问题的同学参考。

一、环境信息

测试设备：iOS 17 / Android 14 双平台复现

网络环境：中国移动 / 联通 / 电信三网切换，企业 Wi-Fi 与 5G 混合测试

SDK 版本：官方移动端 SDK v10.x 系列

协议层：MTProto 2.0

二、问题现象

初始化 SDK，进入登录页，输入 +86 手机号

调用 auth.sendCode 接口，界面进入 loading 状态

约 30-45 秒后请求超时，手机无短信到达

第 3 次重试后，界面弹出 SMS fee 提示框

完成支付后再次请求，依然无验证码到达

切换语音验证通道，该按钮处于 disabled 状态，无法触发

基础排查结论：更换 SIM 卡、切换三大运营商蜂窝网络、更换 Wi-Fi 环境（含企业专线与家庭宽带），现象 100% 复现。排除本地终端与接入网问题。

三、逐层排查分析

3.1 短信网关层（运营商侧）

通过抓包发现，SDK 在点击"发送验证码"后，会向服务端发送 auth.sendCode 请求。服务端响应正常（HTTP 200），但后续承载验证码的国际 SMS 通道在国内运营商网关处被静默丢弃。

特征表现：

用户侧无短信送达回执

运营商侧无拦截通知

网关日志无明确拒绝记录，表现为黑洞路由

这是典型的国际短信风控策略，部分海外服务的短信号码段（尤其是 +1 / +44 开头的下发号段）会被国内短信网关的灰名单机制静默过滤。

3.2 服务端风控层（SDK 侧）

在频繁触发 auth.sendCode 接口后，服务端返回的响应中出现了 FLOOD_WAIT_3600 错误码。此时系统进入 Flood Control 保护状态：

强制要求支付 SMS fee 作为验证门槛

对当前手机号实施验证码下发限速（rate limit）

部分情况下直接封禁该号码的短信通道，仅保留语音验证（但语音通道在国内同样受限）

此时继续重试会指数级加剧限制时长，形成请求死锁。

3.3 传输层与协议握手层

MTProto 协议在登录阶段需要与远端 DC（数据中心）建立加密长连接。官方 SDK 默认尝试连接境外 DC 节点，握手过程中若遇到中间网络设备的 RST 包或 TLS 指纹干扰，会导致 handshake timeout。

抓包显示：

TCP 三次握手正常完成

但在 MTProto 协议交换阶段（0xefefefef 起始包），连接被异常终止

重试后 SDK 切换 DC，但可用 DC 池有限，最终全部超时

四、解决方案：协议兼容实现接入

既然官方 SDK 的登录链路在当前网络环境下存在网关拦截 + 服务端风控 + 握手异常的三重限制，考虑采用基于相同 MTProto 协议规范的开源实现进行接入。

该实现的核心差异点：

登录流程绕过官方 SDK 的 DC 选择策略，采用更灵活的握手方式

在相同网络环境下，auth.sendCode 请求响应正常，验证码秒级到达

SMS fee 弹窗未再触发

接入后功能验证：

中文界面：开箱即用，无需额外国际化配置

网络连通：自动适配网络环境，无需手动配置传输层参数

消息收发：基于 MTProto 的端到端加密通信正常

频道浏览与 Bot 交互：API 调用正常

多账号切换与推送服务：后台保活与 APNs / FCM 推送正常

五、技术结论

网关层不可控：国际 SMS 通道的风控策略属于运营商侧黑盒，开发者侧无法干预

服务端风控有策略：官方 SDK 的频繁重试会触发 Flood Control，正确做法是遇到 FLOOD_WAIT_X 响应后等待指定秒数，而非连续重试

协议层可替代：基于 MTProto 协议规范的开源实现，在协议兼容的前提下，能够绕过官方 SDK 的特定限制，提供更稳定的接入体验

当官方 SDK 的某个链路被网络策略或风控机制卡死时，在协议规范允许的范围内寻找兼容实现，是效率最高的排查方向。

六、讨论

有没有同学在接入海外 IM 协议的 Bot API 时，遇到过类似的登录通道或 DC 握手问题？除了切换协议实现，你们是否尝试过通过自建 MTProto Proxy 或其他传输层方案来解决？欢迎在评论区分享你的排查经历。

本文系个人技术踩坑记录，仅供开发调试参考。