加权轮询本身不直接导致崩溃，但会放大负载不均；真正原因是权重失当、健康状态不同步或连接控制缺失。排查需验证流量是否真按权重分发，并检查节点是否承受超额压力。
加权轮询本身不会直接导致某台机器过载崩溃，但它可能放大后端节点的负载不均问题——尤其是当权重配置失当、健康状态未同步或连接控制缺失时。真正引发崩溃的，往往是加权轮询叠加了未被察觉的系统瓶颈或配置缺陷。排查要从“流量分发是否真按权重执行”和“该节点是否在默默承受超额压力”两方面同时切入。
验证加权轮询是否真实生效
别依赖配置写得对就认为分发正确。Nginx 的 upstream 轮询指针由每个 worker 进程独立维护，短时间日志里看到某台连续收请求是正常现象；关键看长期统计分布：
- 在 nginx.conf 中定义专用日志格式：log_format weighted_log '$remote_addr - $upstream_addr [$time_local] "$request" $status $upstream_response_time';
- 在对应 location 块中启用：access_log /var/log/nginx/weighted.log weighted_log;
- 发起 500+ 次真实请求（避免缓存干扰），用 awk 统计各后端 IP 出现频次：awk '{print $4}' /var/log/nginx/weighted.log | sort | uniq -c | sort -nr
- 若某台实际接收比例远超其 weight 占比（例如 weight=3 的节点收了 60% 请求，而 total weight=10），说明存在隐性偏差
检查权重配置是否引入隐性风险
加权不是万能调节阀，错误用法反而会加剧单点压力：
- 避免混用 ip_hash 或 hash $arg_token 等指令——它们会覆盖加权逻辑，使流量固化到特定节点
- 禁用 backup 和 down 标记以外的异常标记（如临时注释掉某行 server 却保留 # weight=1）；Nginx 会读取注释中的指令并影响行为
- 确认所有 server 行显式声明相同健康检查参数：max_fails=2 fail_timeout=15s；否则性能弱的节点可能因探测更敏感而被频繁剔除，剩余节点被迫承接更多加权流量
- 不要给高权重节点单独配 max_conns 而忽略低权重节点——这会造成高权节点满负荷时仍被持续投递，低权节点却空闲
定位该节点真实的过载根源
崩溃往往发生在“看起来没超限”的临界点。需交叉验证三层指标：
- 连接层：登录该服务器，运行 ss -s | grep -i "tcp:" 查看当前 TCP 连接总数；对比 Nginx 配置中的 worker_connections × worker_processes 上限值，再检查 netstat -antp | grep :8080 | wc -l 看应用端口活跃连接是否接近后端服务最大线程数
- 资源层：用 top -p $(pgrep -f 'java|node|python') 直接盯住后端进程的 CPU 和内存占用；若 RSS 持续 >80% 物理内存，且 dmesg | grep -i "killed process" 有记录，大概率是 OOM Killer 终止了进程
- 响应层：在 Nginx 日志中筛选该节点的 $upstream_response_time，若大量请求 >5s 且伴随 504 Gateway Timeout，说明后端已无法及时处理，但加权机制仍在继续派发新请求
加固加权轮询的容错能力
单纯调低 weight 只是掩耳盗铃。必须让 Nginx 主动感知并规避正在恶化的节点：
- 在 upstream 块中为每台 server 显式设置 max_conns=300（根据后端实际并发能力设定），防止连接堆积
- 在 location 块中启用重试：proxy_next_upstream error timeout http_500 http_502 http_503 http_504;，配合 upstream 的 fail_timeout=10s max_fails=1，实现“一次失败即绕过”
- 确保后端开启 keepalive 连接，并在 Nginx 中配置 proxy_http_version 1.1; proxy_set_header Connection '';，避免连接反复建连加重负担
- 若该节点是数据库前置服务或强状态服务，考虑改用 least_conn 替代加权轮询——此时连接数比权重更能反映真实负载
