API接口遭恶意请求刷量时的防护措施，不必一开始就堆叠复杂设备。先找出哪些接口会消耗计算、存储或第三方调用资源，再依次控制访问身份、请求速度和故障影响范围。下面五项适用于不同规模的服务，可按现有架构逐步实施。
1. 先盘点接口与资源成本
列出公开接口、登录后接口和内部接口，记录每个接口的调用者、认证方式、正常用途及主要成本。重点检查搜索、导出、图片处理、短信发送等可能触发较重计算或外部费用的操作；它们比读取缓存中的普通信息更需要严格保护。
为接口标注风险等级，并确认请求经过哪些环节，例如负载均衡器、API网关和应用服务。盘点的目的不是立刻封禁流量，而是知道异常请求可能消耗什么，以及哪个环节可以最早拦截。
2. 让请求身份可识别、权限可核验
对需要用户身份的接口，服务端应校验会话或访问令牌，并在每次请求时检查其权限；不要把前端隐藏按钮当作授权措施。服务间调用可使用独立凭据，按用途限制权限，避免多个服务共用一把长期有效的密钥。发现凭据泄露时，准备撤销和更换流程。
匿名接口也应区分可信客户端与未知流量，但不要只依赖 IP 地址：共享网络可能让许多正常用户共用出口，攻击者也可能更换来源。可结合账号、令牌、IP信誉和接口类型判断风险。
3. 在合适层级设置速率限制
在 API网关或服务入口实施速率限制，按用户、密钥、IP 地址和接口分别计量。普通查询与高成本操作应采用不同额度；必要时再加并发数限制，避免少量慢请求长期占满工作线程。
- 先观察一段正常业务周期的请求量，按接口和身份类别建立基线。
- 从高成本、易被滥用的接口开始设限，先记录超限事件，再逐步启用拒绝或延迟响应。
- 根据业务峰值调整短时突发额度与持续速率，并为可信内部调用设置独立规则。
固定窗口实现简单，但窗口边界可能出现短时流量集中；令牌桶允许有限突发，更适合有正常峰谷的请求。具体阈值需依据业务基线和容量测试确定，不宜照搬通用数字。限流返回明确的状态码和重试提示；对可安全重试的写操作，还可使用幂等键避免重复执行。
4. 监控异常，并保护后端资源
监控请求量之外，还要观察错误率、延迟、并发数、数据库连接、队列积压和外部服务调用量。按接口、身份和来源聚合数据，设置短时间内突增、失败率升高或资源耗尽的告警。单看总流量，容易漏掉针对一个昂贵接口的低速消耗。
对可缓存的公开读取结果设置合理缓存，对非实时任务采用队列处理，并为数据库和下游服务设置连接池、超时及并发上限。网页应用防火墙可以补充识别常见攻击特征，但不能替代身份校验、业务限流和后端容量保护。
5. 准备处置流程，避免临时误伤
预先明确谁负责确认告警、谁能调整规则，以及如何回滚。出现疑似刷量时，先按接口和身份核对日志，再选择缩紧单一路径的限流、暂停高成本功能或临时提高验证要求；不要未经核实就封掉整个来源网段，以免影响共享网络中的正常用户。
- 保存告警时间、请求特征、受影响接口和资源指标。
- 先实施范围最小的临时措施，并观察正常请求是否恢复。
- 事件结束后复盘规则是否误拦截，补充自动告警、限流测试和凭据轮换记录。
常见问题
只按 IP 限流够不够？
通常不够。共享出口会误伤正常用户，来源地址变化也会削弱限制效果，应结合账号、令牌和接口维度。
所有接口都要设置同一额度吗？
不建议。读取缓存的接口与导出、搜索等高成本操作负载不同，应按资源消耗和正常调用模式分别设置。
什么时候需要升级防护？
如果入口限流后后端仍持续过载，或攻击流量已挤占网络与边缘资源，应与基础设施服务方协同处置，并检查容量和流量清洗能力。
从盘点高成本接口开始，逐项补齐身份校验、分层速率限制、监控和应急流程，才能让API接口遭恶意请求刷量时的防护措施既能拦截异常，也尽量不影响正常调用。