Nginx主动限流可通过error_log中的“limiting requests”提示、access_log中upstream_addr/upstream_status为空、503集中于特定IP/路径且request_time趋近0等特征识别；后端过载则表现为多IP泛发503、upstream_status异常或缺失、request_time偏高及error_log中大量超时或连接拒绝记录。
直接看日志中的响应头和上下文特征就能区分：Nginx 主动限流会留下明确的限流标记，而后端过载则表现为连接失败、超时或上游无响应。
看是否有 limit_req 相关的响应头或日志线索
Nginx 在启用 limit_req 限流时，若请求被拒绝，默认不记录详细原因到 access_log，但可通过以下方式确认：
- 检查 error_log（如
/var/log/nginx/error.log）是否出现类似limiting requests, excess: 1.000 by zone "zone_ip"的提示； - 在配置中启用
log_level notice或更高（如debug），可让限流动作更显式输出； - 若配置了自定义限流响应页（如
error_page 503 /503.html），且该页面内容固定、无后端痕迹（比如不含数据库错误、堆栈或服务名），大概率是限流触发； - 限流导致的 503 通常 不伴随 upstream 相关关键词（如
no live upstreams、connection refused、timeout、upstream prematurely closed）。
看 access_log 中的 upstream_addr 和 upstream_status 字段
确保你的 log_format 包含这两个关键变量（例如：log_format main '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" $upstream_addr $upstream_status $request_time $upstream_response_time';）：
- 如果
$upstream_addr为空或显示为-，且$upstream_status也是-，说明请求根本没发往后端——极可能是限流、rewrite 拦截或本地拒绝； - 如果
$upstream_addr显示具体后端地址（如127.0.0.1:9000），但$upstream_status是-或缺失，常见于连接被拒绝（Connection refused）或超时未响应； - 如果
$upstream_status是503（注意：不是 Nginx 返回的 503，而是后端自己返回的），说明后端应用主动返回了 503，属于业务层过载或维护； - 如果
$upstream_status缺失，而 error_log 中有connect() failed (111: Connection refused)或upstream timed out，基本可断定后端不可达或响应太慢。
结合时间分布与客户端特征交叉判断
限流和过载在日志模式上有明显差异：
-
限流：503 集中出现在特定 IP、User-Agent 或 URL 路径上；同一 IP 短时间内大量 503，间隔规律（如每秒最多 10 次，第 11 次必 503）；可能伴随大量相同
request_time（如都接近 0.000），因为请求甚至没出 Nginx； -
后端过载：503 出现在多个不同 IP、路径、User-Agent 上，呈“面状”爆发；
request_time偏高（常 >1s），且upstream_response_time缺失或极大（如超 60s）；error_log 中常伴随机群式超时或连接失败报错； - 若某类请求（如 POST /api/v1/submit）503 突增，而 GET /health 持续 200，则更倾向后端业务逻辑瓶颈（如 DB 锁、慢查询），而非全局限流。
快速验证方法：绕过 Nginx 直连后端
用 curl 或 telnet 绕过 Nginx，直接访问后端服务端口：
-
curl -v http://127.0.0.1:9000/health—— 若返回 200，说明后端正常，问题在 Nginx 层（限流/配置）； -
curl -v http://127.0.0.1:9000/some-api—— 若超时或返回 503，说明后端自身已过载或异常； -
telnet 127.0.0.1 9000—— 若连接立即拒绝，说明后端进程未监听；若卡住几秒后断开，大概率是后端无响应或挂起。
