权重算法需与max_fails和fail_timeout协同实现动态健康决策，高权重节点故障时会被标记down并退出轮询，恢复后权重立即生效；必须启用proxy_next_upstream才能闭环重试机制。
权重算法本身不感知健康状态，必须和 max_fails 与 fail_timeout 协同，才能让高权重节点在异常时被临时“降权”甚至剔除，避免流量持续打到故障节点。
权重不是静态分配，而是动态参与健康决策
设置 weight=10 的节点，不代表它永远接收 10 倍流量。只要它在 fail_timeout 时间窗口内累计失败达到 max_fails 次，Nginx 就会把它标记为 down——此时权重完全失效，所有请求自动跳过它，直到冷却期结束并试探恢复。
- 权重只在“可用节点池”中起作用；一旦被标记为 down，就退出轮询队列，权重归零
- 恢复后重新加入，权重立即生效，无需重启或重载配置
- 多个节点权重不同但都配置了
max_fails/fail_timeout，故障隔离是独立判断的，不会互相影响
合理搭配权重与健康参数，避免“高权重拖垮集群”
高权重节点若响应慢或易出错，反而会放大故障影响。需根据其服务能力同步调优健康参数：
- 对核心服务（如支付网关）设高权重（
weight=20），但同时收紧健康敏感度：max_fails=1、fail_timeout=5s，确保秒级摘除 - 对缓存类后端（Redis 集群）设中等权重（
weight=5），配合快速响应特征：max_fails=2、fail_timeout=10s - 对慢接口（报表导出）设低权重（
weight=1），并放宽健康窗口：max_fails=2、fail_timeout=60s，防止长耗时请求误触发踢出
必须启用 proxy\_next\_upstream 才能让权重+健康检查真正闭环
仅靠 max_fails/fail_timeout 只能“事后屏蔽”，不能解决当前请求失败问题。用户仍可能打到刚宕机但尚未被标记的节点上。这时权重再高也没意义——流量卡住了。
- 在
location块中明确写：proxy_next_upstream error timeout http_500 http_502 http_503 http_504 - 限制重试次数：
proxy_next_upstream_tries 3（最多换 2 台，含原节点） - 控制重试总耗时：
proxy_next_upstream_timeout 10s，避免用户等待过久 - 注意：
proxy_next_upstream默认关闭，不配置等于没开健康重试
验证是否生效：看日志 + 看 upstream_addr
配置完别只信语法检查，要实测确认行为符合预期：
- 开启
error_log /var/log/nginx/error.log info，观察是否出现upstream timed out或now down提示 - 停掉一台高权重后端，用
curl -I连续发请求，检查access_log中upstream_addr字段是否不再出现该节点 IP - 等待
fail_timeout秒后，再发请求，确认是否自动试探恢复并重新出现在upstream_addr中
