使用防火墙或WAF时IP访问频率限制的最佳实践是什么？

IP 频率限制（Rate Limiting）不是简单的“加个规则”就完事了，它是攻防博弈中最基础也最容易被玩坏的一环。很多运维朋友要么设得太松导致被扫库，要么设得太紧导致正常用户误伤。

作为在一线扛过流量洪峰的人，我直接说干货。最佳实践的核心逻辑只有三点：分层防御、动态调整、上下文感知。

1. 不要只盯着 IP，要区分“会话”与“行为”

新手最容易犯的错误是：全局统一限制，比如“每秒最多 10 次请求”。

错误场景：
一个正常的用户刷新页面，或者一个 API 调用者并发发起请求，瞬间触发阈值，直接封禁。而攻击者可能通过分布式僵尸网络，每个 IP 只发 5 次请求，完美绕过。

最佳实践：

• 按接口差异化限流：登录接口、支付接口、搜索接口的阈值必须不同。登录接口可以严（如 5次/分钟），首页加载可以宽（如 100次/秒）。
• 基于 Token Bucket（令牌桶）或 Leaky Bucket（漏桶算法）：这是工业界标准做法。不要只用简单的计数器。令牌桶允许突发流量，但会平滑长期速率；漏桶则强制匀速处理。对于 WAF 来说，通常推荐滑动窗口计数器，精度更高。
• 身份维度的限流：如果用户已登录，限制应基于 User_ID 或 Session_ID，而不是纯 IP。未登录用户才严格限制 IP。

2. 分级响应，别一上来就封 IP

直接返回 403 Forbidden 并封禁 IP 是最粗暴的做法，体验极差，且容易引发 DDoS 放大效应（攻击者故意触发你的限流，让你去处理大量无效日志）。

最佳实践：阶梯式惩罚机制

关键点：L2 和 L3 是用户体验和安全性平衡的关键。不要跳过验证码直接封 IP，除非你确定那是恶意扫描。

3. 精准识别“真实 IP”，避免被X_X池绕过

WAF 和防火墙拿到的 client_ip 很可能是 CDN 节点或负载均衡器的 IP，而不是最终用户的 IP。

最佳实践：

• 信任链配置：确保你的应用/Web 服务器正确解析 X-Forwarded-For、X-Real-IP 等头部字段。
• IP 信誉库联动：结合第三方威胁情报（如 AbuseIPDB、阿里云盾、Cloudflare Radar），对已知数据中心 IP、Tor 出口节点、高危国家 IP 默认设置更严格的限流策略。
• 指纹识别：除了 IP，还要结合 User-Agent、TLS Fingerprint（JA3）、HTTP Header 特征 进行多维判断。同一个 IP，不同 UA 可能是不同的人。

4. 动态基线，拒绝“一刀切”

静态阈值（如“每分钟 100 次”）无法适应业务波动。大促期间流量自然上涨，夜间流量低谷期同样 100 次可能就是爬虫。

最佳实践：

• 学习期建模：系统运行 7-14 天，收集各接口的正常流量分布，建立基线（Baseline）。
• 自适应阈值：使用统计模型（如均值+3倍标准差）动态计算阈值。例如：“当前每小时流量比过去一周同期平均高 50%，且来自新 IP，则触发限流”。
• A/B 测试限流策略：先对小部分流量开启更严格的限流，观察错误率和投诉率，再全量推广。

5. 可观测性与快速回滚

限流策略一旦出错，可能导致全站不可用或大规模用户投诉。

最佳实践：

• 实时监控看板：必须实时展示：
  • 各接口的 QPS
  • 被限流的请求占比
  • 被封禁的 IP Top N
  • 429 错误码分布
• 灰度发布限流规则：先在测试环境验证，再在生产环境小范围（如 1% 流量）生效。
• 一键降级开关：当限流策略误伤正常业务时，必须有快速关闭或放宽限制的通道，最好是通过配置中心（如 Nacos, Apollo）热更新，无需重启服务。

6. 特殊场景处理

• API 网关层 vs WAF 层：

  • WAF 层：侧重防护 CC 攻击、SQL 注入、XSS，限流粒度较粗，主要防恶意扫描。
  • API 网关/应用层：侧重业务逻辑保护，限流粒度细，可按用户、按租户、按方法限流。
  • 建议：两者配合。WAF 做第一道防线，过滤明显恶意流量；网关做第二道防线，保障业务公平性。

• 合法爬虫处理：

  • 为百度、Google 等搜索引擎爬虫提供白名单或宽松限流策略，避免因限流影响 SEO。
  • 通过 robots.txt 引导爬虫，而非单纯依赖 IP 限流。

总结 checklist

1. 是否区分了登录/非登录状态？
2. 是否使用了阶梯式响应（延迟->验证码->封禁）？
3. 是否正确获取了用户真实 IP？
4. 是否有动态基线，而非固定阈值？
5. 是否有实时监控和快速回滚机制？

记住，限流的目的是保护资源，不是制造障碍。最好的限流是让正常用户无感，让攻击者寸步难行。