加权轮询中，weight、max_fails和fail_timeout是并列配置项，各自独立生效；每个server可差异化设置fail_timeout以适配自身稳定性，节点被标记为不可用时weight暂失效，恢复后重新参与加权调度。
加权轮询本身不带故障隔离能力，要让权重分配和节点故障处理协同工作，关键不是“结合”两个独立机制，而是把 max_fails 和 fail_timeout 直接写在每个 server 行后面——权重和健康策略是并列配置项，各自生效、互不干扰。
加权轮询中每个节点可独立设置 fail_timeout
你不需要为整个 upstream 统一设定惩罚时间。每个后端服务器可以按自身稳定性单独配置 max_fails 和 fail_timeout，同时保留自己的 weight 值：
-
server 192.168.1.10:8080 weight=5 max_fails=2 fail_timeout=20s;—— 高性能且稳定的节点，失败容忍低、恢复快 -
server 192.168.1.11:8080 weight=2 max_fails=5 fail_timeout=60s;—— 性能较弱或跨机房链路，允许更多失败、更长冷却期 -
server 192.168.1.12:8080 weight=1 max_fails=1 fail_timeout=5s;—— 实时性要求高但易抖动的服务，快速摘除也快速试探
这样，权重决定流量比例，fail_timeout 决定该节点出问题后被跳过的时长，两者在调度逻辑中自然共存。
fail_timeout 的实际作用在加权场景下不变
即使启用了权重，fail_timeout 的行为逻辑完全一致：
- 它仍是滑动时间窗口：在最近
fail_timeout秒内，该节点失败 ≥max_fails次，就被标记为down - 标记后，Nginx 在接下来的
fail_timeout秒内完全不向它发请求，也不会计入权重计算 - 期满后，首个真实请求会试探打过去；成功则立即恢复参与加权调度，失败则重置计数、再等一个
fail_timeout
也就是说，节点一旦被标记为不可用，它的 weight 就暂时失效；恢复后，权重才重新参与流量分发。
必须配套启用 proxy_next_upstream 才能触发计数
只写 max_fails 和 fail_timeout 不起作用。必须在 location 块中显式开启错误传播：
proxy_next_upstream error timeout http_502 http_503 http_504;- 这样当 Nginx 遇到连接失败、超时或这些 5xx 状态时，才会尝试下一个 upstream server，并给当前失败节点累加计数
- 注意：
http_404默认不触发重试，除非业务明确需要（比如网关兜底逻辑）
超时参数需与 fail_timeout 对齐
如果 proxy_read_timeout 或 proxy_connect_timeout 设置得比 fail_timeout 还长，单次慢请求就可能直接拖满整个窗口，导致误判下线：
- 建议
proxy_connect_timeout ≤ fail_timeout / 3（例如fail_timeout=30s，则设为5s） -
proxy_read_timeout设为fail_timeout / 2左右（如15s），确保读超时能及时上报失败 - 所有超时值都要小于
fail_timeout，否则健康检查机制会失灵
