Appearance
活动秒杀被薅羊毛?IP维度风控这样设置
每次大促秒杀,都是羊毛党最兴奋的时候。你辛辛苦苦准备的限量福利,可能被脚本一秒钟扫光,真实用户啥都没抢到,回头还骂平台。
这篇讲讲,从IP维度怎么给活动做风控。这套东西我帮朋友做过好几次,效果立竿见影。
先看羊毛党怎么薅
- 注册一堆号:同一个IP批量注册,或者同一批IP段注册;
- 脚本抢购:毫秒级请求,人做不到那个速度;
- 换IP:高级一点的会用代理池,但代理IP的特征依然可疑(机房/数据中心)。
秒杀风控的IP三板斧
1. 同IP限购
最基础的一条:一个IP在活动期间最多下单N次。
python
from collections import defaultdict
import time
orders = defaultdict(list)
def can_order(ip, limit=1, window=3600):
now = time.time()
orders[ip] = [t for t in orders[ip] if now - t < window]
if len(orders[ip]) >= limit:
return False
orders[ip].append(now)
return True别小看这条,它能挡住最笨的"一个IP疯狂下单"型羊毛党。
2. 机房IP拦截
云服务器上跑的抢购脚本,IP全是机房类型。活动场景下,机房IP的"正常参与率"极低,可以果断处理:
python
def risk_check(info):
if not info:
return "unknown"
if info.get("ip_type") == "IDC":
return "high" # 机房IP,直接进验证
return "low"对"high"的,弹滑块验证码——脚本过不去,真人能过。别一棍子打死,弹验证码是最优雅的折中。
3. 注册-下单关联
把"注册时IP"和"下单时IP"关联起来看。正常用户注册和下单IP基本一致;羊毛党注册在机房、下单可能换了IP,或者反过来。
python
def order_risk(user):
reg_ip = user.register_ip
order_ip = user.order_ip
if reg_ip == order_ip and is_datacenter(reg_ip):
return "high" # 同一个机房IP注册又下单
return "low"秒杀场景的加分项:提前预热黑名单
别等秒杀开始才临时判断,那会儿流量洪峰,接口压力大。提前把疑似风险的IP拉个黑名单:
- 活动预热期,统计注册量异常的IP;
- 把之前活动里出现过的"薅羊毛IP"沉淀成名单;
- 秒杀开始时直接查名单,快速放行/拦截。
名单可以存Redis,秒杀时查一次毫秒级,不拖累主流程。
怎么做到"不误伤真用户"
活动风控最怕误伤——真用户没抢到,比羊毛党薅走还伤口碑。几点经验:
- 优先验证码,其次拦截:不确定的,弹验证码而不是直接拒绝;
- 手机用户放宽:移动网络IP飘,别因为IP变了就卡人;
- 留人工复核通道:被拦截的用户能申诉,客服能处理;
- 看综合分,别看单指标:IP只是其中一个维度,加上设备指纹、注册时间、行为,一起打分。
python
def final_score(ip_info, device_fp, register_age, click_speed):
score = 0
if ip_info and ip_info.get("ip_type") == "IDC":
score += 40
if device_fp and device_fp.get("is_emulator"):
score += 30
if register_age and register_age < 3600:
score += 20
if click_speed > 5: # 每秒点击超过5次
score += 10
return score
# >70 拦截;40-70 验证码;<40 放行落地顺序建议
- 先上同IP限购(最快、最简单);
- 再加机房IP验证码(拦脚本主力);
- 活动前沉淀黑名单(提性能);
- 最后上综合评分(提准确率)。
按这个顺序,一步步来,别一上来就搞复杂的模型。
用到的免费接口:https://www.ip9.com.cn