一个验证码背后的产品逻辑：短信风控全链路拆解

guozi

短信验证码看似简单的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 位。

作者：零度Pasca，公众号：进击的零度

本文由 @零度Pasca 原创发布于人人都是产品经理。未经作者许可，禁止转载

题图来自Unsplash，基于CC0协议

--------------------------------------------------
本文转载自：https://www.woshipm.com/pd/6415036.html