如何配置 limit_conn_log_level 审计静态连接限制触发的异常行为-Nginx-PHP中文网

limit_conn_log_level仅控制连接超限拒绝事件的日志级别，核心作用是降噪而非审计；应通过结构化access日志（含$limit变量）、Prometheus聚合告警及stub_status等手段实现可追溯、可聚合、可响应的限流审计。

如何配置 limit_conn_log_level 审计静态连接限制触发的异常行为

limit_conn_log_level 本身不用于审计异常行为，它只控制“连接超限被拒绝”这一类事件是否记日志、以什么级别记。它的核心作用是降噪，而非审计。想审计静态连接限制的触发情况，不能依赖这个指令，而要换用更可靠、可追溯、不影响主日志质量的方式。

审计目标应明确：不是“记录每次拒绝”，而是“可观测、可聚合、可告警”

Nginx 的 limit_conn 是硬性连接数上限，一旦触发即断连（返回 503），不排队、不缓冲。高频触发往往意味着真实攻击（如扫描、CC）、配置过紧或突发流量。审计重点应是：谁在频繁触限？何时集中发生？是否伴随其他异常特征？ 而非把每条 client 192.168.1.100 rejected 塞进 error.log。

推荐审计路径：分离采集 + 结构化分析

在 http 块中统一设为
limit_conn_log_level error;
这样正常连接超限完全不写日志，避免 error.log 被刷爆，确保真正严重的错误（如共享内存初始化失败）能被看见。
启用结构化 access 日志字段，暴露限流状态
添加自定义 log_format，显式记录限流结果：
```
log_format conn_audit '$remote_addr - $remote_user [$time_local] '
                       '"$request" $status $body_bytes_sent '
                       'conn_limit="$limit_key" conn_rejected=$limit';
```
其中 $limit 是内置变量，值为 1 表示该请求因 limit_conn 被拒绝，0 表示未触发；$limit_key 对应你定义的 zone key（如 $binary_remote_addr）。这样所有连接级限流决策都落进 access log，与业务请求上下文绑定，便于回溯。
用外部工具做分钟级聚合与告警
- 用 nginxlog exporter + Prometheus 抓取 $limit == 1 的请求数，按 $remote_addr 或 $limit_key 分组统计。
- 设置告警规则，例如：“过去 5 分钟内，同一 IP 触发 conn_rejected ≥ 100 次”。
- 配合 Grafana 做热力图，观察触发时间分布和来源地域/IP 段。

补充验证手段：运行时指标 + 主动探测

开启 stub_status 或集成 nginx-module-vts，实时查看 Rejected 计数器变化趋势，确认限流是否生效、是否突增。
对关键静态资源路径（如 /static/、/cdn/）单独定义 limit_conn_zone，例如：
limit_conn_zone $binary_remote_addr zone=static_conn:10m;
并在对应 location 中使用 limit_conn static_conn 50;
这样可隔离审计范围，避免登录接口或 API 的连接行为干扰静态资源限流分析。

不推荐的“伪审计”做法

把 limit_conn_log_level 设为 info 或 notice：仍每拒一次就写一条，若 error_log 级别开到 info，磁盘压力反而更大。
仅靠 grep error.log 查 limit_conn 关键字：日志内容高度重复、无上下文、不可聚合，且易被淹没。
关闭所有限流日志却不补监控：等于放弃对连接层过载的感知能力，故障时无法区分是攻击、误配还是真实容量瓶颈。

审计的本质是让“已知的拒绝”变得可度量、可归因、可响应。用好 $limit 变量 + 外部可观测栈，比调低日志级别更有效。