将 limit_conn_log_level 设为 error 是最有效方式——限流拒绝事件不写入 error log，彻底消除日志刷屏对磁盘 I/O 的干扰；默认 warn 级别在高并发拒绝时导致磁盘高负载、轮转开销大、关键错误被淹没。

直接把 limit_conn_log_level 设为 error 是最有效的方式——它让限流拒绝事件完全不写入 error log，彻底消除日志刷屏对磁盘 I/O 的干扰。

为什么默认 warn 级别会拖垮 IO

当大量连接被 limit_conn 拒绝时（例如遭遇扫描或突发流量），每秒可能触发数百甚至上千次 warn 日志。这些日志密集写入 error.log，导致：

• 磁盘持续高负载写入，挤占其他关键服务的 I/O 带宽
• 日志轮转频繁，引发额外的文件系统操作开销
• 真正需要关注的 error 级异常（如共享内存初始化失败）被淹没

推荐配置：静默限流 + 外部可观测性补位

仅调低日志级别还不够，需配合结构化监控避免“看不见即等于没发生”：

• 在 http 块中统一设为 limit_conn_log_level error; —— 正常限流拒绝零日志
• 启用 stub_status 或集成 nginx-module-vts，实时查看 rejected 计数
• 用 Prometheus + nginxlog exporter 抓取 access log 中的 $limit 和 $limit_key 变量（需 OpenResty 或 patch 支持），做分钟级聚合告警
• 对静态资源限流 zone（如 zone=static）单独设置，避免与登录、API 等关键路径混用

搭配 limit_req 缓冲，从源头减少拒绝次数

limit_conn 是硬性连接数上限，无法缓冲；但可在外层叠加 limit_req 做请求级平滑：

• 例如：对同一 IP 设置 limit_conn addr 50; + limit_req zone=req_per_ip burst=30 nodelay;
• 这样大部分突发请求先进入 burst 队列等待，而非立刻被 limit_conn 拒绝，天然降低 error log 触发频率
• 同时把 limit_req_log_level 设为 warn，让延迟行为有迹可循，但不冲击 error.log

不建议的“降噪”方式

以下做法看似减少日志，实则掩盖问题或引入新风险：

• 把 limit_conn_log_level 设为 info 或 debug：仍每拒一次就记一条，只是级别更低，若 error_log 配置了 info 级别，反而更占磁盘
• 关闭所有限流日志却不补监控：等于放弃对连接过载的可观测性，故障时无法回溯
• 盲目增大 limit_conn_zone 内存：不能解决日志噪音，还浪费共享内存资源