单纯调低weight不能真正限流，必须协同健康检查与max_conns：weight控制长期流量占比（如1/(5+4+1)=10%），max_fails=2 fail_timeout=15s实现故障自动剔除，max_conns=3+queue 10 timeout=8s限制并发并缓冲洪峰。
单纯调低 weight 并不能真正实现“限流”，它只改变流量分发比例，不阻止连接堆积或突发冲击。要让一台低性能机器既保持在线、又不被压垮，必须把权重当作“长期分流倾向”，再叠加健康检查和连接数硬控——三者缺一不可。
用低权重控制长期流量占比
比如后端有三台节点：
– 高配 A：weight=5
– 高配 B：weight=4
– 低配 C：weight=1
那么 C 的理论长期流量占比是 1/(5+4+1) = 10%。这能缓解压力，但不代表安全——只要它一直健康，Nginx 就会持续往它身上发请求，哪怕响应变慢、队列拉长。
靠健康检查避免故障时继续导流
低配机容易因负载高而响应延迟或超时，必须让它能被自动识别并临时下线：
- 配置
max_fails=2 fail_timeout=15s，连续失败 2 次就剔除 15 秒 - 剔除期间，所有流量自动由 A 和 B 按新权重（5:4）重新分配
- 恢复后自动回归，无需人工干预
没有这步，weight 再低也挡不住慢节点持续收请求。
用 max_conns 主动掐住并发入口
这是真正防止压垮的关键一步。在 upstream 中为低配节点显式加限：
server 192.168.1.10:8080 weight=1 max_conns=3;- 超出 3 个并发连接的请求，直接排队或返回 503（取决于是否配 queue）
- 这个值要结合应用实际能力设，比如 Java 应用线程池只有 5 个，max_conns 就不宜超过 3～4
加 queue 缓冲瞬时洪峰更稳妥
光靠 max_conns 容易直接拒掉请求，加 queue 可平滑过渡：
max_conns 3; queue 10 timeout=8s;- 最多允许 3 个请求同时处理，10 个排队等待，超 8 秒没被调度就返回 503
- 特别适合冷启动、数据库连接池未填满等响应暂时偏慢的场景
这样组合下来，低配节点既不会被瞬间打满，也不会完全失联，运维可控性更强。
