直接查 Nginx error_log 中“limiting requests”标记，结合 access_log 的 $upstream_addr 为空、$request_time 极短（0.000–0.002s）及客户端请求规律（同IP短时密集503），可快速确认是否限流导致503。
直接看 Nginx 日志就能快速确认是不是限流导致的 503。关键不是只盯着返回码，而是比对 error_log 和 access_log 中的上下文线索。
查 error_log 看限流标记
Nginx 主动限流会在错误日志里留下明确提示：
- 搜索 “limiting requests”，典型行如：
limiting requests, excess: 1.000 by zone "peripreq" - 若没看到，检查是否启用了足够高的日志级别（如
log_level notice或debug） - 注意：默认
error_log级别为error，限流信息可能被过滤，需临时调高
查 access_log 看上游是否“根本没发出去”
确保你的 log_format 包含 $upstream_addr 和 $upstream_status：
- 如果这两项都为空（
-），说明请求压根没走到后端——大概率是限流、rewrite 拦截或本地拒绝 - 对比正常请求：限流触发的 503 通常
$request_time极短（比如 0.000–0.002 秒），因为连连接都没建 - 而真实后端问题往往伴随
$request_time > 0.5s，甚至超时值（如 60s）
看客户端行为是否符合限流规律
限流有强模式特征，和随机过载完全不同：
- 同一 IP 在极短时间内（如 1 秒内）密集出现多个 503，间隔接近固定（如每 100ms 一个）
- 集中在特定路径（如 /api/v1/submit）或 User-Agent（如爬虫头）
- 配合页面资源加载场景：HTML 加载后，CSS/JS/图片并发请求中第 11、12 个开始报 503（对应
burst=10队列满）
验证配置是否真在生效
有时限流规则写了但没生效，或作用范围不对：
- 运行
nginx -t确认语法无误，再nginx -s reload - 检查
limit_req_zone定义位置（必须在 http 块）和limit_req调用位置（server 或 location）是否匹配 - 确认没有被
if或其他条件意外跳过，Nginx 的 if 是危险区域 - 留意是否误配了
limit_req_status 503—— 这会让限流直接返回 503，而非默认的 503
