如何优化Nginx limit_req_zone公式应对千万级独立IP长尾词限流？

本文共计830个文字，预计阅读时间需要4分钟。

使用单个 `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 策略调优