如何通过Nginx Upstream模块实现高效轮询式负载均衡？

本文共计714个文字，预计阅读时间需要3分钟。

直接在服务器块中编写会报错。Nginx启动时提示：

正确位置示例：

http { upstream backend { server 192.168.1.10:8080; server 192.168.1.11:8080; } server { location / { proxy_pass http://backend; } } }

• upstream名称（如backend）要和proxy_pass中引用的名称严格一致，区分大小写
• 每个server行末不加;以外的符号，比如不能写server 127.0.0.1:3000 weight=2;后面多一个逗号
• IP和端口必须可达，Nginx启动时不会校验连通性，但第一次请求失败会记录no live upstreams错误

轮询是默认策略，无需额外关键字

只要没写ip_hash、least_conn或hash $request_uri这类指令，Nginx就自动按顺序轮流分发请求——不是严格“1-2-1-2”，而是基于连接数动态调整的加权轮询（weight=1时等效于简单轮询）。

• 如果某台服务器响应超时或返回502/503/504，Nginx会临时将其标记为down，跳过它，持续约10秒（由fail_timeout控制）
• 想让某台机器承担更多流量，加weight=2；设为weight=0相当于禁用该节点
• 避免误加backup——它只在其他节点全挂时才启用，不是用来做“备用轮询”的

proxy_pass必须带协议和upstream名，不能省略斜杠

proxy_pass http://backend; 是对的；proxy_pass http://backend（结尾无分号）语法错误；proxy_pass http://backend/（末尾有斜杠）会导致URI重写行为变化，容易引发后端路径错乱。

• 如果后端服务监听的是非标准端口（如3000），必须显式写出：server 127.0.0.1:3000
• 不要用localhost代替127.0.0.1——DNS解析失败时可能拖慢故障转移
• 若上游服务需要Host头透传，补上proxy_set_header Host $host;，否则默认发的是upstream name

健康检查得靠第三方模块或外部工具

开源版Nginx的upstream本身不支持主动心跳检测，max_fails和fail_timeout只响应被动失败（即请求打过去被拒绝或超时）。这意味着：一台进程僵死但端口仍通的服务，会被持续转发流量。

• 常见解法是配合nginx-plus（商业版）或nginx-upstream-check-module（需重新编译）
• 轻量替代：用systemd或supervisor监控后端进程，异常时自动curl -X POST http://localhost/api/upstream/disable?server=192.168.1.10:8080（需自建API）
• 日志里盯紧upstream timed out和connection refused，这是发现“假存活”节点的第一线索

实际部署时最容易忽略的是proxy_http_version 1.1和proxy_set_header Connection ''这两项——缺了它们，长连接复用率低，轮询看起来“不均匀”。