配置limit_req_zone内存大小应基于并发活跃IP数而非总访问量，每个IP约占64字节，1MB可存约1.6万个IP；超5万宜拆分key或加白名单。
配置 limit_req_zone 的内存大小，关键不是看总访问量，而是盯住「并发活跃 IP 数」——也就是在限速时间窗口（如 1 秒）内真正可能同时触发计数的客户端数量。静态资源高并发场景下，IP 分布往往更集中、行为更规律，反而更容易精准估算。
按活跃 IP 数反推内存用量
每个被限速的 IP（使用 $binary_remote_addr）在共享内存区中固定占用约 64 字节：包含 IPv4 二进制地址（4 字节）、64 位计数器（8 字节）、时间戳、哈希桶指针等管理开销。实测 1MB 内存可稳定存储约 16,000 个 IP 状态。
- 5,000 个并发活跃 IP → 需 320 KB → 建议配
zone=static:2m（留冗余防哈希冲突和短期增长） - 20,000 个并发活跃 IP → 需 ~1.28 MB → 推荐
zone=static:10m - 超 50,000？不建议单 zone 扛，应拆分 key（例如按 URL 前缀或 referer 分组）或叠加白名单豁免可信 CDN 回源 IP
静态资源场景下的活跃 IP 估算技巧
静态资源（如 JS/CSS/图片）常由少量 CDN 节点回源，或被浏览器强缓存，真实并发 IP 远低于日志总去重数。需剔除“偶发访问”干扰：
- 从 access.log 抽最近 60 秒高频请求段：
awk '$9==200 && $7 ~ /\.(js|css|png|jpg|webp)$/ {print $1}' access.log | sort -u | wc -l，再乘以 0.4～0.7（CDN 回源 IP 通常占 3～8 个，但每个会带千级并发请求） - 若用 CDN，重点统计其回源 IP 段（如 Cloudflare、阿里云全站加速的官方 IP 列表），按段估算活跃连接数，而非单 IP
- 观察 Nginx worker 进程 RSS 内存：上线后运行
ps aux | grep nginx | grep worker，若某 worker RSS 突增且波动剧烈，大概率是 zone 内存不足导致状态频繁淘汰
配置与验证要点
静态资源限流宜宽松+缓冲，避免误伤缓存失效时的批量重拉：
- 定义 zone 时用
$binary_remote_addr，不拼接 URI 或参数，防止 key 泛化浪费内存 - location 中启用时加
burst=20 nodelay：允许短时突发，但不排队延迟（静态资源重试成本低，直接响应比排队更合理） - 开启限速日志辅助诊断：
log_format limitlog '$remote_addr [$time_local] "$request" $status $limit_status';，关注$limit_status是否大量出现hit（正常）或频繁切换为-（状态未命中，内存可能不足） - 上线后检查 error.log：反复出现
limiting requests, excess: 123且对应 IP 在几秒内消失，说明状态被挤出，需扩容 zone
避免常见偏差
静态资源流量有明显峰谷和缓存依赖，别套用动态 API 的模型：
- 不按日活用户数算：10 万日活静态资源请求，峰值并发活跃 IP 可能仅数百（尤其 CDN 场景）
- 不盲目放大 burst：burst=100 不等于能扛住 100 并发，它只是缓冲槽位，底层仍受限于 rate 和内存中 IP 状态是否存活
- 不忽略白名单：对已知 CDN 回源 IP 或监控探针 IP，用
geo+map设置空 key，彻底绕过限流，减少无效内存占用
