防刷防的是什么

"刷接口"的三种典型攻击:

薅羊毛:批量调用注册/领券接口,套取新人补贴

资源消耗:恶意高频调用计费接口,刷爆你的余额或服务器

数据爬取:枚举参数批量拉取接口数据

防刷的目标不是"全拦",而是让正常用户无感、让攻击者成本高于收益。

第一层:频率限制(最基础,必做)

按维度限流

维度典型配置防什么 按手机号验证码 1 分钟 1 条、1 天 10 条轰炸、骚扰 按用户 ID敏感接口 10 秒 1 次脚本批量操作 按 IP100 次/分钟单机攻击 按接口全局按 SLA 容量设阈值资源被打满

实现:滑动窗口 + Redis

import redis
r = redis.Redis()
def allow_request(key: str, limit: int, window_sec: int) -> bool:     """滑动窗口限流: window_sec 秒内最多 limit 次"""     pipe = r.pipeline()     now = int(time.time() * 1000)     member = f"{now}"     zset_key = f"rl:{key}"     pipe.zremrangebyscore(zset_key, 0, now - window_sec * 1000)     pipe.zadd(zset_key, {member: now})     pipe.zcard(zset_key)     pipe.expire(zset_key, window_sec)     _, _, count, _ = pipe.execute()     return count <= limit
用法: 同一手机号 60 秒内最多 1 条验证码
if not allow_request(f"sms:{phone}", limit=1, window_sec=60):     return {"code": 1109, "message": "发送过于频繁,请稍后再试"}

要点:限流返回码要友好(告诉用户"稍后再试"而不是"系统错误"),并加 Retry-After 头。

第二层:IP 白名单与黑名单

白名单:服务间调用的硬门槛

企业内部服务、支付回调这类调用方固定的接口,直接上 IP 白名单——白名单外一律拒绝,比任何算法都可靠。

主流 API 平台(包括诺正通)都支持在控制台绑定调用 IP,签名密钥泄露了,攻击者不在白名单内也调不通。

黑名单:动态封禁

单 IP 触发限流 N 次 → 自动拉黑 24 小时

命中威胁情报库的 IP(代理池、IDC 段)→ 预拦截或加验证

分布式攻击(低频多 IP)→ 按设备指纹聚合识别

第三层:行为验证与业务风控

频率和 IP 都是"网络层"手段,高级攻击会绕过。最后防线在"业务层":

验证码接口的特殊防护

验证码接口是防刷重点(黑产用它做短信轰炸):

图形/行为验证前置:下发短信验证码前,先过一次滑块或点选验证

单手机号限额:1 分钟 1 条、1 小时 5 条、1 天 10 条

同 IP 限额:单 IP 每天发给不同手机号的上限(防轰炸代理池)

受益人分离:下发短信的成本是调用方的——用状态回执对账,失败不计费,发现异常量立即告警

业务信号风控

设备指纹:同一设备批量注册 → 拦

行为序列:注册到领券间隔 < 1 秒 → 疑似脚本

名单体系:手机号三要素核验不一致的账号,标记高风险

三层怎么组合

请求 → [L1 频率限制] → [L2 IP 名单] → [L3 行为验证/风控] → 业务逻辑
        拦掉 80% 脚本      拦掉固定源       拦掉拟人化攻击

原则:低成本手段放前面(频率/IP),高成本手段放后面(验证码/人工审核);每一层的拦截都要打日志,用于回归分析和误杀排查。

监控与告警

防刷不是配置完就结束:

量级突增告警:接口 QPS 超基线 3 倍 → 告警

失败率告警:验证码接口失败率 > 30% → 可能被轰炸

余额监控:计费接口日消耗超预算 → 立即暂停排查

定期演练:每季度做一次压测,确认限流阈值合理

关于诺正通

诺正通 API 平台内置三重防护:签名机制(mall_id + appkey 防冒用)、IP 白名单(控制台自助绑定)、频率限制(1109 错误码自动拦截超频调用)。配合短信状态回执与余额告警,把"被刷损失"控制在最小。100 次免费试用,具体价格请联系商务。

联系试用

试用入口:(100 次免费)

技术支持:service@nztapi.com