单靠一个limit_req_zone无法支撑千万级独立IP限流，因每个IP平均占用64字节内存，1000万IP需约640MB；应采用分层zone设计、降维key（如国家码/IP前缀/用户ID）、复用内存及外部兜底（WAF+Redis黑名单）来提升扩展性。
单靠一个 limit_req_zone 区域无法在常规内存下支撑千万级独立 IP 限流，核心问题不是算法能力，而是共享内存开销太大——每个 IP 状态平均占约 64 字节。
单 IP 内存占用怎么算
实测与社区共识一致：每个客户端 IP 在 limit_req_zone 中至少消耗约 64 字节，包含哈希桶头、计数器、时间戳、锁等元数据。这意味着：
- 1 MB 共享内存 ≈ 存储 1.6 万个独立 IP 状态
- 100 万 IP → 至少需约 64 MB 内存
- 1000 万 IP → 至少需约 640 MB，接近 1 GB
- 若用
$remote_addr（文本形式），IPv4 地址平均占 12 字节以上，整体内存再增 15%～20%
为什么不能硬扛 $binary_remote_addr
用 $binary_remote_addr 虽比文本省空间（IPv4 固定 4 字节），但只是“省一点”，不是“省很多”。真正瓶颈在于每个 IP 都要维护完整状态结构，而非地址本身长度。直接按 IP 建 zone 是最笨的办法，内存增长是线性的，毫无弹性。
实际可行的内存压缩路径
关键不是“算准每字节”，而是通过降低 key 维度、复用内存、分层管理，把千万级 IP 映射到几千甚至几百个逻辑 key 上：
- 用
$geoip2_country_code或$http_x_forwarded_for前两段（如192.168）做粗粒度限流，单个 key 覆盖成百上千 IP - 用
map动态构造 key：登录用户走$http_x_user_id，未登录用户回落到 IP 前缀，避免全量记 IP - CDN 回源流量用
$http_x_real_ip + $server_name组合，把“同一源站 + 同一客户”视为一个逻辑单元
分层 zone 设计节省总内存
不把所有压力堆在一个 zone，而是按行为类型拆分，让内存各司其职：
-
zone=burst_api:5m rate=100r/s：专用于突发接口，只存活跃 IP（自动淘汰 60 秒无访问者） -
zone=login_basic:2m rate=3r/m：登录页限流，key 用$binary_remote_addr，但速率极低，长期存活 IP 少 -
zone=user_action:8m rate=20r/s：key 为$http_x_user_id，覆盖真实用户，数量远小于 IP 总量
这样总内存仍可控（例如 15 MB），却能覆盖行为、身份、来源等多个层面，实际支撑能力远超单一千万 IP zone。
必须加的兜底手段
纯 Nginx 内存方案有硬上限，生产环境必须配合外部机制：
- 在 LVS 或云 WAF 层做第一道 IP 频控（基于连接数或包速率），过滤明显攻击流量
- 对高频异常 IP，由后端服务写入 Redis 黑名单，Nginx 通过
lua-resty-redis实时查表跳过限流逻辑 - 开启
limit_req_log_level warn和limit_req_status 429，结合日志分析真实热点 key，持续反哺 zone 策略调优
