加权轮询不分配句柄，仅调度请求；句柄消耗发生在Nginx与后端建连及后端处理中；优化需按真实资源设权重、启用keepalive、配合健康检查并监控验证。
加权轮询本身不直接分配句柄资源，它只决定请求发给哪台后端；句柄（如文件描述符、TCP连接）的消耗和分配，主要发生在 Nginx 与后端建立连接、以及后端应用自身处理过程中。优化的关键是：让权重配置与真实资源承载能力匹配，并减少不必要的句柄开销。
按后端真实资源能力设权重，避免句柄堆积在弱节点
句柄资源瓶颈常出现在低配机器上——比如一台 4 核 8GB 的服务器，若和 16 核 32GB 机器用相同 weight=1，它可能因并发连接数高、响应慢，导致连接堆积、TIME_WAIT 升高、文件描述符快速耗尽。
- 以 CPU 核心数为基准设 weight：16 核 → weight=4，8 核 → weight=2，4 核 → weight=1
- 若某台机器磁盘 I/O 是瓶颈（如用 HDD 而非 SSD），即使 CPU 充足，也应适当下调 weight（例如降为原值的 0.7）
- 上线前用 wrk 或 ab 做单节点压测，记录其稳定支撑的最大并发连接数（不是 QPS），再按比例折算权重，比纯看硬件参数更可靠
启用 keepalive 连接复用，降低句柄创建频次
高频短连接场景下，每秒数百次建连/断连会迅速推高 Nginx 和后端的文件描述符使用量。开启 upstream keepalive 可复用连接，显著缓解压力。
- 在 upstream 块中配置：keepalive 64;（保持最多 64 个空闲长连接）
- 对应 location 中必须加上：proxy_http_version 1.1; 和 proxy_set_header Connection '';
- 后端服务（如 Go/Java/Node.js）需启用连接池并支持 HTTP/1.1 keep-alive，否则 Nginx 端复用无效
配合健康检查，及时剔除句柄异常节点
当某台后端因句柄耗尽无法 accept 新连接时，它可能仍能返回 502 或超时，但已丧失服务能力。若轮询持续将请求打过去，只会加剧雪崩。
- 每台 server 后显式配置：max_fails=2 fail_timeout=15s;
- upstream 块中启用：proxy_next_upstream error timeout http_502 http_503;
- 搭配主动健康检查（需 nginx plus 或 stream 模块 + 自定义脚本），定期探测 socket 是否可连通 + 是否能 accept，比仅看 HTTP 状态码更早发现句柄枯竭问题
监控与验证句柄分配是否合理
光靠配置不能保证效果，得看实际运行数据：
- 在 access_log 中加入 $upstream_addr $upstream_connect_time，观察高权重节点是否真有更高连接建立频次，且 connect_time 不明显偏高
- 用 ss -s 或 lsof -i -n -P | grep :port | wc -l 定期采样各后端的 ESTABLISHED 连接数，比对是否与权重比例基本一致（例如 weight=4:2:1，连接数期望落在 ~40% : ~20% : ~10% 区间）
- 关注 Nginx 自身的 worker_connections 使用率（通过 stub_status 模块），若长期 >80%，说明连接复用不足或权重失衡导致部分 worker 过载
