现象：接口调用量突然翻了几倍，服务器负载升高，账单也在涨，但真实用户数并没有变化。限流能顶一时，可对方换个 IP 段、放慢频率就又回来了。以下是社区整理的分层应对思路，核心是「提高攻击成本」而不是「彻底封死」。
第一步：先看清流量的样子
盲目加规则很容易误伤正常用户。动手之前先做一次流量画像：
- 请求特征：来源 IP 分布是否异常集中或异常分散、User-Agent 是否雷同或缺失、请求头是否缺少浏览器应有的字段。
- 行为特征：访问路径是否只集中在少数几个接口、请求间隔是否过于规律、是否只取数据从不触发正常用户会做的其他操作。
- 时间特征：是否集中在固定时段、是否与业务高峰完全无关。
- 身份特征：未登录流量占比、同一账号的请求频次、注册与登录接口的异常增长。
把这些特征记下来，后面的规则才有依据，也才能在误伤时快速回退。
第二步：在边缘拦，别让流量打到源站
源站直接暴露公网时，所有流量都要自己扛，这是最不利的局面。优先做的几件事：
- 静态资源上 CDN：把图片、脚本、样式与可缓存的接口响应放到边缘，既降低源站压力，也大幅减少被刷带来的带宽成本。
- 源站只接受边缘回源：配置访问控制，让源站只处理来自 CDN 或负载均衡的请求，直接访问源站地址的请求一律拒绝。
- 启用 Web 应用防火墙：对已知的爬虫特征、异常频率、常见攻击载荷做拦截；新规则先用观察模式跑一段时间，确认不误伤再切拦截。
- 人机校验：对高风险接口在触发阈值后加入验证环节，把自动化脚本的成本抬高一个量级。校验方式要平衡安全性与真实用户体验。
第三步：身份与频控要分层设计
单一维度的限流很容易被绕过，需要多个维度叠加：
- 按 IP：限制单 IP 的短时与长时请求量，注意区分企业出口与真实个人用户，避免误伤同一网络下的大量正常访问。
- 按账号：登录后按用户维度限制，能防止对方用大量 IP 轮换但账号数有限的攻击方式。
- 按设备与会话：结合会话标识、令牌有效期与请求签名，识别批量注册与脚本会话。
- 按接口重要度：核心数据接口设置更严格的阈值，公开内容接口可以放宽，把防护资源用在刀刃上。
阈值不要拍脑袋定，先用监控统计正常用户的请求分布，把阈值设在明显高于正常分位的位置，再逐步收紧。
第四步：数据与业务层加固
- 收敛可遍历性：自增 ID 的资源最容易被批量爬取，改用不可预测的标识可以显著增加遍历成本。
- 限制返回粒度：列表接口只返回必要字段，不一次性暴露全量数据；分页深度设上限，避免通过深翻页批量导出。
- 接口鉴权：所有返回业务数据的接口都要求有效凭证，匿名可访问的接口范围尽量小。
- 敏感操作二次确认：涉及资金、隐私信息、批量导出的操作增加验证与审计，即使被爬取也不至于造成严重后果。
- 水印与溯源：对外发布的数据可以加入不影响使用的标记，一旦发现被搬运，能判断泄露来源。
第五步：建立长期机制
对抗是持续的，一次性整改撑不了多久。建议固定做这几件事：把接口调用量、异常状态码、单 IP 请求排行纳入日常看板并设告警；定期复盘拦截规则的命中与误伤情况，清理过时规则；对新增接口在设计阶段就考虑频控与鉴权，而不是上线后被刷了再补；保留完整的访问日志，便于事后取证与规则调优。
几个容易踩的坑
- 把限流阈值设得过低，正常用户在高峰时段被误拦，投诉比爬虫还多。
- 只在应用层做限流，流量已经打到源站，带宽和计算成本照样产生。
- 规则写死在代码里，调整一次就要发布一次，响应速度跟不上对方变化。
- 只看拦截数量不看业务指标，误伤了转化却没人发现。
小结：反爬与防刷没有一劳永逸的方案，思路是提高对方成本、降低自己损失。边缘拦一层、身份频控一层、数据加固一层，再加上持续的观测与规则迭代，才能把影响控制在可接受范围内。涉及安全防护产品的能力与费用，以实际方案与报价为准。
把云上安全纵深防御交给更专业的协作方
安徽卓牛为客户提供云上的安全加固、监控体系搭建与运维托管服务，能够结合阿里云的安全防护、CDN 与可观测产品，帮助团队建立可持续的防护体系，而非一次性整改。若你希望就当前的接口安全问题做一次现状评估，可通过官网在线客服联系安徽卓牛，获取针对性建议。
#反爬虫#接口安全#限流#WAF#风控