是限流触发：看error_log是否有“limiting requests”提示、access_log中upstream_addr/upstream_status是否为空、503是否集中于同一IP且request_time趋近0、是否因阈值过严误伤正常并发请求。
遇到 Nginx 返回 503 且怀疑是限流触发，关键不是“有没有限流”，而是快速确认 是不是限流、谁在限、为什么限、限得对不对。下面分四步直击排查核心。
看 error_log 里有没有限流标记
Nginx 主动限流会在 error_log 中留下明确线索，这是最可靠的判断依据：
- 搜索关键词
limiting requests，典型日志如：2026/09/30 12:15:22 [warn] 12345#0: *6789 limiting requests, excess: 2.000 by zone "api" - 若没看到该提示，大概率不是 limit_req 触发的 503，要转向后端或配置问题
- 确保
limit_req_log_level warn已开启（默认就是 warn），否则低级别日志可能被过滤
查 access_log 看 upstream 字段是否为空
修改 log_format，确保包含 $upstream_addr 和 $upstream_status：
- 如果某条 503 日志中这两个字段都是
-或空，说明请求根本没发往后端——极可能是限流、rewrite 拦截或本地拒绝 - 如果
$upstream_addr有值（如127.0.0.1:8000）但$upstream_status是-或503，说明问题出在后端（超时、拒绝连接、主动返回） - 注意：
$upstream_status是后端返回的状态码；Nginx 自己返回的 503 不会写入这个字段
分析 503 的时间与客户端分布特征
限流和后端过载在日志模式上差异明显，用时间+IP+路径三维度交叉观察：
- 同一 IP 在极短时间内（比如 1 秒内）密集出现多个 503，request_time 都接近 0（如 0.000、0.001），基本可锁定为限流
- 多个不同 IP 同时出现 503，且 request_time 普遍偏高（>1s），error_log 中伴随
upstream timed out或Connection refused，属于后端过载或宕机 - 503 集中在特定 path（如
/api/v1/login），而其他接口正常，说明限流规则只作用于该 location，配置位置合理
验证限流配置是否误伤正常流量
很多“故障”其实是阈值设得太紧，尤其忽略浏览器并发行为：
- 一个普通页面加载常触发 10+ 并发请求（HTML、JS、CSS、图片等），rate=5r/s 对单个 IP 来说极易误杀
- burst 值不等于“允许突发”，而是漏桶缓冲区大小；nodelay 开启后，超出部分直接丢弃，不会排队
- 临时降低限流强度测试：比如把
rate=1r/s改成rate=10r/m，或去掉nodelay观察是否缓解 - 检查 location 是否套错了范围——比如整个
/都加了限流，导致静态资源也被限制
