接口高频请求攻击本质上是CC攻击在API场景下的变种，它不追求打满带宽，而是用大量看似合法的请求精准消耗接口背后的计算、数据库连接、内存和业务逻辑资源。很多防御方案失败，是因为只关注了“请求次数”，没有关注“请求代价”和“业务状态”。一个查询接口如果每次请求都触发复杂SQL、缓存穿透或第三方调用，攻击者只需要每秒几十个请求就能把服务拖垮。因此，防御方案必须从入口限流、行为识别、资源隔离、业务降级四个层面同时下手。
先区分攻击目标：高频调用和慢接口叠加
高频请求攻击最常见的形态有两种。第一种是攻击者直接对某个轻量接口发起每秒数千甚至上万次请求，试图消耗连接数和CPU。第二种更隐蔽，攻击者专门挑选那些响应慢、计算重的接口，例如搜索、报表导出、复杂筛选、短信发送、验证码校验等，用相对较低的频率反复触发。第二种往往比第一种更危险，因为单次请求成本高，服务端容易在短时间内耗尽线程池或数据库连接池。防御的第一步不是盲目加限流，而是先梳理接口清单，标记出每个接口的“单次请求资源成本”和“是否可缓存”。没有这个基础，任何限流阈值都是拍脑袋。
入口层：多级限流比单级限流有效得多
很多人一提到限流就想到Nginx的limit_req模块，但单层限流在高频攻击下很容易误伤正常用户，或者被攻击者用分布式IP绕过。正确的做法是建立“网关级—应用级—业务级”三级限流。网关级负责粗粒度拦截，例如单个IP每秒超过200次请求直接拒绝；应用级基于用户ID、设备指纹、会话Token做精确限制，例如同一用户每分钟最多调用某个接口30次；业务级则针对具体操作做语义限制，例如同一手机号每分钟只能发一次验证码。三层之间互相独立又互相兜底，即使攻击者更换IP，也会在应用级被识别出来。
在Nginx层面，除了limit_req，还可以配合limit_conn限制并发连接数。但要注意，limit_req默认是基于“漏斗算法”平滑处理突发流量，对于攻击性的突发高频，建议设置较低的burst值，并配合nodelay参数让超出的请求立即返回503，而不是排队等待。下面是一个基础配置示例：
http {
limit_req_zone $binary_remote_addr zone=api_zone:10m rate=50r/s;
limit_conn_zone $binary_remote_addr zone=conn_zone:10m;
server {
location /api/ {
limit_req zone=api_zone burst=20 nodelay;
limit_conn conn_zone 10;
proxy_pass http://backend;
}
}
}
这段配置将每个IP的请求速率限制在每秒50次，突发最多20次，超过立即拒绝，同时限制每个IP的并发连接数为10。对于大多数公开API来说，这是一个相对安全的起点。但如果是登录、支付等敏感接口，阈值需要进一步收紧。
行为识别：不能只数请求次数，要看请求模式
高频攻击的另一个特点是请求模式异常。正常用户的请求间隔往往不均匀，会有思考时间、页面停留时间，而攻击脚本的请求间隔高度一致，或者呈现明显的周期性。因此，在应用层可以引入滑动窗口计数和标准差分析。例如，统计一个IP在60秒内的请求间隔，如果间隔的标准差极小，说明很可能是脚本。此外，还要关注请求头特征，攻击脚本常常缺失Referer、使用固定User-Agent、不带正常的Cookie或Accept-Language。将这些特征组合成评分系统，比单纯计数更准确。
一个实用的做法是在网关层或应用中间件中维护一个轻量级的行为画像。对于每个来源IP或设备指纹，记录最近100次请求的时间戳和接口路径。如果发现某个来源在短时间内反复请求同一个接口，且请求参数高度相似，或者请求路径集中在少数几个高成本接口上，就触发动态限制。动态限制不是永久封禁，而是先降级为“观察模式”，要求客户端完成验证码或返回带有退避时间的429响应。这样既能拦截攻击，又不会把误判用户一棍子打死。
资源隔离：别让一个接口的过载拖垮整个服务
很多系统在遭受接口高频攻击时，最先崩溃的不是被攻击的接口本身，而是数据库连接池、线程池或内存。因为所有接口共享同一个后端资源池，一个接口的请求量暴增会迅速占满连接，导致其他正常接口也无法使用。解决这个问题必须做资源隔离。在Java体系中，可以使用Hystrix或Sentinel为不同接口配置独立的线程池和熔断策略；在微服务架构中，可以为高成本接口单独部署服务实例，或者使用消息队列削峰填谷。数据库层面，可以为不同业务配置不同的连接池，或者使用读写分离、缓存前置来降低数据库压力。
缓存是防御高频请求最直接有效的手段之一。对于查询类接口，如果数据变化不频繁，可以在网关层或应用层设置短时间缓存，例如5到30秒。这样即使攻击者疯狂请求，大部分请求也会命中缓存，不会穿透到数据库。但要注意缓存穿透问题，攻击者可能会故意请求不存在的ID，导致每次请求都查询数据库。解决方法是缓存空值，或者使用布隆过滤器快速判断ID是否存在。
业务降级：关键时刻保住核心功能
当攻击流量超出防御能力时，必须有一套自动化的降级机制。降级不是简单返回错误，而是有策略地牺牲非核心功能。例如，在攻击期间，可以暂时关闭搜索建议、热门推荐、用户行为统计等非关键接口，把资源留给登录、下单、支付等核心链路。降级开关可以基于系统负载自动触发，例如当CPU使用率超过85%或数据库连接池使用率超过90%时，自动关闭标记为“可降级”的接口。这个机制需要提前在代码中埋好开关，而不是等出事后再临时改代码。
另一个容易被忽视的降级点是验证码和风控系统。很多网站在遭遇CC攻击时，会立即对可疑流量弹出验证码。但如果验证码服务本身也部署在同一个后端集群中，攻击者可能同时打挂验证码接口，导致正常用户也无法完成验证。因此，验证码服务应该独立部署，并且具备高可用能力。在极端情况下，可以暂时放行已登录用户的请求，只对匿名流量进行验证，这样能保住核心用户的使用体验。
针对分布式攻击：IP封禁的局限与应对
高频请求攻击很少来自单一IP，攻击者通常使用代理池、僵尸网络或云主机集群。因此，单纯基于IP的封禁效果有限。更有效的做法是结合设备指纹和账号体系。设备指纹可以通过前端JavaScript采集浏览器Canvas、WebGL、字体、时区等信息生成唯一标识，即使攻击者更换IP，只要设备指纹相同，依然可以被识别。对于已登录用户，可以基于用户ID做限流和风控。攻击者如果使用大量注册账号发起攻击，就需要配合注册风控、实名认证、行为分析等手段提高攻击成本。
在网关层，可以使用基于Cookie或Header的会话追踪。对于没有携带有效会话的请求，直接进入更严格的限流通道。对于携带有效会话但行为异常的请求，可以标记为风险会话，限制其访问高成本接口。这种“先验证身份，再分配资源”的策略，能显著降低匿名攻击的杀伤力。
日志与监控：没有数据就无法判断防御效果
防御方案上线后，必须持续监控关键指标。需要关注的指标包括：每个接口的QPS、平均响应时间、错误率、数据库连接池使用率、缓存命中率、限流触发次数、封禁IP数量等。当限流触发次数突然飙升时，说明可能正在遭受攻击；当缓存命中率下降时，说明攻击者可能在尝试绕过缓存。日志方面，建议记录每个请求的来源IP、设备指纹、用户ID、接口路径、响应状态码和耗时。这些数据不仅是事后分析攻击源头的依据，也是优化限流阈值和降级策略的基础。
一个常见的误区是只看总QPS。总QPS看起来不高，但某个高成本接口的QPS可能已经接近极限。因此，监控必须细化到接口级别，并且对高成本接口设置独立的告警阈值。当某个接口的响应时间突然从50毫秒上升到500毫秒，即使QPS没有明显变化，也可能是攻击者正在用慢查询消耗资源。
总结：防御是一个动态调整的过程
接口高频请求攻击的防御没有一劳永逸的方案。攻击者会不断变化请求模式、更换IP、模拟正常用户行为。因此，防御体系必须具备动态调整能力。限流阈值需要根据实际业务流量定期校准，行为识别模型需要根据新的攻击样本持续优化，降级开关需要定期演练确保可用。更重要的是，开发团队在设计和实现接口时，就应该考虑单次请求的成本，避免出现“一个请求拖垮整个系统”的脆弱设计。把防御前置到开发阶段，比事后补救要有效得多。
