限流日志应设为notice级别，避免error级在高压下刷爆磁盘、淹没真实错误、触发误告警；需配合limit_conn_zone与limit_conn使用，并按作用域置于http/server/location块，同时设limit_conn_status为429以提升可观测性。
限流触发时，默认用 error 级别记日志，高压下会刷爆磁盘、干扰故障排查。关键不是关日志，而是把“该记的记清楚，不该刷的压下去”——重点调低级别、聚焦真实异常。
为什么 error 级别在高压下反而有害
当大量请求被 limit_conn 拦住，每条都打一条 error 日志，结果是：
- 日志文件体积暴涨，可能占满磁盘或拖慢 I/O
- 真实错误（如后端超时、502）被淹没在海量限流日志里，难定位
- 监控系统误将限流当成服务异常告警，产生噪音
推荐的日志级别组合与适用场景
notice 是最平衡的选择，它比 warn 更克制、比 info 更聚焦：
-
notice：记录限流事件但不标为错误，适合生产环境主站、API 网关 -
warn：仅在需人工关注突发限流（如某 IP 短时连接暴增）时启用 -
info：调试阶段用，上线前必须降级，否则日志量不可控 -
error：仅保留在灰度或安全加固场景，例如配合 fail2ban 做联动封禁
配置写法与生效细节
必须注意：该指令不能单独存在，要和 limit_conn_zone + limit_conn 配套使用，且位置决定作用范围：
- 放在
http块：全局生效，所有 server 和 location 共享同一日志策略 - 放在
server块：只影响该虚拟主机 - 放在
location块：最细粒度控制，比如只对/upload路径降级日志
示例（推荐写法）：
http {limit_conn_zone $binary_remote_addr zone=perip:10m;
limit_conn_log_level notice;
server {
location /api/ {
limit_conn perip 5;
}
}
}
配合 limit\_conn\_status 提升可观测性
单靠调低日志级别不够，还要让客户端和监控系统“知道这是有意限流”：
- 显式设置
limit_conn_status 429，替代默认的 503，语义更准确（Too Many Requests） - Nginx access log 中可通过
$status字段区分 429 和真实 503，便于日志分析脚本过滤 - 前端或网关可据此做重试退避，而非当作服务宕机处理
