Nginx 安全控制：如何利用 limit_req_status 定制接口遇恶意刷流时的降级响应码

应将限流响应状态码设为429并配合error_page返回JSON，因429语义明确、符合RFC标准且利于客户端识别；仅设limit_req_status不配置error_page会导致空响应；配置须同作用域且需实测验证。

直接用 limit_req_status 把限流响应从默认的 503 改成 429，再配合 error_page 返回结构化 JSON 提示，是最清晰、最易被客户端识别的降级方式。

明确限流状态码语义：优先选 429

限流不是服务不可用，而是客户端请求过频。用 429（Too Many Requests）比 503 更准确，也符合 RFC 6585 标准，主流 SDK 和重试逻辑会自动识别并读取 Retry-After 头进行退避。

• 429 是推荐首选，语义明确，利于前端和网关统一处理
• 403 可用于“免费用户额度耗尽”等权限类场景
• 444 适合强风控拦截——不返回任何响应体，直接断连（静默丢弃）
• 避免混用 503，否则监控里难以区分是限流还是后端宕机

只设 limit_req_status 不够：必须配 error_page 返回 JSON

limit_req_status 429 只改状态行，不生成响应体。若不额外配置，客户端收到的是空的 429 响应，无法解析错误原因。

• 加 error_page 429 = @rate_limited 拦截该状态码
• 定义 location @rate_limited 并标记 internal（禁止外部直访）
• 用 add_header Content-Type "application/json; charset=utf-8" 显式声明类型
• 用 return 429 '{"code":429,"message":"Rate limit exceeded","retry_after":60}' 输出标准 JSON

配置位置必须严格匹配作用域

这条指令不会继承，也不跨层级生效。写错位置等于没写。

• ✅ 正确：limit_req 和 limit_req_status 都在同一个 location /api/ { ... } 块内
• ❌ 错误：limit_req 在 location 里，limit_req_status 却写在 server 块顶层
• ⚠️ 注意：多个 limit_req 共存时，当前作用域下的 limit_req_status 对全部生效

验证是否生效的实操要点

别只看配置文件，得用真实请求确认行为。

• 用 curl -I http://your-api/path 看响应头第一行，确认是 HTTP/1.1 429
• 高频触发限流（如 ab -c 20 -n 50），避免因未真正超限而返回 200
• 清除浏览器缓存或换 curl 测试，防止旧 503 被缓存误导判断
• 执行 nginx -t && nginx -s reload 后再验证，配置热加载必须成功