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