Nginx权重是静态配置，不支持自动调度；需通过采集层、决策层、执行层协同实现动态调整；least_conn和健康检查是更实用的替代方案。
Nginx 本身不支持“自动调度”，权重（weight）是静态配置项，加载后即固化，不会随接口响应时间、错误率或并发数变化而实时调整。所谓“自动”，必须依赖外部机制协同完成——把 weight 当作容量锚点，再叠加可观测性与动态执行能力。
权重是基线，不是开关
设 server 10.0.1.10 weight=6，本质是声明这台机器理论处理能力约为 weight=2 节点的 3 倍。它适合长期稳定的硬件差异场景（如 16 核 vs 8 核），但不适合应对突发抖动或性能衰减。新节点上线建议从 weight=1 起步，验证后再逐步调高；维护前可临时降至 weight=2，让流量自然倾斜，避免硬下线。
纯 Nginx 配置只能做到“按比例分发”
例如：
upstream api_backend {
server 10.0.1.10:8000 weight=5;
server 10.0.1.11:8000 weight=3;
server 10.0.1.12:8000 weight=2;
}总权重为 10，三台机器理论承接比例为 50% / 30% / 20%。这个比例在 reload 后固定生效，不感知任何运行时状态。
真要实现“自动”调度，得靠三层配合
-
采集层：从各后端暴露
/health或/metrics接口，定时上报 P95 延迟、错误率、活跃连接数（可用 Prometheus + Exporter） -
决策层：用 Python/Go 脚本拉取指标，按公式算出建议权重（如
weight = max(1, round(10 × (100 − cpu_pct) / 100 × 200 / p95_ms))），输出整数 1–10 -
执行层：生成新 upstream 配置，执行
nginx -t && nginx -s reload；或用 OpenResty 的shared_dict+balancer_by_lua_block实现零 reload 切换
更轻量、更实用的替代方案
如果目标是让慢接口请求“自动绕开繁忙节点”，直接启用 least_conn 比调权重更有效：
upstream api_backend {
least_conn;
server 10.0.1.10:8000 max_fails=3 fail_timeout=30s;
server 10.0.1.11:8000 max_fails=3 fail_timeout=30s;
}它不改权重，但每次选当前连接最少的节点，天然适配长耗时请求（如导出、模型推理），且无需额外开发。
健康检查不能省
无论是否调权重，都必须配 max_fails 和 fail_timeout，否则宕机节点仍会持续收请求。建议：
- 内网节点：
max_fails=2 fail_timeout=10s（快速剔除） - 公网节点：
max_fails=3 fail_timeout=15s（容忍网络抖动） - 可加
backup标记灾备节点，仅当全部主节点不可用时才启用
不复杂但容易忽略
