应将限流响应状态码设为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后再验证，配置热加载必须成功
