短信验证码接口被刷爆了，我们是怎么扛住的？

相信早期做过短信服务的程序员都有过一个共同的噩梦——验证码接口被恶意攻击。这篇文章就来分享一下我们刚接触短信服务时的验证码接口被恶意攻击的真实经历，以及我们是如何通过技术手段实现限流、防刷等一系列操作的过程。

首先，一起来回顾一下异常指标突然出现事故现场：

这是一个不能再普通的工作日，客服的同事向我们反映，客户不能正常使用验证码服务，页面卡在验证环节。基于程序员的警觉，我预感到有特殊情况发生。果不其然，短信验证码接口的请求数量暴增。初步排查发现，大量IP在频繁请求接口，手机号随机但访问行为高度相似，判断为典型的脚本刷接口。虽然经验不足，但我们也算是沉着冷静，先通过监控和日志排查流量异常来源，紧急启用IP限流。随后提取攻击特征，封禁高频IP或行为异常用户。一波操作过后，我们发现平台渐渐恢复了稳定，大家紧张的情绪才慢慢放松了下来。

为了防止这类事件的再次发生，我们立刻开会采取了一系列的措施：

第一步：接入层限流防刷

基于 Nginx + Redis + Lua 实现滑动窗口限流

1. 每个IP每分钟不得超过 X 次请求；
2. 每个手机号在5分钟内只能请求一次验证码；
3. 每个账号（或设备ID）单日限制调用次数；
4. 发现异常请求立刻记录并拉入黑名单。

技术要点：

使用 Redis 的 INCR + EXPIRE 组合做时间窗口计数；

提前加载高风险IP段（如IDC机房）做灰名单处理。

第二步：接口层幂等 + 验证码冷却机制

1. 每次验证码请求生成唯一的业务ID，进行幂等判断；
2. 若某手机号 2 分钟内已经下发成功，不重复发送，而是直接复用上一次验证码。

关注的要点：

验证码存入 Redis，设置合理 TTL（如1分钟）；

同一手机号短时间重复调用，返回 “验证码已下发，请稍后重试”。

第三步：通道层动态调度 + 熔断保护

1. 通道分流系统实时监控发送成功率、响应时间；
2. 当发现某通道出现大量失败/卡顿时，自动熔断该通道；
3. 低优先级通道/营销类通道立即限流甚至中断，优先保障验证码类业务。

注意点：

调度打分策略（成功率 + 回执时延）优先选择“快而稳”的通道；

针对特定业务（验证码）设置“保命通道”，仅服务于核心业务或客户。

第四步：行为识别 + 黑产规则提取

1. 调用日志实时入库 + Kafka推送至行为分析引擎；
2. 使用规则模型判定：
3. 短时间内高频请求多个手机号；
4. IP+UserAgent+参数组合重复度高；
5. 请求UA异常（如curl/无头浏览器）；

一旦命中规则，立即封禁IP/设备，并记录日志入侵处置中心。

注意点：

构建自定义规则引擎，与黑白名单动态组合；

建立高危IP库，与短信平台联动进行限流/熔断。

通过这次攻击事件，我们还是获得了蛮大的收获解决了很多我们之前忽略的一些隐患，为平台的平稳运行打下了基础，归纳起来有下面的几个问题点：

顺便附上验证码短信防刷架构图

随着我们对这个行业了解的加深，我们意识到免费的验证码短信往往会成为黑产攻击的目标。面对网络上的风险，我们必须要居安思危，防范于未然。