针对API接口的IP限流应该设置多大的时间窗口和请求数？

这个问题没有标准答案，因为“多少”完全取决于你的业务场景、接口类型以及你愿意承担的风险成本。在云原生和微服务架构下，IP限流（Rate Limiting）通常不是孤立存在的，而是配合令牌桶（Token Bucket）或漏桶（Leaky Bucket）算法一起使用的。

如果非要给一个“通用建议值”，对于大多数面向C端用户的Web API，1分钟/60次 或者 5分钟/300次 是比较常见的起步配置。但这只是起点，以下是我在实际生产环境（包括阿里云、腾讯云等主流云平台实践）中总结的分级策略和设置逻辑：

一、 核心原则：按接口敏感度分级

不要对所有接口使用同一套限流阈值。你需要将API分为三类：

1. 高频、低风险接口（如：首页加载、公共信息查询、状态查询）

• 特点：读多写少，幂等性高，即使被刷也不会造成数据错误，只会消耗带宽和计算资源。
• 推荐窗口与阈值：
  • 时间窗口：60秒（1分钟）
  • 请求数：100~200次/IP
  • 理由：正常用户滑动页面或刷新页面，一分钟几十次是合理的。设置太低会误伤正常用户，导致体验下降；设置太高则对恶意爬虫限制不足。

2. 中等风险接口（如：登录验证、验证码发送、搜索接口）

• 特点：涉及账号安全或资源消耗较大（如数据库复杂查询）。
• 推荐窗口与阈值：
  • 时间窗口：60秒（1分钟）
  • 请求数：10~30次/IP
  • 特殊处理：
    • 短信验证码：必须更严格，建议 60秒内1次，且 24小时内累计不超过5-10次。这个不能靠IP限流单独解决，必须结合手机号维度做全局限流。
    • 登录接口：建议 60秒内5次，连续失败3次后锁定IP或要求图形验证码。

3. 高风险、写操作接口（如：支付下单、修改密码、删除数据、批量导入）

• 特点：影响核心业务逻辑，可能造成资损或数据混乱。
• 推荐窗口与阈值：
  • 时间窗口：60秒（1分钟）
  • 请求数：1~5次/IP
  • 理由：这类接口通常有业务层面的防重放机制（如Nonce+Timestamp），IP限流作为第二道防线。如果允许单个IP在一分钟内发起多次相同操作，极易被脚本自动化攻击。

二、 技术实现中的关键考量

在实际落地时，单纯看“次数”是不够的，还需要注意以下几个工程细节：

1. 时间窗口的选择：滑动窗口 vs 固定窗口

• 固定窗口（如：每分钟重置一次计数器）：实现简单，但在窗口边界处可能出现流量突刺（Crash the server问题）。例如前59秒没请求，第60秒和第1秒同时涌入大量请求，瞬间压力翻倍。
• 滑动窗口（Sliding Window）：更平滑，推荐用于生产环境。大多数云厂商的网关（如阿里云ALB/Nginx插件、腾讯云CLB）默认支持滑动窗口算法。
• 建议：优先使用 滑动窗口，时间粒度可以细到秒级甚至毫秒级，但统计精度不宜过高，否则Redis或内存开销太大。

2. IP地址的获取陷阱

• 真实IP问题：经过CDN、WAF或负载均衡后，后端服务器拿到的往往是XX服务器的IP，而不是用户真实IP。
  • 解决方案：必须从HTTP Header中获取 X-Forwarded-For 或 X-Real-IP。注意，有些高级攻击者会伪造Header，所以需要结合客户端指纹（User-Agent + IP组合）或JS Challenge来识别机器人。
• 共享IP问题：企业出口、学校网络、运营商NAT环境下，成千上万的用户共享同一个公网IP。
  • 后果：如果你对该IP限流过严，会导致整个公司或小区的用户无法访问。
  • 对策：
    1. 区分内网络IP：对私有IP段（如10.x.x.x, 192.168.x.x）放宽限制或不限制。
    2. 动态调整：监控该IP下的错误率或异常行为，如果是合法流量但触发限流，可考虑加入白名单或临时提升配额。
    3. 使用设备指纹：对于极度重要的接口，IP限流不够精准，应结合Cookie或本地存储的设备ID进行限流。

3. 限流后的响应策略

• HTTP 429 Too Many Requests：标准做法。
• 重试机制：前端必须实现指数退避（Exponential Backoff）重试，而不是立即疯狂重试，否则会加剧DDoS效果。
• 友好提示：返回JSON中明确告知用户“请求过于频繁，请稍后再试”，并给出预估的重试时间（如 Retry-After: 60）。

三、 如何确定适合你的阈值？（实战方法论）

不要拍脑袋决定，通过以下步骤测算：

1. 基线测试：

   • 模拟正常用户行为，记录平均每秒请求数（RPS）和峰值RPS。
   • 例如：正常用户浏览商品列表，平均每人每分钟点击3次，峰值可能达到10次。

2. 压测找瓶颈：

   • 使用JMeter或Wrk对目标接口进行压测，找到系统能承受的极限QPS。
   • 假设单实例能承受1000 QPS，你有10个实例，总能力10000 QPS。
   • 如果预计在线用户1万，那么每个用户平均只能占用1 QPS。考虑到并发系数，你可能需要设置更严格的单IP限制。

3. 灰度观察：

   • 先设置一个较宽松的阈值（如正常值的2倍），运行一周。
   • 分析日志：是否有大量429错误？如果有，说明阈值过低，误伤了正常用户。
   • 是否有明显的异常流量模式（如某个IP在短时间内发起数千次请求）？如果有，说明阈值过高，需收紧。

4. 利用云厂商的安全产品：

   • 阿里云：推荐使用 WAF + DDoS防护 + API网关限流插件。WAF可以自动识别CC攻击，动态调整IP封禁策略。
   • 腾讯云：类似，依托于WAF和API网关的QPS控制功能。
   • 自建方案：如果使用Nginx，可使用 limit_req_zone；如果使用Spring Cloud Gateway，可使用Resilience4j或Sentinel，它们都支持基于IP的限流规则，并且可以动态热更新。

四、 总结建议

最后提醒：IP限流只是第一道防线。面对有组织的专业攻击，IP会被海量轮换（僵尸网络），此时必须引入行为分析、人机验证（滑块、点选）以及云盾/WAF的高级防护策略。不要过度依赖IP限流来解决所有安全问题。