Nginx开源版不内置fair算法，需通过least_conn、健康检查与权重动态调整等原生机制实现近似公平调度；推荐结合keepalive、proxy_read_timeout和limit_req优化API场景尾延迟。
确认 fair 算法是否可用
Nginx 开源版默认不支持 fair 指令。它属于第三方模块 upstream_fair，需手动编译安装。若你使用的是标准发行版（如 Ubuntu 官方包、CentOS Stream 的 nginx），该指令直接写入配置会报错：unknown directive "fair"。
验证方式：运行 nginx -V 2>&1 | grep -o with-http_upstream_fair_module，无输出即未启用。
替代方案更主流且稳定：优先采用原生 least_conn 或结合健康检查 + 权重动态调整的策略。
用原生 least_conn 实现近似公平
最少连接（least_conn）虽不看响应时间，但在长连接、高并发场景下，天然倾向将新请求导向当前负载最轻的节点——这与“响应快→连接释放快→空闲连接多”的实际表现高度一致。
- 适用于 WebSocket、gRPC、大模型 API（如 vLLM 接口）等连接生命周期较长的服务
- 配置简单，无需额外模块：
upstream api_backend {<br> least_conn;<br> server 10.0.1.10:8000 max_fails=3 fail_timeout=30s;<br> server 10.0.1.11:8000 max_fails=3 fail_timeout=30s;<br>} - 配合
max_fails/fail_timeout可自动剔除临时卡顿或超时节点，间接保障调度质量
用加权轮询 + 主动健康检查模拟响应感知
若后端响应时间差异显著且相对稳定（例如 A 节点平均 RT=50ms，B 节点 RT=200ms），可人工设定权重比（如 weight=4:1），再通过定期探针反馈动态 reload 配置（需脚本辅助）。虽然非实时，但比纯轮询更贴近公平目标。
更实用的做法是启用 被动健康检查，让 Nginx 自动降权慢节点：
- 在
server行中添加max_fails=2 fail_timeout=10s，连续两次超时即暂停调度 10 秒 - 搭配
proxy_next_upstream error timeout http_500;，使失败请求自动转发至下一节点 - 结果：慢节点被快速“冷落”，快节点自然承接更多流量
对 API 场景的特别建议
面向 API 的公平调度，重点不在算法名称，而在降低尾延迟、避免雪崩。推荐组合配置：
- 启用 keepalive 连接池：减少 TCP 建连开销，放大后端真实处理差异
- 设置合理的 proxy_read_timeout（如 60s），防止单个慢请求阻塞整个连接
- 用 limit_req 控制突发流量，避免某节点因瞬时洪峰拖垮整体响应能力
- 若需强响应时间感知，建议在业务层埋点 + Prometheus + Grafana 监控 RT，再通过 Operator 自动调整 weight 并 reload
