nginx api频率管控需基于身份标识（如x-api-key或jwt解析的sub）定义limit_req_zone，避免仅用ip限流；限流须在proxy_pass前生效，联动upstream健康检查与重试；拒绝响应应返回429 json格式，并灰度验证。
在 Nginx 上对 API 调用做频率管控，核心是结合 limit_req 模块与合理的 key 定义，再配合 upstream 实现负载均衡。这不是单纯限流，而是“带负载分发的受控限流”——既要防刷、保后端稳定，又不能把合法流量误杀或集中压垮某台节点。
定义基于用户标识的限流规则
直接按 IP 限流容易误伤（如企业出口 NAT）、也难区分真实调用者。更稳妥的做法是提取请求头中的身份标识（如 X-Api-Key 或 Authorization）作为限流 key：
- 在 http 块中声明限流区域：
limit_req_zone $http_x_api_key zone=api_perkey:10m rate=10r/s; - 若使用 JWT，可用 Lua 模块（如 lua-resty-jwt）解析 token 并提取 sub 或 client_id，再 set 到变量供 limit_req_zone 使用
- 避免用 $remote_addr 单独限流；如需兜底，可叠加一层 IP 限流（zone=api_perip），但速率设得宽松些（如 100r/m）
将限流与 upstream 负载均衡联动
限流发生在 Nginx 接入层，不直接影响 upstream 分发逻辑，但需注意两点协同：
- 限流规则必须放在 server 或 location 块中，且在 proxy_pass 之前生效；被限流的请求不会进入 upstream
- upstream 配置本身无需改动，但建议启用健康检查（如 health_check）和重试机制（proxy_next_upstream error timeout），确保某台后端异常时流量自动转移
- 若需按服务维度差异化限流（如 /v1/pay 限 5r/s，/v1/user 限 50r/s），为每个 location 单独配置对应的 limit_req，并指向不同 zone
处理限流拒绝后的用户体验
默认返回 503，对 API 不友好。应返回标准错误码和提示：
- 用 limit_req_status 429 将状态码改为 429 Too Many Requests
- 搭配 error_page 429 返回 JSON 格式响应：
error_page 429 = @rate_limited;<br>location @rate_limited {<br> add_header Content-Type "application/json";<br> return 429 '{"error":"rate_limit_exceeded","retry_after":60}';<br>} - 可选：通过 limit_req_log_level warn 记录被限流详情，便于后续分析高频调用来源
验证与渐进式上线
上线前务必实测，避免规则过严导致业务中断：
- 用 ab 或 wrk 模拟多客户端并发调用，观察日志中 429 出现时机是否符合预期
- 先对非核心接口灰度开启，监控 Nginx 的 limit_req 拒绝计数（通过 stub_status 或 Prometheus exporter）
- 生产环境建议开启 limit_req burst=20 nodelay 缓冲突发流量，但 burst 值需根据后端处理能力评估，不宜过大
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
