高可用限流需“精准压缩+分层兜底+动态裁剪”：按业务维度降维key（如用户ID、IP前缀、国家码）、分层设置zone（api_normal/login_strict/user_action等）、跳过非关键流量（CDN回源、健康检查）、联动WAF/Redis日志调优。
直接配一个能存下千万 IP 的 limit_req_zone 不现实——单个 IP 状态占约 64 字节，1000 万活跃 IP 就要近 640 MB 共享内存，且状态无法长期驻留、哈希冲突加剧、worker 间同步开销陡增。高可用限流的关键不是“全量记住”，而是“精准压缩 + 分层兜底 + 动态裁剪”。
按业务维度降维 key，把千万 IP 映射到百级逻辑单元
避免用 $binary_remote_addr 作为唯一 key，改用更高抽象层级的标识：
- 已登录用户：用
$http_x_user_id（后端注入），真实用户数通常只有活跃 IP 的 1/5～1/10，内存压力骤减 - 未登录流量：聚合为 IP 前缀，如
map $binary_remote_addr $ip_prefix { ~^(?<a>\d+\.\d+)\. $a; default "0.0"; }</a>，将 /16 网段归为一个 key - 地域维度：结合
geoip2模块提取$geoip2_data_country_iso_code，全球 200+ 国家 → 200 个 key - 设备+行为组合：对风控敏感接口，用
$binary_remote_addr$http_user_agent防 UA 轮换，但仅限 login、pay 等路径，不全局启用
分层 zone 设计，让内存各司其职
不把所有限流逻辑塞进一个大 zone，而是按风险等级、路径重要性、存活周期拆分多个小 zone，总内存可控，命中更精准：
-
zone=api_normal:5m rate=20r/s：覆盖全部 API，key 为$server_name，防域名级泛洪，2 MB 内存即可稳住 -
zone=login_strict:3m rate=3r/m：只作用于/login，key 用$binary_remote_addr，因登录失败 IP 存活时间短，自动淘汰快，3 MB 支撑数万尝试者 -
zone=user_action:8m rate=50r/s：key 为$http_x_user_id，面向真实账号，数量有限，可长期跟踪异常操作频次 -
zone=burst_fallback:2m rate=100r/s：极宽松兜底，key 为$remote_addr哈希前缀，防止某网段突发刷量击穿上层
主动剔除低价值流量，释放内存给关键路径
不是所有请求都值得记录状态，跳过它们等于变相扩容：
- CDN 回源、健康检查、内部服务调用：用
map将其映射为空 key，例如map $http_x_forwarded_for $limit_key { "10.0.0.0/8" ""; "192.168.0.0/16" ""; default $binary_remote_addr; } - 静态资源路径（
/static/、/favicon.ico）不套limit_req，或单独配置极宽松 zone - 对
GET /health等探针接口，完全绕过限流，避免干扰监控准确性
配合外部系统构建弹性防线
Nginx 限流是第一道轻量闸门，不是唯一防线。当真实活跃 IP 超出内存承载能力时，需有后备机制：
- WAF 层做 IP 黑名单实时同步：Nginx 日志中持续触发
limit_status=hit的 IP 段，由脚本自动推入云 WAF 黑名单 - Redis 计数器兜底：对登录爆破等场景，在应用层用 Redis + Lua 实现滑动窗口，支持千万级 key 且可持久化
- 日志驱动动态调优：开启
log_format limitlog ... "$limit_status"，用 Prometheus 抓取$limit_status分布，识别“大量 passed 但实际应限”的漏网区域，反向优化 map 规则
