limit_conn_log_level仅控制连接超限拒绝事件的日志级别，核心作用是降噪而非审计；应通过结构化access日志（含$limit变量）、Prometheus聚合告警及stub_status等手段实现可追溯、可聚合、可响应的限流审计。
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 变量 + 外部可观测栈，比调低日志级别更有效。
