短信验证码看似简单的6位数字实则暗藏复杂业务链路与风控挑战。从游戏行业的账号体系保护到黑灰产攻防的成本平衡短信防控需要在体验、安全与通道稳定性间寻找微妙的平衡点。本文将深度拆解短信风控的三层防御体系揭秘那些隐藏在发送按钮背后的业务逻辑与产品设计哲学。一、短信不是一个按钮而是一条高风险链路最近 vibe coding 很火一句话可能就能生成一个登录框。输入手机号、点击获取验证码、填验证码、完成注册看起来非常顺滑。但真正做过账号体系的人都知道登录框只是冰山露出来的一角。它下面藏着短信通道、验证码校验、账号注册、设备识别、渠道投诉、供应商评级、黑名单联动等一整套业务链路。游戏行业尤其明显。游戏是典型的大 ToC 业务用户规模大、账号价值高、充值场景多、权益体系复杂只要一个手机号能注册账号背后就可能对应礼包、首充、拉新返利、渠道结算、虚拟资产交易等利益。利益足够大黑灰产自然会围上来。短信验证码本身又是一个很特殊的入口。正常用户收不到验证码会影响注册转化异常请求大量消耗短信会带来直接费用更严重的是如果某个短信签名短时间内投诉过多运营商和通道商可能会对签名降频、拦截甚至封禁。到这个时候受影响的就不是几个异常手机号而是整条正常业务链路。我之前做过一段时间短信产品经理对短信下发机制有一些了解。最近在账号风控治理中又重新接触短信相关防控发现短信这件事看似基础但真正要做好并不简单。它不是单纯“加一个验证码”或者“限制一分钟一次”就能解决的问题而是要在成本、体验、识别能力和处置策略之间不断平衡。这篇文章不讲短信供应商商务选型也不讲具体攻击脚本。这里我只从产品和风控落地视角聊一聊比较通用的短信防控实践。二、先建立一个共识短信风控要看全链路很多团队做短信防控第一反应是卡“发送验证码”这个动作。这个方向没错但不够。一条验证码短信从用户点击按钮开始至少会经过五个关键环节用户请求、基础频控、风险决策、短信网关、验证码提交。短信发送成功也不是终点后面还要看验证码是否被提交、是否注册成功、是否触发投诉。如果只看发送动作就会漏掉很多重要信号。比如某批请求发送频率并不高但验证码提交几乎都是秒过某批手机号分散在不同 IP 上但设备指纹高度相似某批请求没有造成注册成功却造成大量短信投诉。这些都不是单点频控能发现的。所以短信风控的目标不是“让短信少发”而是让该发的短信稳定发出去让不该发的请求在合适的位置被拦下或被二次验证。这句话听起来像废话但它决定了产品设计方向不能只追求拦截率也不能只追求用户体验。规则太紧正常用户注册会受影响规则太松短信通道和账号体系都会暴露在风险里。我会把短信防控拆成三层成本门槛层、行为识别层、分级处置层。第一层是成本门槛层用低成本规则挡住最明显的异常请求。第二层是行为识别层通过设备、请求、提交行为、黑名单等多维数据识别复杂机器流量。第三层是分级处置层对疑似风险请求不简单误杀而是通过上行短信、扫脸、人机挑战等方式进一步确认。三、第一层成本门槛层先挡住最明显的异常短信风控最基础的能力一定是频控。不要嫌它简单很多线上事故就是因为最基础的频控没做好。频控通常围绕手机号、IP、设备、账号、业务场景展开。比如同一手机号 1 分钟内最多发送 1 次1 小时最多发送 5 次24 小时最多发送 10 次同一 IP、同一设备或同一浏览器指纹也要有对应阈值。这里有一个容易被忽略的问题自然时间和滚动时间。自然时间是按照固定时间边界计数比如“今天 0 点到 24 点最多 10 次”。滚动时间是从当前请求向前回看比如“过去 24 小时最多 10 次”。对于短信风控来说最佳实践通常是滚动计数。为什么因为自然时间存在边界漏洞。假设系统按自然日计数攻击者可以在 23:58 打满当天额度0:01 之后额度清零又继续请求一轮。规则看起来没问题实际防控被时间边界绕开了。滚动时间实现成本更高尤其在数据量大时会涉及缓存、滑动窗口、聚合统计但它更符合风控场景。产品经理在写需求时不要只写“24 小时最多 X 次”最好明确口径是自然日还是过去 24 小时是按手机号计数还是手机号 IP 设备组合计数命中阈值后是直接拦截还是延长冷却时间。除了频控图形验证码也是成本门槛层的重要工具。很多人觉得图形验证码很基础但从攻防视角看它贯穿整个短信盗刷防控过程。常见的图形验证码包括滑动拼图、文字点选、图标点选、语序选词、空间推理、障碍躲避等。验证码的价值不只是“让用户做一道题”而是提升机器请求成本并给系统提供行为数据比如轨迹是否自然、完成时间是否异常、同一设备是否高频通过。当然验证码不是越难越好。注册登录是高转化场景如果一上来就给所有用户弹复杂验证码正常用户会被一起惩罚。更合理的方式是分层触发低风险用户无感通过中风险用户触发轻量验证码高风险用户触发更强验证。号段识别也属于基础能力。比如 170、171、165 等虚拟运营商号段在某些业务里风险更高可以根据业务情况做更严格的策略。但不建议把虚拟号段简单等同于黑名单直接全量拦截会带来误伤。更稳妥的做法是提高验证等级、降低发送频次、叠加设备和 IP 风险判断。成本门槛层解决的是“别让明显异常请求轻松进来”。它不追求特别聪明但必须稳定、清晰、可解释。四、第二层行为识别层把孤立规则变成风险判断第一层规则可以挡住一部分粗糙流量但挡不住更成熟的黑灰产。成熟黑产不会只用一个 IP、一个手机号、一个设备猛冲它会拆散请求分布式地试探系统阈值。这时候就需要进入行为识别层。行为识别层的核心是多维数据。产品上至少要能拿到手机号、IP、设备指纹、账号、渠道、业务场景、验证码生成时间、验证码提交时间、提交结果、失败次数、请求来源、前端环境等信息。没有这些埋点风控就只能靠猜。设备指纹是这里的关键能力。它不是单纯拿一个设备 ID而是综合浏览器、系统、分辨率、时区、字体、Canvas、网络环境、客户端版本等信息生成相对稳定的设备标识用来识别“换手机号、换 IP但设备特征高度相似”的请求。前端请求加密和参数校验也很重要。它不能从根本上防住所有攻击但可以提高脚本化请求门槛。比如短信发送接口不应该裸奔前后端需要对关键参数、时间戳、随机串、业务场景进行校验避免接口被直接复用。注意这类能力的定位是提高成本不是绝对安全真正的风控仍然要靠服务端决策。验证码提交行为同样值得关注。正常用户收到短信后通常会有一个阅读和输入过程。如果大量验证码都在极短时间内提交成功就要怀疑是否存在接口自动化、短信接收平台、批量控制设备等风险。这里不用把规则写死成“多少秒一定异常”而是结合业务基线做分层判断。黑名单库是行为识别层的另一个基础设施。它不应该只是一个静态表而应该是动态更新的风险资产库至少包含以下几类黑名单最怕两个问题一是更新慢等运营手动导入时风险已经过去二是没有过期机制半年以前的风险数据一直影响正常用户。比较好的方式是给名单设置来源、等级、命中原因、过期时间和复核机制。行为识别层的重点不是把规则写得多复杂而是把原本分散的数据串起来。手机号、IP、设备单独看都正常组合起来可能就不正常。风控能力的差距很多时候就在这个“组合判断”里。五、第三层分级处置层别把风控做成一刀切短信风控最难的地方不是拦截黑产而是不误伤正常用户。尤其在游戏业务里用户注册和登录往往发生在高情绪场景新游开服、活动领取、好友邀请、充值回流。这个时候如果正常用户收不到验证码或者被连续拦截很容易直接流失。所以对疑似风险请求不一定要直接拦截。更好的方式是分级处置。低风险请求直接放行中风险请求增加轻量验证比如图形验证码或冷却时间高风险但不确定的请求增加强验证比如上行短信、人脸识别、实名校验已确认风险请求再直接拦截。上行短信是一个特别值得重视的能力。所谓上行短信就是用户主动发送指定内容到指定号码系统收到后完成验证。它本身不复杂但在实践中并不是所有短信供应商都能稳定支持上行能力而且接入、解析、回调、状态同步都需要额外建设。为什么它有效因为它把验证动作从“企业给用户发短信”变成“用户主动发短信给企业”。对正常用户来说虽然多了一步但能完成对批量盗刷来说成本会明显上升。尤其在疑似风险但不敢直接拦截的场景上行短信是一个不错的中间态。扫脸、人脸识别、实名校验也属于强验证手段但要谨慎使用。它们的验证强度高用户打扰也高不适合放在短信发送前的常规链路里。更合理的触发场景是高价值账号、疑似批量设备、异常领取权益、异常充值返利、账号找回等风险更高的业务节点。把这些动作放在一起看可以整理成一张风险分级处置矩阵。它的价值不是给所有业务一个固定答案而是帮助产品、风控、研发和客服对齐“什么情况该怎么处理”。这里有个产品细节强验证的提示文案要解释清楚。不要只弹一句“请求异常”可以写成“当前环境存在安全风险为保护账号安全请完成验证后继续”。这类文案不是为了好看而是为了减少用户的不确定感和客服压力。分级处置层的本质是把风险决策从“是/否”变成“放行/观察/验证/拦截”。这会让系统更复杂但也更符合真实业务。六、落地时要补齐三套后台能力如果要把短信风控真正跑起来前台策略只是其中一部分后台能力更重要。第一套是规则配置后台。产品和风控同学需要能按业务场景配置规则比如注册、登录、换绑、找回密码、领取礼包分别使用不同阈值。不要把所有场景套一套规则注册场景可以更严格登录场景要更重视老用户体验找回密码则要更重视账号安全。规则配置后台最小要支持“业务场景、统计维度、时间窗口、处置动作”四类配置。配置粒度太粗规则会互相误伤配置粒度太细又会难以维护。比较稳妥的方式是先搭一个能覆盖 80% 场景的基础模型。第二套是监控看板。短信风控必须看数据至少包括发送请求量、发送成功率、验证码提交率、注册转化率、拦截量、强验证通过率、短信成本、供应商失败率、投诉量、签名状态等。只看拦截量没有意义拦截量升高可能代表风控有效也可能代表正常用户被误伤。监控看板的核心不是把指标堆满而是同时回答三件事黑产有没有变多、正常用户有没有受伤、短信通道有没有变差。第三套是应急开关。短信通道一旦异常影响会非常快。比如某个供应商失败率升高要能快速切换通道某个规则误伤要能快速降级某个签名投诉异常要能暂停对应场景或切换备用签名。没有应急开关风控系统本身也会变成风险源。我个人建议每一条核心规则都至少配三样东西命中原因、处置结果、回滚方式。命中原因用于排查处置结果用于复盘回滚方式用于止损。还有一个容易被忽略的点短信风控需要和客服对齐。用户收不到验证码时第一反应通常是找客服。如果客服后台看不到用户为什么被拦截只能回复“请稍后再试”体验会非常差。七、几个容易踩的坑第一个坑是把短信成本当成唯一目标。短信确实有成本但短信风控不是省钱项目。它的核心价值是保护账号体系、保护通道稳定性、保护正常用户体验。如果只盯着短信费用很容易把规则收得过紧最后省了短信费丢了注册转化。第二个坑是只做发送频控不做提交校验。短信发出去以后验证码是否提交、提交是否成功、多久提交、失败几次都是重要信号。只管发送不管提交就像只看门口排队不看进店以后发生了什么。第三个坑是规则没有分场景。注册、登录、换绑、找回密码、支付确认的风险完全不同规则必须和业务语义绑定。第四个坑是黑名单只进不出。风控名单不是垃圾桶不能什么都往里扔。没有过期、没有降级、没有复核时间久了必然误伤。第五个坑是把图形验证码当万能药。验证码能提高攻击成本但也会提高用户成本。它应该是动态策略的一部分而不是所有用户都必须跨过的一堵墙。八、写在最后短信本身是个很简单的服务生成验证码、调用供应商、用户收到、输入校验。简单到很多人会觉得这不就是一个接口吗但在真实业务里短信又一点都不简单。它连接着账号注册、用户体验、营销成本、通道稳定、投诉治理和黑灰产攻防。尤其在游戏这种高用户量、高利益密度的行业里短信入口做不好后面会牵出一串问题。我理解的短信防控不是单纯把黑产挡在门外而是建立一套可持续的平衡机制前面用成本门槛层挡住明显异常中间用行为识别层判断复杂风险后面用分级处置层减少误伤。再配合规则后台、监控看板、应急开关和客服可解释能力整个体系才算真正能跑起来。回到开头说的 vibe coding。AI 可以很快帮你做出一个登录框但登录框之下的业务不会因为页面生成得快就自动消失。短信风控就是这类“看起来不起眼但出了事很疼”的底层能力。产品经理真正要补的往往不是某个按钮怎么画而是按钮按下去之后系统如何判断、如何保护、如何兜底。短信验证码只有 6 位但它背后的产品设计远不止 6 位。