limit_req_log_level 是日志级别过滤器，仅控制被拒绝请求的日志级别，不决定是否记录；需配合全局 error_log 级别使用，否则日志可能被过滤掉。
limit_req_log_level 不是开关，而是“日志过滤器”——它只影响被拒绝请求的日志级别，放行请求永远不记日志（无论设成 info 还是 warn）。
为什么设了 limit_req_log_level warn 却看不到限流日志？
常见现象：Nginx 配置了限流，但 error.log 里既没 limiting requests，也没报错，仿佛限流没生效。根本原因不是配置失效，而是默认日志级别是 error，而你设的 warn 比 error 更“宽松”，但 Nginx 的日志输出还受全局 error_log 级别控制。
实操建议：
- 检查全局
error_log配置，比如error_log /var/log/nginx/error.log warn;—— 如果这里设的是error，那即使limit_req_log_level warn也压根不会写日志 -
limit_req_log_level只对“触发限流并被拒绝”的请求生效，且仅决定该条日志的级别（info/notice/warn/error），不改变是否记录 - 最稳妥的调试组合：
error_log /path/to/error.log debug;+limit_req_log_level info;，能看清每条被拒请求的 key、zone、burst 溢出细节
limit_req_log_level 和 limit_req_status 要配着看
限流日志的“信噪比”不仅取决于写不写，更取决于写了什么、谁来读。比如运维查告警习惯扫 warn 级日志，但开发可能想用 info 级日志做请求分布分析。
实操建议：
- 线上稳态运行时，推荐
limit_req_log_level warn+ 全局error_log ... warn;，避免info级日志刷爆磁盘 - 若配合
limit_req_status 429（而非默认 503），需确认监控系统是否识别 429 的日志标记——有些日志采集器按 status 过滤，但limiting requests日志里并不含 status 字段 - 不要依赖日志中的 “by zone” 文字判断具体限流规则，真正决定行为的是
limit_req指令里的zone=xxx和burst=参数，日志只是副产品
真实场景下的参数取舍：debug 不等于可用，info 不等于安全
在高 QPS 接口上开 limit_req_log_level info，可能让 error.log 每秒多出数千行，反而掩盖真正的错误。这不是功能问题，是日志设计的天然权衡。
实操建议：
- 测试环境可设
info，观察 key 计算是否符合预期（比如$binary_remote_addr是否真按 IP 归一，$uri是否带 query string） - 生产环境如需采样分析，改用
log_format在 access.log 中记录$limit变量（需编译时含--with-http_realip_module并启用），比塞满 error.log 更可控 -
limit_req_log_level对性能无影响，但高频写日志会拖慢 worker 进程——尤其当磁盘 I/O 已饱和时，warn和error的实际写入频率差异可能微乎其微
真正难调的从来不是这个参数本身，而是你得先确认：当前看到的“没日志”，到底是限流根本没触发、被全局日志级别吞了、还是请求压根没走到这条 limit_req 规则里。
