limit_req_log_level 默认为error，高频限流时每拒绝请求即写error日志，导致磁盘I/O飙升、日志服务压力大、Nginx响应变慢；它仅作用于被拒绝请求，不控制其他错误日志。
limit_req_log_level 的默认行为为什么会导致日志膨胀
当 limit_req 触发限流时，Nginx 默认以 error 级别记录每一条被拒绝的请求，日志会大量写入 error.log。高频限流（比如每秒数千次 503）直接导致磁盘 I/O 暴涨、日志轮转压力剧增，甚至可能拖慢 worker 进程响应。
这不是配置错误，而是设计如此：Nginx 把“超出速率限制”视为一种异常事件，默认归为 error 级别。但实际生产中，限流是主动防御策略，不是故障信号。
-
limit_req_log_level必须和limit_req配套使用，单独配置不生效 - 它只控制“被限流拒绝”的日志级别，不影响正常请求或其它错误（如 404、500）的日志输出
- 可选值包括
info、notice、warn、error；设为info或notice后，需确保error_log配置允许该级别（例如error_log /var/log/nginx/error.log notice）
如何安全地把限流日志降级到 notice 级别
核心是两步：先调低日志级别，再确认日志接收端能过滤或忽略该级别。否则可能误判为问题漏报。
- 在
http或server块中，为对应限流区域添加：limit_req zone=api burst=10 nodelay;<br>limit_req_log_level notice;
- 同步修改全局
error_log指令，至少设为notice：error_log /var/log/nginx/error.log notice; - 如果用 rsyslog 或 journald 收集日志，检查其过滤规则是否仍捕获
notice级别 —— 很多默认只收warning及以上，此时降级后反而“看不到”限流日志，失去监控意义
burst 场景下 limit_req_log_level 的触发边界在哪
它只对“最终被拒绝”的请求打日志，不记录进入 burst 缓存队列或被延迟处理的请求。也就是说：limit_req_log_level 不会在每个请求上都触发，只在真正返回 503（或 502/429，取决于配置）时写日志。
- 例如
limit_req zone=api burst=5 nodelay;：前 5 个超频请求会被缓存并延迟发出，不记日志；第 6 个才触发拒绝并按limit_req_log_level记录 - 若去掉
nodelay，burst 内的请求会排队，只有超出 burst 总数的部分才被拒绝并记日志 - 注意：即使用了
nodelay，只要请求没被拒绝（比如通过了令牌桶），就不会触发该日志
为什么不能直接关掉限流日志
完全屏蔽（比如设成 crit 且不匹配）看似省资源，但会丢失关键观测能力：无法区分是真实服务崩溃（500）、上游不可达（502），还是单纯被限流（503）。运维排查时容易误判为后端故障。
- 更稳妥的做法是保留日志，但分级 + 过滤：用
notice级别写入独立文件，或通过log_format加字段标识限流事件，再由日志采集器做路由 - Nginx 1.13.6+ 支持
limit_req_status，可配合自定义状态码（如 429）与log_format中的$status字段联动，实现精准过滤 - 磁盘写入开销主要来自频繁 fsync，可考虑将限流日志指向 tmpfs（如
/dev/shm/nginx-rate-limit.log），再定时 sync 到持久存储
真正影响性能的不是日志级别本身，而是日志写入路径、同步策略和采集方式。把 limit_req_log_level 设对只是第一步，后续必须配套调整日志落盘行为和监控链路，否则要么丢数据，要么压垮磁盘。
