nginx防止单个后端被冲垮需限流与负载均衡协同：按接口路径分设限流zone并绑定独立upstream；用真实身份（如x-api-key或jwt）限流，辅以ip兜底；结合健康检查（max_fails/fail_timeout）、max_conns和proxy_next_upstream实现连接与失败双保险；依业务特征选用least_conn、weight或ip_hash调度策略。
用 Nginx 防止单个后端被瞬时冲垮，关键不是“堆服务器”，而是让负载均衡和限流协同工作：限流先筛掉超量请求，负载均衡再把合规流量合理分发——两者必须按接口、按身份、按能力联动，否则容易误杀或漏防。
按接口路径拆分限流 + 独立 upstream
不同接口承受压力的能力差异很大。比如登录接口怕暴力破解，报表接口允许偶发延迟。不能所有请求共用一个限流池，否则宽松规则保护不了敏感接口，严格规则又会卡住正常业务。
- 在 http 块里为每个关键路径定义专属限流 zone，例如：
limit_req_zone $http_x_api_key zone=login_limit:10m rate=5r/s;<br>limit_req_zone $http_x_api_key zone=report_limit:10m rate=2r/s;
- 对应 location 块绑定限流 zone 并指向专用 upstream：
location /api/v1/login { limit_req zone=login_limit burst=10; proxy_pass http://auth_backend; }<br>location /api/v1/report { limit_req zone=report_limit burst=5; proxy_pass http://data_backend; } - upstream 按服务类型隔离，便于单独扩缩容和健康检查：
upstream auth_backend { server 192.168.2.10:8001; server 192.168.2.11:8001; }<br>upstream data_backend { server 192.168.2.20:8002 weight=2; server 192.168.2.21:8002; }
用真实身份限流，别只靠 IP
单靠 $binary_remote_addr 在 NAT 或 CDN 场景下极易误伤——上百用户可能共享一个出口 IP。企业级防护必须识别调用方本身。
- 优先从请求头提取唯一标识，如
X-Api-Key或 JWT 的sub字段：limit_req_zone $http_x_api_key zone=api_perkey:10m rate=10r/s; - 若需解析 JWT，配合
lua-resty-jwt模块，在access_by_lua_block中解出 client_id 并 set 到变量，再供限流模块使用 - 保留一层宽松的 IP 限流兜底（如
100r/m），防止无 key 的扫描行为绕过主策略
给后端加连接与失败双保险
限流管“进”，健康检查管“活”。光限制请求速率不够，还得确保 Nginx 不把请求打到已卡死但还没彻底断连的节点上。
- 设置
max_fails和fail_timeout实现轻量主动规避：server 192.168.1.10:8080 max_fails=2 fail_timeout=30s;
表示 30 秒内连续失败 2 次即剔除，30 秒后自动重试 - 用
max_conns控制单台后端最大活跃连接数，避免弱机被压穿：server 192.168.1.11:8080 weight=1 max_conns=200;
达到上限后 Nginx 自动跳过该节点 - 搭配
proxy_next_upstream error timeout http_500，让一次失败请求能自动转发到其他可用节点
选对调度策略，避免平均主义失衡
轮询（round-robin）在机器配置不均时反而加剧负载倾斜。要根据业务特征选策略：
- 长连接、耗时接口多（如文件上传、WebSocket），用
least_conn，它基于当前活跃连接数分配，更贴近真实压力 - CPU/内存明显不同的机器混用时，显式设
weight，比如 8C16G 的机器设weight=2，4C8G 的设weight=1 - 需要会话保持的场景（如老系统未做无状态改造），用
ip_hash，但注意它会削弱负载均衡效果
