详解 "limiting requests" 记录：如何根据错误日志微调限流策略

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 级别会淹没真正故障，且易被监控系统误判为严重异常。正确做法是分级归因： 设 ：拒绝记 warn，延迟记 notice，主 error.log 不再刷屏 搭配 ：将限流日志分离存储，不影响核心错误追踪 在 log_format 中加入 和 ：方便后续用 awk/grep 按 key 统计各 IP 或 URI 的触发频次 启用 ：让限流响应返回标准 HTTP 状态码，便于从 access.log 直接聚合 429 数量，替代低效的 error.log 扫描 结合行为调整，让日志量自然下降 日志多，本质是拒绝动作太频繁。减少写入最治本的方式，是改变限流行为本身： 去掉 ：改用 （不加 nodelay），超限请求先进队列等待，Nginx 对“延迟”默认记更低级别日志（如 notice 级下记为 info） 增大 burst 值而非提高 rate：更平滑吸收瞬时毛刺，避免秒级突增直接打满阈值 检查 key 选型是否合理：用 可能误伤 NAT 后用户；若业务有可信 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%，且无真实用户投诉，说明策略更柔性、更精准