limit_req_zone 不支持百万级并发，仅支持百万级活跃状态数；关键在压缩有效key数量，如按网段聚合、敏感路径限流、白名单免限流、多zone分级协同，并合理设置burst与日志调优。
直接说结论：limit_req_zone 本身不“支持百万级并发”，它只支持百万级活跃状态数；而百万级并发请求往往来自远少于百万个真实客户端（比如 CDN 回源、爬虫集群、APP 客户端复用连接等），关键在于把内存花在刀刃上——压降有效 key 数量，而非堆内存。
理解内存开销的本质
Nginx 为每个活跃 key（如 $binary_remote_addr）在共享内存 zone 中分配一个固定大小的状态槽，约 64 字节。这意味着：
- 10MB zone ≈ 支持 16 万个独立 IP 的长期限流状态
- 100MB zone ≈ 支持约 160 万个 IP —— 看似够百万，但实际不可靠：突发流量可能瞬间填满，旧状态淘汰机制会引发抖动，且大量低价值 IP（如监控探针、CDN 节点）挤占空间
- 真正决定上限的不是“总并发请求数”，而是同一时间窗口内需被独立识别和计数的 key 数量
压缩有效 key 数量的四类实操手段
百万级并发场景下，应放弃“每个 IP 单独记”的思路，转向聚合与分层：
-
按网段或地域聚合：用 map 指令将 IP 映射为国家码、运营商前缀或 /24 子网。例如：
map $remote_addr $ip_subnet {
default "";
~^(?\d+\.\d+\.\d+)\..* "$net.0";
}
再设limit_req_zone $ip_subnet zone=by_subnet:20m rate=100r/s。20MB 即可覆盖数万个子网，支撑千万级请求分流 -
只对高风险路径限流：不在
location /全局启用，而是聚焦/login、/api/submit、/pay等敏感接口。静态资源、健康检查、CDN 回源路径完全跳过，避免无效状态写入 -
白名单免限流 + 空 key 技巧：用 map 将可信来源（如内部服务段、云厂商探针 IP、已知 CDN 回源段）映射为空字符串：
map $remote_addr $bypass_key {
10.0.0.0/8 "";
192.168.0.0/16 "";
default $binary_remote_addr;
}
再基于$bypass_key定义 zone，空 key 不占用任何槽位 -
多 zone 分级协同：设置小而快的兜底 zone（如
zone=global_flood:2m rate=500r/s，key 为$server_name）防整体打垮；再配中等粒度的业务 zone（如zone=api_per_user:10m rate=10r/s，key 为$http_x_user_id）；最后加严苛的防护 zone（如zone=brute_login:5m rate=2r/m，key 含 UA 和 IP 组合）。内存按需分配，互不干扰
生产配置关键细节
光有策略不够，落地时注意这些硬性要点：
- burst 值要合理：burst 是漏桶深度，不是并发上限。设为 10～30 即可应对瞬时毛刺；过大（如 burst=1000）会导致请求堆积、延迟飙升，反而恶化体验
- 慎用 nodelay：nodelay 让 burst 请求立即通过，失去平滑削峰作用。仅在明确需要“允许突发但拒绝超额”时使用；多数场景建议保留默认延迟行为，让 Nginx 自动排队等待令牌
-
开启限流日志辅助调优：配置
limit_req_log_level warn和log_format ... $limit，观察 access log 中哪些 key 频繁触发限流、哪些 zone 接近满载，动态调整 map 规则或 zone 大小 - 结合 upstream 健康检查做熔断联动：当后端响应超时或错误率突增时，临时收紧限流速率（如通过 Lua 或外部控制面 reload 配置），形成闭环保护
