Nginx高效负载调度的关键在于匹配业务特征选对算法、配好健康检查、调优传输链路并避开配置雷区：轮询适用于同构无状态服务；加权轮询适配异构服务器；ip_hash保障会话保持，但需防NAT/IP失真；least_conn适合长连接场景；必须配置max_fails/fail_timeout与proxy_next_upstream实现被动健康检查；启用keepalive连接池、调优缓冲区及超时参数提升转发效率；严禁ip_hash与weight共存，upstream须定义在http块内，域名server需加resolve，backup与down不可混用。
要让 Nginx 实现高效负载调度，关键不是堆砌功能，而是匹配业务真实特征选对策略、配好健康机制、调优传输链路，并避开几个高频配置雷区。
按业务场景选准核心调度算法
不同流量模式对应不同算法，硬套默认轮询容易引发倾斜或会话中断：
- 轮询（round robin）：适合后端全是同构服务器、无状态服务（如静态资源、无 session 的 API）。无需额外配置，Nginx 默认启用
-
加权轮询（weight）：新老机器混用、CPU/内存差异明显时必须用。例如一台 16C32G 设
weight=5，一台 8C16G 设weight=2，请求比例自动趋近 5:2 -
ip_hash：登录态、购物车等需会话保持的场景。注意 NAT 或 CDN 后客户端 IP 可能被覆盖，建议搭配
proxy_set_header X-Forwarded-For $remote_addr;，再用hash $http_x_forwarded_for consistent;替代原生 ip_hash - least_conn：长连接密集型服务首选（如 WebSocket、gRPC 流式接口）。它看的是当前活跃连接数，而非请求数，避免慢连接堆积拖垮单台节点
必须配健康检查，否则等于“盲转发”
没有健康检查的 upstream 就是定时炸弹。开源版 Nginx 支持被动检查，务必启用：
- 每台
server后加max_fails=3 fail_timeout=30s：连续 3 次超时或返回 5xx 即标记为不可用，30 秒后自动重试 - 在
location块中配proxy_next_upstream error timeout http_500 http_502 http_503 http_504;：上游失败时立即转给下一台，用户无感知 - 若用 Nginx Plus，可启用主动健康检查：
health_check interval=5s uri=/health;，比被动更早发现僵死进程
优化代理层转发效率
很多性能瓶颈不在后端，而在 Nginx 自身转发环节：
- 启用 keepalive 连接池：
upstream backend { keepalive 32; }，配合proxy_http_version 1.1;和proxy_set_header Connection '';，复用 TCP 连接，大幅降低 handshake 开销 - 调大缓冲区：
proxy_buffering on; proxy_buffers 8 64k; proxy_busy_buffers_size 128k;，减少小包频繁写入，提升吞吐 - 设置合理超时：
proxy_connect_timeout 5s;（建连）、proxy_read_timeout 30s;（后端响应）、proxy_send_timeout 30s;（发请求），防慢后端拖垮整个 upstream
避开几个致命配置错误
这些细节不报错，但会让策略失效甚至引发流量雪崩：
-
ip_hash 与 weight 绝对不能共存：只要 upstream 中写了
ip_hash，所有weight参数都会被忽略 - upstream 必须定义在 http 块内：若误写在 server 或 location 块里，Nginx 启动会失败
- 用域名做 server 地址时，必须加 resolve 参数：否则 DNS 变更后不会自动更新，导致流量无法到达新 IP
- backup 服务器不能和 down 混用：backup 是备用兜底，down 是主动下线；同时配置可能造成调度逻辑混乱
