nginx 无 limit_conn_log_level 指令；limit_conn 默认静默拒绝不记日志，而 limit_req_log_level 才控制限速日志级别，默认 error 易刷爆磁盘，应调为 warn 或 notice，并配合 error_log 级别、独立日志路径及 burst 缓冲优化。
Nginx 没有 limit_conn_log_level 这个指令。这是常见误解，源于将 limit_req_log_level（用于请求速率限流）与 limit_conn（用于连接数限制）混淆。
limit_conn 本身默认不记录任何日志——当连接被拒绝时，Nginx 静默返回 503 Service Temporarily Unavailable，不会向 error.log 写入任何条目。它天然低开销、无日志刷盘风险。
真正导致磁盘 I/O 压力的，是 limit_req 模块配合默认 limit_req_log_level error 的组合。高频请求被拒时，每秒数百条 error 级日志持续落盘，才是磁盘吞吐瓶颈的主因。
✅ 正确调优方向：聚焦 limit_req_log_level
该指令控制“请求被限速拒绝或延迟”事件的日志级别，直接影响 error.log 写入频率和磁盘压力。
- 默认值：
error
→ 每次拒绝都记一条error日志，高并发下极易刷爆磁盘 - 推荐生产值：
warn或notice
→ 显著降低日志量，同时保留可观测性
http {
limit_req_zone $binary_remote_addr zone=req_per_ip:10m rate=10r/s;
server {
location /api/ {
limit_req zone=req_per_ip burst=30;
limit_req_log_level warn; # ← 关键：降级为 warn
limit_req_status 429; # 返回标准状态码，便于监控识别
}
}
}
⚠️ 注意：
limit_req_log_level只影响limit_req自身日志，不影响access_log或其他错误日志。
✅ 配合 error_log 全局级别过滤
仅设 limit_req_log_level warn 不够，还需确保 error_log 配置允许该级别写入：
error_log /var/log/nginx/error.log warn; # 必须 ≥ warn，否则日志不落盘
若仍用 error_log ... error;，即使设了 warn，也不会记录——因为 warn 被全局阈值过滤掉了。
✅ 分离限流日志，彻底隔离磁盘影响
避免限流日志污染主 error.log，推荐独立路径 + 独立轮转：
log_format limit_rej '$remote_addr $status $request_time $limit'; access_log /var/log/nginx/limit_rej.log limit_rej if=$limit_req_status; # 或更轻量：用 error_log 单独承接（需 Nginx ≥ 1.17.6） error_log /var/log/nginx/limit_error.log notice; limit_req_log_level notice;
再配合 logrotate 设置 hourly + maxsize 10M，防止单文件阻塞写入。
✅ 减少拒绝频次：用 burst 缓冲，慎用 nodelay
- 不加
nodelay：超速请求先进burst队列等待 → 记录的是低一级日志（如notice对应延迟记info） - 加了
nodelay：所有超限请求立刻拒绝 → 全部打你设的高级别日志 → 瞬间刷屏
所以：
limit_req zone=req_per_ip burst=20; # ✅ 推荐：有缓冲，日志更安静 # limit_req zone=req_per_ip burst=20 nodelay; # ❌ 避免：无缓冲，全拒绝
✅ 补位可观测性：别依赖日志查限流
日志静默后，靠指标驱动监控：
- 在
access_log中加入$limit_req_status和$status字段，标记429 - 用
stub_status或nginx-module-vts暴露实时拒绝数 - Prometheus 抓取
nginx_http_requests_total{code="429"}，设置 5 分钟 > 500 触发告警
这样既保护磁盘，又不失问题定位能力。
