Nginx原生不支持limit_req_status指令，限流默认返回503且不可直接修改；可通过error_page 503 =429配合自定义location实现等效429响应。
Limit\_Req\_Status 是什么，它真能改限流返回码？
不能。limit_req_status 这个指令根本不存在 —— Nginx 官方文档里查不到，所有稳定版本（1.18–1.25）都不支持该配置项。你看到的可能是拼写错误、第三方模块（如 nginx-limit-req-status）、或混淆了 limit_req 和 error_page 的组合用法。
真正生效的限流状态码由 limit\_req 决定，且固定为 503
当请求被 limit_req 规则拒绝时，Nginx 默认返回 503 Service Temporarily Unavailable，这个行为不可通过原生命令修改。原因在于限流发生在请求处理早期（rewrite 阶段前），尚未进入 error_page 重定向流程，所以：
-
error_page 503 =429 /@rate_limited这类写法对限流触发无效 -
limit_req_status不是 Nginx 内置指令，编译时加了非官方补丁才可能有 - 即使使用
limit_req nodelay burst=5，超限响应仍是硬编码的 503
绕过限制：用 error\_page + 自定义 location 模拟“改状态码”
虽然不能直接改限流返回码，但可通过拦截 503 并重写响应实现等效效果。前提是让限流失败最终落到可捕获的位置 —— 关键是把 limit_req 放在 location 块内，并配合 proxy_intercept_errors on（仅对 proxy 场景）或更通用的 error_page 回退路径：
# 示例：API 接口限流，希望超限时返回 429
location /api/ {
limit_req zone=api burst=10 nodelay;
limit_req_status 429; # ❌ 错误！这行会报 nginx: [emerg] unknown directive "limit_req_status"
<pre class='brush:php;toolbar:false;'># ✅ 正确做法：接受默认 503，再用 error_page 转发并覆盖
error_page 503 =429 @rate_limited;}
location @rate_limited { return 429 '{"error":"rate limited"}'; add_header Content-Type "application/json"; }
注意：error_page 503 =429 中的 =429 表示“内部重定向并强制使用 429 状态码”，不是转发；若去掉等号，就会变成 302 跳转，不符合 API 场景需求。
为什么有些文章说 limit\_req\_status 可用？
常见误导来源有三个：
- 把 OpenResty 的
resty.limit.countLua 模块行为当成 Nginx 原生功能 - 引用已废弃的第三方 patch（如 2014 年有人给 Nginx 1.7 提交过实验性 PR，未合入主线）
- 将
limit_conn_status（真实存在，用于连接数限制）和limit_req混淆 —— 后者确实没有对应 status 指令
如果你必须返回 429 且不想依赖 Lua，目前最稳妥的方式就是上面的 error_page 503 =429 @xxx 组合，但要注意它只在限流触发且当前 location 无其他 error_page 干扰时才可靠。实际部署前务必用 curl -I 验证响应头和状态码是否符合预期。
