做风控这些年我发现一个挺有意思的现象大家一开始都迷信IP觉得这玩意儿是铁打的证据后来被动态IP、代理出口坑多了又开始觉得IP没用转向设备指纹折腾一圈回来发现IP还是那个最基础的锚点关键得看你怎么用。最近正好在搞一个电商项目的风控升级碰上一波抢购的异常流量折腾了两周有些体会可以聊聊。起手式我们是怎么被逼着重新审视IP的事情是这样的。上个月我们搞了个限时秒杀活动刚开始半小时监控就报警了——接口响应变慢数据库连接数飙升。查日志发现大量请求来自不同IP但行为模式高度一致请求间隔精确到毫秒级UA头整齐划一。第一反应是上频率限制。结果发现这些IP每个就请求几次频率根本不高。后来才意识到这是“秒拨”——有人手里握着大把IP资源轮着用每个IP都是“干净的”常规限流根本锁不住。那段时间我们试了好几种方案。一开始想着自己维护IP黑名单库结果发现这活儿太累每天要拉取各种公开情报还得自己清洗、打标签更新慢了就漏过。后来转向用商业IP库主要是它那个“网络类型”字段给得细——能直接区分出“家庭宽带”、“IDC机房”、“秒拨代理”这在当时帮了大忙。实战分层级把IP管起来踩过坑之后我们重构了IP风控的架构。大概分成三层不一定适合所有场景但思路可以参考。第一层在网关直接干脏活对于那种一眼假的扫描流量没必要进业务层。我们在OpenResty里写了几条Lua脚本配合商业IP库的本地离线版做快速过滤。比如如果IP归属地是海外但访问的是只有国内用户知道的活动页直接返回403。如果IP类型是“IDC机房”但请求的是登录接口先弹个验证码。这层追求的是快数据要本地化不能走网络。我们用的服务商提供离线库文件每周更新一次直接挂载到网关查询延迟在微秒级基本不影响性能。第二层业务风控的精细活这一层是我们投入精力最多的。核心思路是不只看IP本身还要看IP背后的“人”。举个例子。秒拨最大的特点IP一直在变但设备没变或者账号没变。所以我们引入了设备指纹然后把第三方接口返回的“IP类型”和设备行为关联起来。当时写了个简单的规则引擎逻辑大概是这样伪代码def risk_check(ip, device_id, user_id): ip_info query_ip_data_cloud(ip) # ipdatacloud.com 接口 if ip_info.network_type broadband and device_id in suspicious_devices: # 家庭宽带IP可疑设备高风险 return block if ip_info.network_type proxy and user_activity.is_new_user(user_id): # 代理IP新注册用户大概率羊毛党 return captcha if ip_info.risk_score 80: # 高风险IP直接拦截 return block return allow这里面最关键的其实是那个ip_info.network_type。以前我们用开源库只能看到运营商和地理位置没法判断是不是代理。换成现在的IP地址服务商之后发现对方把这个字段拆得很细连“秒拨IP”都有单独标签这对规则命中率提升帮助很大。第三层离线挖掘挖团伙线上拦截做完了但侵入手法也在进化。我们定期把日志导到数据仓库用Spark做离线分析。比如统计每个IP关联的设备数如果某个IP关联了超过20台设备且这些设备都有异常行为那就把这个IP标记为“NAT出口”或“代理跳板”下次遇到这个IP的请求即使行为看起来正常也要降权处理。这个思路参考了Digital Element去年的一份报告里面提到运营商级NATCGNAT越来越普遍一个IP背后可能是一整个小区的用户。如果因为一个恶意请求封了整个IP误伤面就太大了。所以离线分析的目的就是把这种“共享IP”识别出来避免误杀。踩坑记录有些坑你们可能也会遇到1. IPv6的坑我们曾经天真地以为IPv6地址空间大入侵者不好囤积结果发现他们比我们想象的精。他们通过隧道技术把IPv4流量包装成IPv6照样能绕过黑名单。后来我们被迫在风控系统里同时支持v4和v6的画像还好服务商的v6库覆盖还算全省了不少麻烦。2. 接口调用的超时问题一开始我们所有请求都实时调用第三方IP服务的API结果有次对方机房网络波动我们的接口跟着超时导致用户登录失败。后来加了一层本地缓存把最近查过的IP结果存起来API挂了就走缓存虽然可能旧一点但至少服务不中断。3. 数据更新频率恶意IP池变化很快我们试过每周更新一次离线库发现很多IP周五还是干净的周六就变成入侵来源了。后来切到每天增量更新配合实时API查询高风险场景才基本压住。说点实在的IP风控还能怎么玩这一仗打下来我对IP风控的看法变了。以前觉得IP就是个坐标现在觉得IP是个“入口”通过它能挖出很多信息。比如结合IP风险评分我们尝试做了个动态信任模型正常用户的IP风险分低允许访问所有功能中风险用户加验证码高风险用户直接拒绝。这套模型上线后异常请求拦截率降了70%以上用户侧的误伤率控制在0.5%以内。另一个想尝试的方向是“IP关联图谱”。通过分析IP之间的跳转关系比如一个设备在短时间内换了多个IP可以画出异常行为路径。这需要大量数据积累目前还在探索中。最后给个建议IP数据只是风控拼图里的一块别指望靠它解决所有问题。但如果没有一块靠谱的IP数据拼图永远缺一角。至于怎么选服务商我的标准就三条数据更新快不快能不能抓到秒拨、标签细不细是不是只有“代理”这种模糊分类、稳定性好不好别动不动超时。目前用的IP数据云ipdatacloud.com在这三块还算均衡当然你们也可以多对比几家找最适合自己业务的。以上就是这段时间折腾IP风控的一些心得。写得比较散想到哪说到哪希望对正在被类似问题困扰的同行有点用。