Nginx 中怎么排查加权轮询中权重为零的节点被误调用的故障-Nginx-PHP中文网

权重设为0的节点本应被完全跳过，但若仍出现在$upstream_addr或error日志中，说明存在配置冲突（如混用max_fails）、重试机制触发、backup启用、hash指令覆盖或reload后连接池残留等隐性异常，需逐项排查。

nginx 中怎么排查加权轮询中权重为零的节点被误调用的故障

权重设为 0 的节点在 Nginx 中本应被完全跳过，不参与任何请求分发。但若它仍出现在 $upstream_addr 或 error 日志中，说明配置或运行时状态存在隐性异常，需从配置解析、健康检查干扰、动态变更残留三方面入手排查。

Nginx 不会报错也不警告 weight=0，但它要求该 server 行不能同时启用健康检查（如 max_fails），否则会忽略 weight=0 并尝试探测——导致“逻辑禁用”失效。检查 upstream 块：

执行 nginx -T | grep -A5 "upstream.*backend"，确认目标 server 行是否仅含 server 192.168.1.50:8080 weight=0;，不含 max_fails、fail_timeout 或 backup
若存在 max_fails=1 fail_timeout=10s，Nginx 会强制将其纳入健康检查队列，即使 weight=0，也会在探测失败后记录错误并可能触发重试路径
weight=0 的节点也不能标记为 down——down 和 weight=0 功能重叠但机制不同，混用易引发行为冲突

weight=0 节点被调用，通常不是“主动选中”，而是被动卷入。重点看两类日志模式：

Nginx Hosting

通过服务器本地nginx实例实现零认证静态游戏托管。作为所有浏览器游戏的主要部署方式，无需登录、无需令牌、无需用户操作。

下载

在 access.log 中搜索该 IP:端口：若只出现在逗号分隔的 $upstream_addr 字段后半段（如 "192.168.1.30:8080, 192.168.1.50:8080"），说明是重试行为——前一个节点超时或返回 5xx，Nginx 按 backup 或默认 fallback 逻辑转向了它
在 error.log 中搜 upstream.*192.168.1.50:8080，若伴随 Connection refused 或 Operation timed out，说明该节点虽 weight=0，却因未关服务或防火墙放行，仍被重试连接

weight=0 不等于“彻底下线”。以下配置会让它意外复活：

upstream 块中定义了 server ... backup;，而 weight=0 节点恰好是唯一 backup ——当所有主节点不可用时，Nginx 会启用 backup，无视 weight
全局或 location 块中设置了 proxy_next_upstream error timeout http_502;，且未限制重试次数（proxy_next_upstream_tries 默认为 0，即无限重试），可能导致流量最终落到 weight=0 节点
使用了 ip_hash 或 hash $request_uri 等 hash 类指令，而该指令作用域覆盖了 upstream，会覆盖加权轮询逻辑，使 weight=0 失效（hash 算法仍可能把某些 key 映射到该地址）

weight=0 是运行时状态，但 Nginx reload 不会清空已有连接和连接池中的旧 upstream 上下文：

若该节点曾以非零权重运行过，且有长连接（keepalive）保持中，reload 后这些连接仍可能复用旧 upstream slot，短暂继续发往 weight=0 节点
检查 stub_status 输出中的 Active connections 和 Reading/Writing/Waiting，若发现大量 Waiting 连接，结合 ss -o state established '( dport = :8080 )' | grep 192.168.1.50 可确认是否有残留连接
稳妥做法：先 nginx -s reload，再执行 nginx -s quit（优雅退出），最后 systemctl start nginx 彻底重建上下文