nginx无法基于响应状态码动态限流，因限流发生在请求进入阶段，而状态码由后端响应生成；但可通过error_page+return实现限流时返回429等自定义状态码及json响应。
Nginx 本身不支持直接基于响应状态码（如 500、429、503）动态触发限流——限流发生在请求进入阶段（即请求被接受或拒绝前），而状态码是后端处理完成、响应生成后才确定的。所以“针对特定状态码配置限流”这个说法存在逻辑误解。
但你真正需要的，通常是以下两类场景的实现方式：
✅ 场景一：限流触发时，返回自定义状态码和响应体
这是最常见需求：当请求被限流拒绝时，Nginx 默认返回 503 Service Temporarily Unavailable，但你可以主动改写为其他状态码（如 429 Too Many Requests）并返回 JSON 响应。
http {
# 定义限流区域（按 IP）
limit_req_zone $binary_remote_addr zone=ip_limit:10m rate=5r/s;
# 自定义错误页面映射
map $status $limit_status {
503 429; # 将限流产生的 503 映射为 429
}
server {
location /api/ {
limit_req zone=ip_limit burst=10 nodelay;
# 拦截限流返回的 503，并重定向到自定义响应
error_page 503 = @rate_limited;
}
location @rate_limited {
internal;
add_header Content-Type "application/json; charset=utf-8";
return 429 '{"code":429,"msg":"Too many requests, please try later"}';
}
}
}
⚠️ 注意：error_page 503 = @rate_limited 中的 = 表示内部重定向且不改变响应状态码；而 return 429 ... 显式设为 429，最终客户端收到的就是 429 状态码 + JSON 内容。
✅ 场景二：根据后端返回的状态码做条件限流（需配合 Lua 或 OpenResty）
纯 Nginx 配置无法在响应阶段反向触发限流（因为限流已执行完毕），但如果你使用 OpenResty + lua-resty-limit-traffic，可实现在 header_filter_by_lua_block 或 body_filter_by_lua_block 中读取 $status，再记录或上报异常状态，用于后续策略（如临时降级该 IP 的速率）。
简单示意（OpenResty）：
location /backend/ {
proxy_pass http://upstream;
header_filter_by_lua_block {
if tonumber(ngx.var.status) == 500 then
-- 记录到共享内存或 Redis，供后续限流模块参考
local limiter = require "resty.limit.count".new("my_limit", 10, 60)
local key = ngx.var.binary_remote_addr
limiter:incr(key, 1) -- 异常一次，加1分（用于动态惩罚）
end
}
}
这类方案属于高级动态限流，需额外组件支持，不在标准 Nginx 范围内。
❌ 不可行的操作（常见误区）
-
limit_req不能写成limit_req if $status = 500→ 语法错误，$status在限流阶段不可用； - 不能用
if ($status = 503) { ... }在 location 中判断 →if指令不支持$status变量； -
limit_conn或limit_req均作用于请求入口，与后端响应无关。
✅ 补充：让限流更“语义化”的推荐做法
| 目标 | 推荐配置 |
|---|---|
| 返回标准 RFC 限流码 | 用 return 429 替代默认 503 |
| 统一 JSON 格式响应 |
add_header Content-Type "application/json" + return
|
| 区分不同路径限流强度 | 多个 limit_req_zone + 不同 zone= 应用于不同 location
|
| 避免误伤合法爬虫 | 结合 $http_user_agent 或 cookie 做 key，例如 limit_req_zone $cookie_uid zone=user_limit:10m rate=10r/s;
|
不需要复杂模块，标准 Nginx 就能干净地实现“限流即返回 429 + JSON”。关键在于理解：限流是前置守门员，不是后置裁判——它不看结果，只管进门节奏。
