limit_req_log_level 仅控制被拒绝请求写入 error log 的级别，不开关日志也不影响限流逻辑；默认 error 级别易致日志淹没，推荐 warn 级别配合单独日志文件以提升信噪比。
limit_req_log_level 的作用不是开关日志，而是过滤日志级别
很多人误以为 limit_req_log_level 是用来“开启/关闭”限流日志的，其实它只控制「哪些被限流的请求会被记录到 error log」。Nginx 默认对所有触发限流的请求都打 error 级别日志（哪怕只是正常业务高峰触发的 429），这会导致 error log 被大量淹没，掩盖真正需要关注的故障信号。
关键点在于：它不改变 access log 行为，也不影响限流逻辑本身，只决定 error log 中是否写入那条 limiting requests 记录。
-
limit_req_log_level info：所有被限流请求都会记一条info日志 —— 适合调试期，但生产环境慎用 -
limit_req_log_level warn：仅当 rate limit zone 达到 burst 阈值、或 key 泄漏严重（如恶意扫描）时才记日志 —— 实际更接近“异常触发”信号 -
limit_req_log_level error（默认）：只要命中 limit_req 就记 error 日志 —— 生产中往往造成信噪比崩塌
和 limit_req 配合使用时，log_level 只对“实际拒绝”的请求生效
limit_req 的 burst 和 nodelay 机制会让部分请求排队或立即拒绝。而 limit_req_log_level **只对最终被拒绝（返回 503 或 429）的请求生效**，排队中放行的请求不会产生这条日志。
这意味着：如果你配置了 burst=10 nodelay，那么前 10 个超频请求会被立刻拒绝并按 log_level 记录；但如果去掉 nodelay，它们可能被缓冲、延迟响应，就不会触发日志 —— 这反而让日志失去代表性。
- 想让日志反映真实压测/攻击行为 → 用
nodelay+limit_req_log_level warn - 想监控“缓冲区打满”这种临界状态 → 需配合
limit_req_status 429和自定义 access log 变量，limit_req_log_level本身做不到 - 注意：log_level 不影响
limit_req_status设置的响应码，那是另一层控制
生产环境推荐组合：warn 级别 + 自定义 error log 格式 + 单独日志文件
直接把限流日志混在主 error.log 里，等于把告警和噪音扔进同一个筐。更可控的做法是分离输出，并用格式化降低解析成本。
示例配置片段：
log_format limitlog '$remote_addr - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent" '
'rt=$request_time uct="$upstream_connect_time" uht="$upstream_header_time" urt="$upstream_response_time"';
<p>limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;</p><p>server {
error_log /var/log/nginx/limit_rejects.warn.log warn;
limit_req zone=api burst=5 nodelay;
limit_req_log_level warn;</p><pre class='brush:php;toolbar:false;'>location /api/ {
limit_req zone=api burst=5 nodelay;
limit_req_log_level warn;
access_log /var/log/nginx/api_access.log main;
# 其他 proxy_pass 等...
}}
- 单独的
error_log文件 +warn级别，避免污染主 error log -
limit_req_log_level warn在 server 和 location 里都显式声明，防止继承意外覆盖 - Nginx 1.13.6+ 支持在 location 块内重写
limit_req_log_level，旧版本只能在 server 或 http 块设
容易被忽略的兼容性与性能细节
limit_req_log_level 看似简单，但在高并发下有几个隐性代价：
- 每个被拒绝请求仍要走完整的日志格式化流程，即使你只记
warn—— 如果 error log 写磁盘慢，会拖累整个 worker 进程 - Nginx 1.11.13 之前，
limit_req_log_level不支持在 if 块中使用；1.13.6 才支持 per-location 覆盖 - 若启用了
syslog输出 error log，warn级别日志可能被 syslog daemon 丢弃（取决于其配置），建议先本地文件验证 - 不要试图用
debug级别查限流细节 —— 它会记录所有匹配 zone 的请求（包括未拒绝的），日志量爆炸且无业务意义
真正影响信噪比的，从来不是“记不记”，而是“为什么记”和“记到哪”。把 limit_req_log_level warn 当成一个告警阈值开关，而不是日志开关，才能让 error log 重新成为可信赖的信号源。
