nginx 的 weight 参数仅静态按比例分发请求，不感知物理机或虚拟机实际负载；应基于应用层指标（如 p95 延迟、可持续 qps）动态设定权重，并配合健康检查与外部监控实现负载联动。
Nginx 的 weight 参数本身不感知物理机负载，也不读取虚拟机所在宿主机的 CPU、内存或 IO 使用率。它只做静态请求计数分发——也就是说，无论后端是物理机还是虚拟机，Nginx 都只按你写的 weight 值比例派发请求，完全不关心底层资源水位。
所以，“根据物理机负载配置权重”这个想法在 Nginx 原生机制里无法直接实现。但你可以通过合理设计，让权重间接反映真实承载能力，尤其当后端跑在虚拟机上时，需更谨慎处理。关键不是“抄物理机指标”，而是用可测、可观、可复现的应用层指标来反推虚拟机的实际服务能力。
权重应基于虚拟机实际响应能力，而非宿主机资源
虚拟机的性能受多种因素影响：宿主机资源争抢（CPU steal time、内存 balloon）、磁盘 IO 共享、网络带宽隔离、甚至 hypervisor 调度策略。单纯看宿主机 top 里的 CPU 80%，不能说明这台 VM 就该降权——它可能只是被隔壁 VM 抢占了时间片，而自身应用仍很轻快。
✅ 正确做法是：
- 在每台虚拟机上部署相同版本、相同配置的应用服务
- 对同一业务接口（如
/api/health或核心查询路径）发起标准化压测 - 记录稳定状态下的 P95 延迟 和 可持续 QPS（非峰值）
- 以其中一台为基准（比如 P95 = 100ms），其余 VM 权重 = 基准 P95 ÷ 自身 P95（四舍五入为整数）
举例：VM-A（P95=100ms）→ weight=1；VM-B（P95=180ms）→ weight≈0.56 → 取整为 1；VM-C（P95=75ms）→ weight≈1.33 → 取整为 1。三台都设 weight=1，说明它们当前实际响应能力接近，强行配成 3:1:2 反而失衡。
宿主机高负载时，需靠外部机制兜底，而非调 weight
如果某台宿主机整体过载（如 CPU steal > 15%、iowait > 30%），其上的所有 VM 都可能变慢。这时：
- Nginx 单靠 weight 无法感知，必须配合被动健康检查（
max_fails=3 fail_timeout=30s） - 同时在 upstream 中启用
proxy_next_upstream error timeout http_503，让失败请求自动 fallback - 更进一步，可接入外部探活：比如用 Consul 或 Prometheus Alert 触发脚本，临时给对应 VM 的 upstream server 行加
down标记，或通过 Lua 动态修改 weight（需 openresty）
虚拟机场景下特别要注意的配置细节
- 避免 weight 极端化：比如宿主机差异大就设 8:1 —— 这会让低权 VM 长期空转，高权 VM 一旦抖动就雪崩。建议最大比值控制在 4:1 以内（如 4:2:1）
- 所有 VM 的 weight ≥ 1：防止某台因瞬时抖动被完全跳过，失去故障恢复机会
-
禁用 weight=0：它不参与分发，但仍在健康检查中被探测，运维难察觉是否真宕机。要用
backup标记备用 VM，而不是设 weight=0 -
连接复用必须开：upstream 内加
keepalive 32，proxy 区域配proxy_http_version 1.1和proxy_set_header Connection ''，减少 VM 上频繁建连带来的额外开销
真正有效的“物理层联动”方式（非 Nginx 原生）
如果你确实需要根据宿主机负载动态调权，可行路径是：
- 在宿主机部署 exporter（如 node_exporter + vmware_exporter / libvirt_exporter）
- 用 Prometheus 监控 CPU steal、memory pressure、disk wait
- 编写轻量脚本：当某宿主机指标超标时，自动更新 Nginx 配置中的对应 VM weight（或下发
down）并 reload - 或使用 OpenResty + Lua + shared dict，定期拉取指标，运行时微调 upstream 权重（需 careful 测试）
不复杂但容易忽略。
