最轻量精准的优化是调低 limit_req_log_level——仅降日志级别（如 error→warn/notice），不关日志，缓解磁盘 I/O，保留可追溯信息；它只影响 limit_req 拒绝或延迟行为的日志，与 access log、其他 error log 无关；推荐突发高峰设 warn，常态限流设 notice，调试时临时设 info；建议单独配置限流日志路径并轮转；配合 burst 使用延迟排队可进一步减少高级别日志输出。
直接调低 limit_req_log_level 是最轻量、最精准的优化手段——它不关日志，只降级别，让高频限流不再狂刷 error 日志，从而显著缓解磁盘 I/O 压力，同时保留关键可追溯信息。
明确作用边界：它只管“被限流”的那一下
limit_req_log_level 仅影响 limit_req 模块触发的拒绝或延迟行为所生成的日志条目，和以下内容完全无关：
- access log（访问日志）的写入与否或格式
- 其他 error log 条目（如 upstream 超时、SSL 握手失败、配置加载错误）
- 是否记录日志（它不控制开关），只控制记录到哪个级别（error / warn / notice / info）
合理设级：按场景选 warn 或 notice
默认 error 级别在高并发限流时极易造成日志风暴。生产中应根据实际流量特征分级处理：
- 突发但短暂的高峰（如活动预热）→ 设为 warn：保留可查痕迹，日志量下降约 60–70%
- 常态化配额限流（如 API 每秒 100 次）→ 设为 notice：仅表明“发生了限流”，不视为异常，日志量下降超 90%
- 调试归因阶段 → 可临时设为 info，再配合
limit_req_status 429和自定义 access log 格式，把状态码和限流标识落进 access 日志，避免 error log 混杂
隔离日志路径：避免冲刷主 error.log
即使日志级别调低，也建议为限流日志单独指定输出路径，防止与其他严重错误混在一起，干扰故障排查：
- 在 http 块中添加：
error_log /var/log/nginx/limit_rej.log warn; - 这样只有 warn 及以上级别会写入该文件，而主
error.log不再掺杂限流条目 - 搭配
logrotate配置 hourly 轮转 +maxsize 10M，防止单文件膨胀阻塞写入
配合 burst 使用，进一步减少 error 级日志
Nginx 对“延迟”和“拒绝”的日志级别默认差一级。利用这点，可让大部分请求走“排队延迟”路径（日志更轻），而非“立刻拒绝”（日志更重）：
- 配置时 不要加
nodelay：例如limit_req zone=mylimit burst=20;，超速请求先进队列等待，记的是低一级日志（如设 notice → 延迟记 info） - 一旦加了
nodelay，burst 区就失效，所有超限请求都立刻拒绝，全部打你设的高级别日志 → 瞬间刷屏 - 若需严格硬限流，也建议先用 burst 缓冲，再通过监控 “429 响应数/秒”（从 access log 抽取）替代依赖 error log 统计
