权重本身不是限流机制，仅影响请求分发比例；真正限流需权重+健康检查+max_conns三层协同，并辅以queue缓冲和灰度放量。
权重本身不是限流机制，它只是影响请求分发比例的静态倾向。想用 weight 实现“低性能节点限流”，本质是降低其承接流量的比例，但必须配合其他机制才能真正起到保护作用——否则权重再低，只要节点健康，仍会持续收请求，可能被压垮。
核心思路：权重 + 健康感知 + 连接控制
单纯设低 weight（比如 weight=1）只能让该节点分到更少请求，但无法阻止突发流量、慢响应或连接堆积。真正有效的“限流”需三层协同：
- 用低权重控制长期流量占比：例如三台节点中，低配机设 weight=1，高性能机设 weight=5 和 weight=4，长期来看它只承担约 10% 流量（1/(1+5+4)）
-
靠健康检查动态剔除不稳定状态：配置
max_fails=2 fail_timeout=15s，一旦连续失败就临时下线，weight 自动失效，剩余节点按新权重重新分担 -
用 max_conns 主动掐住并发入口：在低性能节点上加
max_conns 5;，超出连接直接排队或返回 503，避免线程/连接数过载
避免常见误区
很多人以为设个 weight=0 就是“限流”，其实它是完全隔离——不发请求、也不探测，等于下线。真要保留服务能力但限制强度，就不能用 weight=0，而应：
- 不依赖 weight 控制实时连接数（它不感知 CPU 或响应时间）
- 不和
ip_hash或least_conn混用，否则 weight 会被忽略 - 不单独调优 weight，必须和
fail_timeout、max_fails联动设置，否则故障时流量分配会失衡
补充防护：用 queue 缓冲瞬时洪峰
即使节点响应慢，也能避免请求直接失败。在 upstream 中为低性能节点启用排队：
-
max_conns 3;—— 最多同时处理 3 个请求 -
queue 20 timeout=10s;—— 允许最多 20 个请求排队，超 10 秒未被处理则返回 503
这个组合比单纯调 weight 更可靠，尤其适合 Java 应用冷启动、数据库连接池未填满等场景。
进阶：灰度式渐进放量
如果低性能节点偶尔需要扩容承载，又怕压垮，可模拟 slow_start：
- 初始 weight=1，并配合外部脚本，每 60 秒调 API 或 reload 配置，逐步升到 weight=3→5
- 或拆两个 upstream：
backend_low（weight=1）和backend_high（weight=5），用split_clients按时间或请求 ID 分流，实现可控导流
