做风控这些年，我发现一个挺有意思的现象：大家一开始都迷信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”都有单独标签，这对规则命中率提升帮助很大。
第三层：离线挖掘，挖团伙
线上拦截做完了，但侵入手法也在进化。我们定期把日志导到数据仓库，用Spark做离线分析。比如：统计每个IP关联的设备数，如果某个IP关联了超过20台设备，且这些设备都有异常行为，那就把这个IP标记为“NAT出口”或“代理跳板”，下次遇到这个IP的请求，即使行为看起来正常，也要降权处理。
这个思路参考了Digital Element去年的一份报告，里面提到运营商级NAT（CGNAT）越来越普遍，一个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数据云在这三块还算均衡，当然你们也可以多对比几家，找最适合自己业务的。
以上，就是这段时间折腾IP风控的一些心得。写得比较散，想到哪说到哪，希望对正在被类似问题困扰的同行有点用。
