Nginx集群需构建多级弹性防线：集群级限流依赖Redis共享状态或IP哈希分片；burst+nodelay按业务调优（秒杀/登录/静态资源差异配置）；连接、请求、响应三层过载保护；结合map+Prometheus实现黑白名单动态联动。
面对突发流量，Nginx 集群不能只靠单节点限流硬扛——必须从“请求入口层”到“后端服务层”构建多级弹性防线。核心不是堵死流量，而是让系统在压力下仍能稳住关键路径、拒绝无效请求、缓冲合理突增，并为运维留出响应窗口。
集群级限流：统一速率控制 + 分布式状态同步
单台 Nginx 的限流区域（limit_req_zone）是本地内存的，集群中各节点独立计数会导致限流失效。要真正实现集群维度的速率控制，需借助外部共享状态：
- 用 Redis 配合 ngx_http_redis2_module 或 OpenResty 的 resty.limit.traffic 模块，将请求计数存入 Redis，所有 Nginx 节点共用同一桶
- 若暂无 Redis，可采用“分片 IP 哈希”降级方案：通过 hash $binary_remote_addr consistent 将同一 IP 固定路由到某台 Nginx，再在其上做严格限流，虽非全局精确，但大幅降低误放率
- 务必启用 limit_req_status 429，配合日志格式记录 $limit_req_status，便于 ELK 实时聚合分析被限流的 IP、接口、频次
burst + nodelay 的实战调优：不牺牲用户体验的缓冲策略
burst 不是越大越好，nodelay 也不是默认必开——它们的组合效果取决于业务语义：
- 秒杀/下单类接口：rate=30r/s + burst=60 + nodelay —— 允许短时双倍洪峰涌入并立即处理，避免用户点击后白屏；后端需配合队列削峰（如 Kafka），Nginx 层只负责“接得住、不崩”
- 登录/注册接口：rate=5r/m + burst=1 + nodelay —— 严格防爆破，突发仅容 1 次试探，超即返 429，杜绝暴力遍历
- 静态资源 / 图片 API：rate=100r/s + burst=0 —— 不设缓冲，超额直接 429，避免缓存雪崩或带宽打满
过载保护三道闸门：从连接、请求到响应链路
限流只是第一关，真实过载常始于连接堆积和响应阻塞：
- 连接层：用 limit_conn_zone 限制单 IP 并发连接（如 zone=conn_perip:10m; limit_conn conn_perip 10），防 Slowloris 类慢速攻击
- 请求层：对 /health、/metrics 等运维接口单独限流（rate=1r/s），避免监控探针自身成为压测源
- 响应层：配置 proxy_next_upstream error timeout http_500 http_502 http_503 http_504 + proxy_next_upstream_tries 2，后端短暂不可用时自动摘除并重试，避免雪崩传导
黑白名单动态联动：基于实时行为的自适应防护
静态封禁 IP 效率低，应让 Nginx 主动参与威胁感知：
- 用 map 指令提取请求特征（如 $http_user_agent ~* "(sqlmap|nmap|masscan)"），命中即设变量 $block = 1，再通过 if ($block) { return 403; } 快速拦截
- 结合 Prometheus + Alertmanager 监控 nginx_http_requests_total{code=~"429"}，当某 IP 5 分钟内触发限流超 50 次，自动调用 API 将其写入 Redis 黑名单，Nginx 定时 reload 或通过 Lua 动态读取
- 对高价值用户（如带有效 JWT 的会员请求），用 limit_req_zone $jwt_uid zone=premium:10m rate=100r/s 单独放行，保障核心体验
