weight参数仅影响新连接调度，不干预已建立连接的复用路径，因加权轮询只在新建TCP连接时生效，长连接持续走原后端，动态更新权重不触发断连或重定向。
Nginx 中的 weight 参数本身不会影响已建立的连接，无论是否动态更新——因为权重只参与新连接的初始选择，不干预已有连接的复用路径。
为什么现有连接完全不受影响
权重是加权轮询（weighted round-robin）算法在创建新 TCP 连接时使用的概率因子。一旦连接建立并被 Nginx 复用（如 HTTP/1.1 keepalive、gRPC 长连接），后续所有请求都会持续打到同一后端，与当前 weight 值无关。动态更新 weight 只改变下一次新建连接的倾向性，不触发断连、重定向或连接迁移。
动态更新的实际生效边界
- 新连接立即按新权重分配：比如将某节点 weight 从 2 调至 8，之后新建的连接会更大概率选它
- 长连接仍走原路径：已存在的 100 个连接不会因 weight 变化而重新分发
- 无 reload、无中断：所有成熟动态方案（如 upsync、dynamic-servers、OpenResty+Lua）都在内存中热更新，主进程和 worker 进程持续运行
- 健康检查照常执行：max_fails、fail_timeout 等机制独立于 weight，仍可实时摘除异常节点
需要注意的间接影响
虽然 weight 本身不扰动现有连接，但动态调整常伴随其他动作，可能间接波及：
- 若通过脚本把某节点 weight 设为 0，它不再接收新连接，旧连接逐步自然释放后，该节点流量归零
- 结合
max_conns或queue限流时，weight 更新后新连接可能更快触达队列上限，导致部分请求排队或返回 503 - 在 OpenResty 的
balancer_by_lua_block中，若逻辑包含主动断连（如检测到响应超时强制关闭连接），则会影响正在传输的请求——但这属于自定义行为，非 weight 本身所致
验证方式建议
可通过日志观察真实效果：
- 记录
$upstream_addr和$request_time，对比 weight 变更前后新请求的分布比例 - 用
ss -tnp | grep :8080查看各后端的 ESTABLISHED 连接数变化趋势，确认旧连接未被强制关闭 - 检查 access_log 中是否存在大量
502/504或连接重置标记，排除误操作引发的异常
