weight与fail_timeout协同实现按能力分发和故障快速隔离：weight决定健康节点流量比例，fail_timeout配合max_fails控制故障标记与恢复节奏，二者联动优化节点恢复阶段的负载再平衡。

在 Nginx 负载均衡中，weight 和 fail_timeout 不是孤立参数，它们协同工作才能实现“按能力分发 + 故障快速隔离”的合理调度策略。只设 weight 不管失败恢复，或只设 fail_timeout 忽略节点性能差异，都会导致流量分配失衡或服务不可用。

weight 决定正常情况下的流量比例

weight 是 upstream 中 server 的权重值，默认为 1。数值越大，Nginx 在轮询（默认策略）中分配到该节点的请求越多。它不改变调度算法本质，只是调整概率分布。

• 两个后端：A（weight=3）、B（weight=1），理论流量比约为 3:1
• weight 只在节点健康时生效；一旦被标记为“down”或“unavailable”，weight 暂时失效
• weight 不是绝对请求数控制，无法保证精确 75% 流量到 A，但长期统计趋近该比例

fail_timeout 控制故障识别与恢复节奏

fail_timeout 定义两个行为：一是连续失败多少秒后将节点标记为不可用；二是标记为不可用后，多久尝试恢复探测。它必须配合 max_fails 使用（默认 max_fails=1）。

• 示例：server 192.168.1.10:8080 weight=2 max_fails=3 fail_timeout=30s;
  表示：30 秒内连续失败 3 次，就将该节点置为不可用；之后每隔 30 秒发起一次健康探测，成功则重新纳入负载池
• fail_timeout 过短（如 5s）会导致短暂网络抖动就剔除节点，引发频繁震荡
• fail_timeout 过长（如 300s）会让故障节点长时间滞留，影响整体可用性

weight 与 fail_timeout 配合的关键逻辑

二者真正联动发生在“节点恢复阶段”：高 weight 节点故障后，流量会瞬间压向其他节点；若其 fail_timeout 设置合理，能更快恢复并承担更多压力；反之，低 weight 节点即使恢复，也因权重小而难以分担回流压力。

• 建议对高性能节点（如 SSD+多核）设更高 weight，并配稍短的 fail_timeout（如 20s），加快故障响应与回归
• 对资源受限节点（如老旧虚拟机），weight 设低（如 1），fail_timeout 可略长（如 40s），避免频繁进出集群造成抖动
• 所有节点的 fail_timeout 值不必统一，应根据各自稳定性特征差异化设置

验证与调优提示

上线后不能只看配置是否生效，要观察实际效果：

• 用 nginx -t 检查语法，reload 后通过 curl -I 或日志确认请求是否按预期分发
• 模拟某节点宕机（如 systemctl stop app），观察 access.log 中其他节点请求激增是否平滑，以及该节点是否在 fail_timeout 后自动恢复
• 开启 Nginx 状态模块（stub_status）或配合 Prometheus + nginx-vts-exporter，实时查看各 upstream server 的请求计数、失败次数和当前状态