limit_req_log_level用于控制限流行为的日志级别，而非减少日志量；默认error级别下拒绝记error、延迟记warn，设为notice可使延迟记info，配合burst不加nodelay及429状态码，可显著降低高优先级日志频率。
limit_req_log_level 的作用不是“降低日志量”，而是控制哪些限流行为会被记录、以什么级别记录。它本身不减少日志条数，但通过合理设置日志级别，能避免高频限流事件（比如大量被延迟或拒绝的请求）刷爆 error 日志，从而减轻磁盘写入压力和日志轮转负担。
关键逻辑是：Nginx 对“延迟处理”的日志级别默认比“直接拒绝”低一级。利用这个特性，配合 burst 和 nodelay 的使用方式，可以大幅减少高优先级（如 error）日志的生成频率。
一、理解默认行为与日志级别关系
-
limit_req_log_level默认值是error - 当请求被直接拒绝（超出
burst且无缓冲空间），记为设定的级别（如error） - 当请求被延迟处理（放入 burst 队列等待），记为低一级的级别（如设
notice→ 延迟记info；设error→ 延迟记warn） - 所以：把日志级别设为
warn或notice，就能让“延迟”这条主力路径落在info或notice级别，而这些级别通常不会被写入主 error.log（除非你显式配置了error_log ... info）
✅ 建议操作：
- 不要让限流日志混进
error_log /var/log/nginx/error.log error; - 单独为限流配置一个轻量级日志文件，并设较低级别
# 在 http 块中定义 limit_req_log_level notice; # 拒绝记 notice，延迟记 info limit_req_status 429; # 把拒绝响应码改成 429（Too Many Requests），更语义化 # 单独指定限流相关日志（可选，推荐） log_format limitlog '$remote_addr - $status $request_time $limit_rate'; access_log /var/log/nginx/limit.log limitlog;
⚠️ 注意：
limit_req_log_level只影响limit_req模块自身的日志（即“因限流被延迟/拒绝”这一动作），不影响 access_log 或 error_log 的其他内容。
二、用 burst + nodelay 减少“拒绝”场景，让日志更安静
默认不加 nodelay 时，超出速率的请求会排队进 burst 缓冲区，等空闲 slot 再处理——这产生的是 延迟日志（级别更低，更温和）。
一旦加了 nodelay，burst 区的请求不再排队，而是立刻透传，此时 rate 失效，所有超限请求都变成“拒绝”，全部打 error 或你设的高级别日志 → 瞬间刷屏。
❌ 错误示范（高日志风险）：
limit_req zone=one burst=10 nodelay; # 所有第11+请求立即 503/429，全记 error/notice
✅ 推荐做法（日志友好）：
limit_req zone=one burst=5; # 允许最多5个请求排队等待，平滑吞吐 # 此时只有真正超出 burst+rate 总容量的请求才会被拒绝（极少发生）
这样绝大多数超限请求是“被延迟”，记 info 或 notice，不会挤占 error 日志空间。
三、结合 limit_req_status 和监控，替代日志排查
高频限流本身是信号，不是故障。与其靠日志查“谁被限了”，不如：
- 把拒绝状态码设为
429（语义明确，客户端易识别） - 用 access_log 中的
$status字段统计 429 数量（例如用 logrotate + awk 或 Prometheus + nginx-exporter） - 设置告警：单位时间 429 超阈值 → 检查是否遭遇爬虫或攻击，而非翻日志
示例 access_log 记录片段：
192.168.1.100 - - [13/Apr/2026:19:15:22 +0000] "GET /api/v1/user HTTP/1.1" 429 172 0.001
你完全可以通过日志分析工具聚合 429，而不必在 error.log 里逐行 grep。
四、终极精简：关闭限流自身日志（仅保留 access 记录）
如果你只关心“有没有触发限流”，不关心“哪个 IP 在哪毫秒被延迟”，可以直接关掉 limit_req 的专用日志输出：
limit_req_log_level off; # ✅ Nginx 1.19.6+ 支持，彻底禁用该模块日志
⚠️ 注意：off 是合法值（见官方文档），但它只禁用 limit_req 动作日志，不影响 access_log 和 error_log 的其他内容。这是最彻底的“零干扰”方案。
不支持 off 的旧版本（info 级别 + 单独日志路径，同样有效。
不需要大动架构，改两行配置、换一个状态码、加一个日志格式，就能让限流从“日志噪音源”变成“安静守门员”。
