Nginx权重是静态容量锚点而非动态流量开关，需结合least_conn、max_conns、主动健康检查及外部动态调权机制（如Consul/Lua/API）实现真实自适应负载均衡。
权重调节本身不能实时响应后端性能波动——Nginx 的 weight 是静态参数，配置加载后即固化，不会随 CPU、响应时间或连接数变化而自动调整。真正有效的做法，是把“权重”作为容量锚点，再叠加动态机制来实现按需调控。
用 weight 做容量基线，不是流量开关
权重本质是表达服务器相对处理能力的标尺。比如一台 16 核机器设 weight=8，一台 8 核设 weight=4，它们在加权轮询下理论承接比例为 2:1。这比直接写死“分 70% 流量给 A”更可持续——只要硬件规格不变，权重就不需频繁改。
- 新节点上线时，先设较低权重（如
weight=1），观察稳定性后再逐步提升 - 老节点降级维护前，可临时调低权重（如从 5 降到 2），让流量自然倾斜，避免 abrupt cut
- 避免极端值：
weight=100和weight=1并不比weight=10和weight=1更“精确”，反而易放大误差
搭配 least_conn 缓解瞬时负载不均
当后端存在长耗时请求（如模型推理、报表导出），仅靠权重会失灵——某台高权重点正处理 5 个慢请求，连接堆积，但轮询仍持续派发新请求。此时启用 least_conn 能即时绕过繁忙节点。
- 配置中同时保留
weight和least_conn：Nginx 先按权重划分“应得份额”，再在同权重组内选连接数最少者 - 配合
max_conns限制单机并发上限，防止某节点被突发流量打穿 - 务必开启主动健康检查（如
health_check interval=3 fails=2 passes=2），否则卡住的节点无法及时剔除
真动态调权必须借外力
Nginx 自身不支持运行时改 weight。要实现“性能变差→自动降权”，需引入外部协同机制：
- Consul + nginx-upsync-module：把各节点实时 P95 延迟和权重存入 Consul KV；Nginx 每 300ms 拉取更新，毫秒级生效
-
OpenResty + Lua：用
lua_shared_dict存各节点延迟指标，在balancer_by_lua_block中按公式weight = base × (ref_rt / actual_rt)²实时计算并选节点 -
nginx-upstream-dynamic-servers + HTTP API：通过 POST 接口（如
curl -X POST /upstream/servers -d '{"server":"192.168.1.11","weight":6}'）由 Prometheus 告警脚本驱动调权
监控闭环才是关键落地环节
没有可观测性，权重调整就是盲调。重点看三类指标：
-
后端活跃连接数：通过
stub_status或 Prometheus exporter 查nginx_upstream_active_connections，持续接近max_conns说明已到瓶颈 -
响应时间拆解：对比日志中的
$upstream_header_time（后端响应头到达时间）和$upstream_response_time（完整响应时间），判断延迟来自网络、Nginx 还是后端业务 -
错误分布：统计
$upstream_http_x_backend_status或$upstream_status，若某节点 502/504 集中出现，应优先降权而非加权
