Nginx单IP每秒限10次，共享出口误封让429持续攀升

ServLlamav2.0.0-alpha.2 服务器管理

类型：系统工具大小：55.1M语言：英语评分：10.0
标签：

立即下载

某电商把 Nginx 放在 CDN 和负载均衡之后，促销开始后 429 突增：同一办公室多人被当作一个 IP 封掉，匿名流量绕开用户配额，重试客户端又同时回压入口。若直接信任 X-Forwarded-For，访客还能伪造地址。限流不能只看一个 rate：先定限流键，再校准令牌桶、代理信任边界和 429 退避。

如果你正在选机器，或者想先把线路和配置跑通再谈长期方案，可以先看看这几家的线路说明和技术参数：cstserver（海外服务器），先看清带宽线路、流量策略和退款条款，再决定要不要迁。

一、限流键决定谁受限：IP、用户、接口各管一层

限流键就是计数桶的归属，键选错，参数再大也无济于事。

按 IP用 $binary_remote_addr 归桶，适合拦住来源明确的批量请求。企业 NAT、校园网和运营商出口会让多人共用一个桶，所以它保护的是连接来源，不是用户公平配额。

按用户应以鉴权后的用户 ID 或 API Key 哈希归桶，不能相信客户端提交的 tenant_id；未登录流量再回退到 IP。使用 ServLlama 统一承接模型 API 请求时，也可把令牌所属主体或模型路由加入键，避免单一账号拖垮共享队列。

Nginx单IP每秒限10次，共享出口误封让429持续攀升

按接口应使用规范化路由，如把 /v1/models/123 收敛为 /v1/models/{id}。原样使用 $uri 会漏掉同接口不同参数，只按固定前缀又可能误伤其他业务，高成本接口应单设配额。

判断方法是先列出调用者，再确认保护对象：匿名、登录用户还是共享出口？保护来源、主体还是昂贵操作？常见做法不是三选一，而是 IP 防洪、用户限配额、热门接口再设独立桶；多个 zone 同时命中时，每个键都必须通过。

二、参数、真实 IP 与 429 要连成一条链

令牌桶按固定速率补充令牌，桶容决定可吸收的突发。Nginx 开源版 limit_req 实际采用漏桶式核算，不能当作严格令牌桶：rate=10r/s 是持续速率，burst=20 是可瞬时通过的额外请求量，nodelay 表示不排队，桶满即 429；zone 中的 10m 只是状态内存，多节点不会自动共享额度。

limit_req_zone $binary_remote_addr zone=ip10:10m rate=10r/s;
limit_req zone=ip10 burst=20 nodelay;
limit_req_status 429;
add_header Retry-After 1 always;

若业务要求严格令牌桶，可设定每秒补充 10 个、容量 20 个，并用 Redis Lua 原子完成补充与扣减；集群中仍应使用同一参数和时钟基准。

Nginx单IP每秒限10次，共享出口误封让429持续攀升

代理真实 IP要先信任代理出口网段，再重写远端地址。下面示例的 10.20.0.0/16 必须替换为 CDN 或负载均衡的实际出口 CIDR；只有上游保证覆盖写入时，才改用 X-Real-IP。不要信任任意来源头，也不要直接拿 $http_x_forwarded_for 归桶。改写后 $remote_addr 及其二进制形式是客户端地址，$realip_remote_addr 保留最初连接者，便于审计。

set_real_ip_from 10.20.0.0/16;
real_ip_header X-Forwarded-For;
real_ip_recursive on;

429 退避不能只让客户端立刻重试。服务端用 Retry-After 给出最小等待时间，客户端第 n 次从零计数，在 [Retry-After, min(30秒, Retry-After+2^n秒)] 区间随机取值，形成带抖动的指数退避，最多重试 3 次；非幂等写请求默认不重放。固定等待会造成同时回醒的尖峰，无上限重试会把 429 放大成流量风暴。上线前应分别模拟共享出口、伪造头和长代理链，核对误封率、剩余额度与重试放大率。

令牌桶算法、漏桶算法与限流键维度

令牌桶算法按速率补充令牌，请求消耗令牌，余额不足才拒绝；它允许有限突发，适合约束平均速率和短时峰值。桶容量过大会掩盖异常，过小则容易误伤正常抖动。多实例部署应由 API 网关或共享存储统一供桶，否则各节点额度相乘，总量会随节点数放大。

Nginx 开源版的 limit_req 更接近漏桶算法：按固定速率核算额度，burst 表示可接受的突发规模，默认会延迟超额请求；启用 nodelay 后，超额请求不再等待，但仍计入 burst。burst 不是无限免费额度，超过其容量仍会被拒绝。

限流键维度决定谁与什么资源共享额度。按 IP 限流适合防爬虫，按用户、租户或令牌限流适合业务配额，按接口或路由限流可保护昂贵下游。组合键更精确，却会提高键基数和误伤率；不要给接口设置全局额度，否则一个大客户即可拖慢所有用户。还要防止空变量让请求落入同一个键。

Nginx单IP每秒限10次，共享出口误封让429持续攀升

代理真实IP识别最常见的坑，是直接信任客户端传入的 X-Forwarded-For。只应通过 set_real_ip_from 声明可信代理网段，再设置 real_ip_header 和 real_ip_recursive，并核对 CDN、负载均衡器与 Ingress 的转发链。配置错误时，按 IP 限流可能只看到代理地址，令所有用户共用一个额度。

429重试退避与上线检查清单

429重试退避方面，可用 limit_req_status 429 返回限流状态，并携带 Retry-After 或统一业务错误码。客户端只对幂等请求重试，采用指数退避加随机抖动，设置单次上限和总重试预算；非幂等写请求应先查询结果或使用幂等键，不能盲目重试，否则服务恢复时可能形成重试风暴。

可执行检查清单：①运行 nginx -t 校验配置；②从直连、可信代理和伪造转发头三条路径核对日志中的客户端 IP；③用压测工具验证正常速率与突发流量下的延迟、拒绝比例；④用 curl 检查 429 状态码、Retry-After 和响应体；⑤模拟限流存储故障，确认拒绝、降级或本地兜底策略；⑥多节点环境明确限流作用域，防止单机额度相乘；⑦持续观察键基数、误杀率、拒绝量和上游延迟，并定期复盘阈值。

结论：可靠限流是“识别真实来源定义公平配额控制突发正确退避持续观测”的闭环。先以小流量和可回滚配置验证，再逐步收紧阈值，才能既守住后端容量，又不误伤正常用户。