limit_req_zone 限制单位时间内同一 key 的请求频次，非并发连接数；内存消耗取决于活跃限流键数量而非总 IP 数，需通过聚合 key、分层 zone 和跳过低价值流量来优化，如按国家码聚合仅需 10MB。

直接用 limit_req_zone 支持“千万级缓存并发”是个常见误解——它不处理缓存，也不面向“并发连接数”，而是限制**单位时间内同一 key 的请求频次**。所谓“千万级缓存并发”，实际想表达的是：在千万级 IP 或用户量级的业务场景下，如何让限流机制稳定、精准、不崩盘。核心不是堆内存，而是压缩状态维度、分层控制、协同外部系统。

别算“并发连接”，算“活跃限流键数量”

限流内存消耗取决于 同时需要被记住的 key 数量，不是总 IP 数或 QPS。每个 key（如一个 IP、一个用户 ID、一个国家码）在共享内存中占约 64 字节：

• 100 万个活跃 key → 约 64 MB
• 1000 万个活跃 key → 约 640 MB（远超常规 Nginx 实例内存上限）
• 若用 $remote_addr 文本形式，还会额外多占 15%～20% 内存

所以第一步是明确：你真正需要长期跟踪的“活跃限流单元”有多少？是全部 IP？还是登录用户？还是异常 UA 组合？答案几乎从来不是“一千万个独立 IP”。

用聚合 key 替代单 IP 记录

把千万级原始输入，映射为几百到几千个高价值逻辑单元：

• 按地域聚合：key $geoip2_country_code → 全球 200+ 国家，10MB 就够
• 按网段粗略归并：key $binary_remote_addr 改为 key ${remote_addr%.*.*}（需配合 map 指令提取前两段）
• 对 CDN 流量：key "$http_x_forwarded_for.$server_name"，把同一源站 + 同一客户视为一个单元
• 对已登录用户：key $http_x_user_id，真实用户数通常远低于 IP 总量

分 zone 分层，让内存各干各的事

不指望一个 zone 扛全部压力，而是按风险等级和行为粒度拆开：

• zone=burst_api:5m rate=100r/s：突发接口兜底，只留活跃 IP（60 秒无访问即淘汰）
• zone=login_strict:2m rate=3r/m：登录页严控，key 用 $binary_remote_addr$http_user_agent 防轮换爆破
• zone=user_action:8m rate=20r/s：用户行为层，key 是 $http_x_user_id，覆盖核心用户群

三者加起来 15MB 内存，却比单个 100MB 的 per-IP zone 更有效、更可控。

跳过低价值流量，释放内存给关键路径

不是所有请求都值得记状态。用 map 指令把确定安全的流量映射为空 key：

• CN2/阿里云回源 IP、健康检查探针、内部服务调用 → key 设为 ""，完全不进限流区
• 静态资源路径（/static/、/healthz）不套 limit_req
• 只在 /login、/api/submit、/pay 等敏感路径上启用限流

这样，内存只服务于真正需要防护的请求，而不是为爬虫、监控、CDN 填充无效槽位。