通过分析Nginx error log中limit_req和limit_conn的warn级别拒绝记录，可判断限流策略是否生效及松紧度；需配置error_log为warn及以上级别，关注excess、zone、client、request等字段，并结合access log、stub_status等验证合理性。
直接看日志里 limit_req 和 limit_conn 的拒绝记录，就能判断当前限流策略是否起作用、是否过严或过松。
识别关键日志字段
Nginx 默认在 error log 中记录被限流的请求，需确保配置了 error_log /path/to/error.log warn;（级别设为 warn 或更高），否则 limit 拒绝不会写入。
典型拒绝日志格式如下：
2026/05/07 02:30:15 [warn] 12345#0: *6789 limiting requests, excess: 15.234 by zone "req_limit", client: 192.168.45.112, server: api.example.com, request: "GET /api/v1/user HTTP/1.1", host: "api.example.com"
2026/05/07 02:30:16 [warn] 12345#0: *6790 limiting connections by zone "conn_limit", client: 203.124.88.55, server: 0.0.0.0:80
重点关注：
- excess：表示该请求超出速率限制的具体数值（单位为“请求数”），值越大说明突发越剧烈
-
zone：对应配置中定义的限流区域名（如
req_limit、conn_limit），用于区分不同策略 -
client：真实客户端 IP（注意：若前端有代理，需确认是否已通过
$realip_remote_addr正确还原） - request：被拒的具体路径和方法，可关联业务接口定位风险点
统计高频触发 IP 与行为模式
用简单命令快速筛查异常源：
grep "limiting requests" /var/log/nginx/error.log | awk '{print $8}' | sort | uniq -c | sort -nr | head -20
grep "limiting connections" /var/log/nginx/error.log | awk '{print $7}' | sort | uniq -c | sort -nr | head -20
观察结果时注意：
- 单个 IP 触发频次极高（如每分钟数百次）→ 很可能是爬虫或攻击源
- 大量不同 IP 集中触发同一 zone → 可能是分布式 CC 攻击，需检查是否漏掉代理头识别
- 触发集中在特定接口（如
/login、/api/search）→ 说明攻击目标明确，应针对性加固该 location
对比业务指标验证合理性
限流不是越多越好，关键是“拦坏人、放好人”。需结合 access log 分析影响面：
- 统计被限流 IP 的
HTTP 503响应占比：若超过总请求量 0.5%，且非攻击时段仍持续出现，说明阈值可能偏低 - 抽样检查被限流请求的 User-Agent 和 Referer：大量
python-requests、空 Referer 或非常规 UA，支持判定为恶意 - 比对正常用户会话行为：真实用户通常每秒请求 ≤ 2–3 次（含图片/CSS/JS），而攻击脚本常达 10–100+ r/s
- 检查 burst 设置是否匹配业务峰值：例如秒杀页面允许短时 burst=50，但日常 API burst=10 更稳妥
结合 stub_status 实时验证
启用 ngx_http_stub_status_module 后，访问 /nginx_status 可得实时指标：
Active connections: 124
server accepts handled requests
123456 123456 987654
Reading: 3 Writing: 12 Waiting: 109
重点看：
-
Waiting 值长期接近或等于
limit_conn阈值 → 连接池吃紧，需调高或排查长连接未释放 -
handled / accepts ≈ 1 表示连接基本都被处理；若明显小于 1，说明大量连接被
limit_conn拒绝 - 配合 error log 中的
limiting connections频次，可确认是否因连接数瓶颈导致服务不可用
