Nginx “limiting requests” 日志是限流生效信号，需通过 excess 值、zone 名、client IP 和 request 路径定位瓶颈；应分级记录日志（warn/notice）、分离存储、添加关键变量、返回 429 状态码，并优化 burst、key 选择及白名单策略以降低无效日志。
看到 error.log 里频繁出现 “limiting requests”，不是配置出错，而是 Nginx 在明确告诉你：当前限流策略正高频介入。关键不是屏蔽日志，而是读懂它、用好它，让每条记录都成为调优依据。
从日志字段反推流量真实压力
典型行：2026/05/06 19:42:11 [error] 12345#0: *6789 limiting requests, excess: 4.234 by zone "api", client: 203.0.113.45...
- excess 值持续 >1.0：说明突发请求远超设定速率，burst 设置可能偏小，或 rate 本身过紧
- by zone "xxx"：快速定位是哪个限流区域（如 perip、byserver）在起作用，避免全局误调
- client IP 高度集中：若同一 IP 多次触发，优先查是否为爬虫或未授权客户端；若大量不同 IP 同时触发，需警惕 CC 类攻击
- request 字段重复固定路径（如 /login、/search）：说明攻击或误用集中在特定接口，应单独对该 location 加强限流
把日志从“噪音”变成“指标”
默认 error 级别会淹没真正故障，且易被监控系统误判为严重异常。正确做法是分级归因：
- 设
limit_req_log_level warn：拒绝记 warn，延迟记 notice，主 error.log 不再刷屏 - 搭配
error_log /var/log/nginx/limit_rej.log warn：将限流日志分离存储，不影响核心错误追踪 - 在 log_format 中加入
$limit_req_key和$status：方便后续用 awk/grep 按 key 统计各 IP 或 URI 的触发频次 - 启用
limit_req_status 429：让限流响应返回标准 HTTP 状态码，便于从 access.log 直接聚合 429 数量，替代低效的 error.log 扫描
结合行为调整，让日志量自然下降
日志多，本质是拒绝动作太频繁。减少写入最治本的方式，是改变限流行为本身：
- 去掉
nodelay：改用burst=10（不加 nodelay），超限请求先进队列等待，Nginx 对“延迟”默认记更低级别日志（如 notice 级下记为 info） - 增大 burst 值而非提高 rate：更平滑吸收瞬时毛刺，避免秒级突增直接打满阈值
- 检查 key 选型是否合理：用
$binary_remote_addr可能误伤 NAT 后用户；若业务有可信 X-Forwarded-For，可改用$http_x_forwarded_for并配合 real_ip 模块 - 对白名单 IP 或内网调用跳过限流：用 map + limit_req condition 实现精准放行，从源头减少无效日志
上线前必须验证的三件事
- 用 wrk 模拟超限请求，确认目标日志文件只出现 warn/notice 行，主 error.log 不再新增限流条目
- 抽样检查被限流请求的 User-Agent 和 Referer：大量 python-requests、空 Referer 或非常规 UA，佐证策略有效性
- 对比调整前后 access.log 中 429 响应占比：若从 5% 降至 0.3%，且无真实用户投诉，说明策略更柔性、更精准
