limit_req_zone是Nginx原生命令，仅在单机内存中维护计数器，无法跨节点同步状态，故不支持千万级IP的分布式精准限速；必须结合Nginx本地预判与Redis等分布式存储实现全局一致性控制。
limit_req_zone 是 Nginx 原生命令，用于在单机反向代理层实现基于变量（如 $binary_remote_addr）的请求速率限制。但它本身不具备分布式能力——它只在当前 Nginx 实例内存中维护计数器，无法跨节点同步状态。因此，直接用 limit_req_zone 管理“千万级 IP”的精准限速，在分布式架构下会失效：不同 IP 请求落到不同 Nginx 实例时，各自独立计数，全局总量不可控，极易绕过限流。
要真正支撑千万级 IP 的分布式、精准、低延迟限速，必须跳出 limit_req_zone 的单机模型，构建分层协同架构。核心思路是：用 Nginx 做本地快速拦截 + 用分布式存储做全局一致性校验与兜底。
以下为可落地的关键设计要点：
一、Nginx 层仅作“轻量预判”，不承担精准统计
避免将 limit_req_zone 当作唯一限流依据。可配置极宽松的本地限速（如每秒 50 请求），用于拦截明显异常的瞬时毛刺或扫描行为，降低后端压力。
- 使用
limit_req_zone $binary_remote_addr zone=ip_limit:100m rate=50r/s - 配合
burst=100 nodelay允许短时突发，但不累积长期额度 - 此层目标不是“精准”，而是“快筛”——99% 的恶意扫请求在此被挡下，不进业务集群
二、IP 维度限速必须下沉到统一控制面
千万级 IP 意味着需支持亿级 key 存储（考虑 IPv4/IPv6 + 时间窗口维度）。此时应选用高性能、高并发、支持 TTL 的分布式 KV 存储：
-
Redis Cluster 是主流选择：单集群轻松支撑 50 万+ QPS，通过
INCR+EXPIRE或Lua脚本实现原子计数 -
Key 设计示例：
ip:20260430:192.168.1.100（按天分片）或ip:1h:2026043014:192.168.1.100（按小时滚动） -
避免热点 key：对高频 IP（如 CDN 回源出口），加随机盐（如
ip:192.168.1.100:rand123）再哈希分片
三、采用“滑动窗口 + 本地缓存”平衡精度与性能
单纯固定窗口（如每分钟计数）存在临界突刺；纯滑动窗口（如 Redis ZSET 存每毫秒请求时间戳）内存开销大。推荐混合策略：
- 后端服务在每次请求时，向 Redis 查询该 IP 在最近 60 秒内的请求数（使用
ZCOUNT+ZREMRANGEBYSCORE清理过期项） - 同时在应用进程内维护一个 LRU 缓存（如 Caffeine），缓存最近 10 万 IP 的 60 秒计数，TTL 设为 10 秒
- 缓存命中则直接判断，未命中才查 Redis —— 实测可降低 70%+ Redis 调用量
四、应对海量 IP 的内存优化关键点
-
不用
$remote_addr，改用$binary_remote_addr：IPv4 地址从 15 字节压缩为 4 字节，IPv6 从 39 字节压缩为 16 字节，节省 60%+ 内存 -
禁用
limit_req_log_level的 warn 级别日志：千万级流量下，每条限流日志都是 I/O 瓶颈，仅在 debug 模式开启 -
Zone 大小按实际 IP 数预估：
100mzone 约支持 160 万个独立 IP（Nginx 默认每个 key 占约 64 字节），千万 IP 至少需600m以上，且需确保 Nginx worker 进程有足够内存锁
真正扛住千万级 IP 限速，靠的不是调大 limit_req_zone 的内存，而是把“精准性”交给后端统一控制面，把“低延迟响应”留给 Nginx 本地快速路径，二者各司其职。单靠 Nginx 配置，永远无法解决分布式一致性问题。
