不能，limit_req_status仅设状态码，不控制响应体；需配合error_page与return或lua实现json返回，proxy_pass透传会破坏限流效率与一致性。
limit_req_status 能否直接返回 JSON？
不能。limit_req_status 只能设置 HTTP 状态码（如 429），不控制响应体内容。Nginx 本身不提供“限流时自动输出 JSON”的内置能力，必须配合 error_page 和 return 或 proxy_pass 实现。
用 error_page + return 构建 JSON 响应的最小可行配置
这是最轻量、无依赖的方案，适合简单统一的错误格式：
limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;
<p>server {
location /api/ {
limit_req zone=api burst=5 nodelay;
limit_req_status 429;</p><pre class="brush:php;toolbar:false;"> error_page 429 = @rate_limited;
}
location @rate_limited {
add_header Content-Type "application/json; charset=utf-8";
return 429 '{"code":429,"message":"Too many requests","retry_after":60}';
}}
-
error_page 429 = @rate_limited中的=表示内部重定向（不改变状态码），否则会变成 302 跳转 -
add_header必须写在location @rate_limited内，写在外部 location 不生效 - JSON 字符串里的双引号必须用反斜杠转义，否则 Nginx 配置解析失败
- 若需动态插入
Retry-After值（如从限流模块获取），return无法做到，得换方案
需要动态 Retry-After 或更复杂 JSON 时用 Lua（OpenResty）
原生 Nginx 无法读取限流模块的剩余等待时间，OpenResty 的 resty.limit.count 或 ngx.shared.DICT 可以捕获并注入响应：
location /api/ {
access_by_lua_block {
local limit = require "resty.limit.count"
local lim, err = limit.new("api", 10, 1) -- 10r/s
if not lim then
ngx.log(ngx.ERR, "failed to instantiate a resty.limit.count object: ", err)
return
end
<pre class="brush:php;toolbar:false;"> local key = ngx.var.binary_remote_addr
local delay, err = lim:incoming(key, true)
if err then
if err == "rejected" then
ngx.status = 429
ngx.header["Content-Type"] = "application/json; charset=utf-8"
ngx.header["Retry-After"] = "60"
ngx.say('{"code":429,"message":"Rate limit exceeded","retry_after":60}')
ngx.exit(429)
end
end
}}
- 必须使用 OpenResty（非标准 Nginx），且启用
lua_shared_dict用于计数器共享 -
lim:incoming返回的delay是毫秒级等待时间，可转换为Retry-After秒值（向上取整） - 注意
ngx.say和ngx.exit的组合才能确保响应体和状态码同时生效 - 性能开销略高于原生
limit_req，高并发下需压测验证
为什么不要用 proxy_pass 到后端处理 429？
看似灵活，但实际引入严重问题：
- 限流本应在接入层快速失败，proxy_pass 会把请求透传到上游，浪费后端资源
- 后端需额外识别 Nginx 注入的 header（如
X-RateLimit-Limit）来判断是否被限，逻辑耦合加重 - 若后端也做限流，会出现双重限流或策略冲突，调试困难
- 无法保证
Retry-After值与 Nginx 限流窗口严格一致（比如 burst 消耗完后的等待时间）
真正需要后端参与的场景，通常是带用户维度的复杂配额（如 per-user + per-app 组合限流），这时应放弃 limit_req，改用 OpenResty 或网关层统一实现。
