nginx的limit_req模块基于漏桶算法限流，不直接优化资源消耗，而是通过控制请求速率防止突发流量压垮后端，间接降低cpu、内存及连接压力；需合理配置zone、burst和nodelay，并配合limit_conn、缓存等协同防护。
Nginx 的 limit_req 模块（常被误称为 rate_limit）本身不直接“优化资源消耗”，而是通过限制请求频率来防止突发流量压垮后端，间接降低 CPU、内存和连接数等资源压力。关键在于合理配置而非简单开启。
理解 limit_req 的作用机制
该模块基于漏桶算法对请求进行排队或拒绝，核心是控制单位时间内的请求数。它不减少单个请求的资源开销，但能避免大量并发请求同时抵达上游服务，从而缓解后端处理压力、减少超时和错误响应。
- 所有限流逻辑在 Nginx 工作进程内完成，几乎不增加额外开销
- 真正节省资源的是避免了后端重复初始化、数据库连接、缓存穿透等高成本操作
- 若仅对静态资源限流，效果有限；应重点保护动态接口（如登录、搜索、下单）
合理定义 limit_req zone
zone 是共享内存区域，用于跨 worker 进程统计请求频次。配置不当会导致内存浪费或限流失效。
- key 应选择有区分度但稳定的字段，例如
$binary_remote_addr（压缩后的客户端 IP），比$remote_addr更省内存 - size 值需匹配预期并发用户量：1MB zone 约支持 16000 个独立 key，小站点设 10m 通常足够
- 避免为每个 location 单独建 zone，优先复用同一 zone 实现统一限流策略
选择适合业务的 burst 和 nodelay 策略
burst 决定允许的瞬时突发请求数，nodelay 控制是否立即响应还是排队等待。这两者直接影响用户体验与资源水位。
- 设
burst=5 nodelay：允许最多 5 个请求立刻通过，超出即 503，适合防爬虫或强一致性场景 - 设
burst=20（无 nodelay）：多余请求排队，按 rate 匀速放行，适合容忍短时延迟的 API - 慎用过大的 burst：虽提升可用性，但可能将压力延迟传导至后端，失去限流意义
结合其他模块协同降载
单独限流效果有限，需配合其他机制形成资源防护闭环。
- 用
limit_conn控制并发连接数，防止 TCP 连接耗尽 - 用
proxy_buffering off+proxy_cache缓存高频只读响应，减少后端调用 - 对已知恶意 UA 或异常参数（如
user-agent: sqlmap）用if+return 444快速丢弃，不进限流逻辑
