upstream块必须定义在http上下文中,不可置于server或location内;需唯一命名并在proxy_pass中正确引用,仅写名称不带路径或端口;默认被动健康检查不足,需配合proxy_next_upstream等参数增强容错。

upstream 块必须定义在 http 上下文中
nginx 的负载均衡核心是 upstream 模块,但它不能写在 server 或 location 块里。常见错误是把 upstream 直接塞进 server 中,导致 nginx -t 报错:unknown directive "upstream"。
-
upstream必须放在http块内(通常在/etc/nginx/nginx.conf的http { ... }区域) - 每个
upstream需要唯一名称,比如backend_servers,后续在proxy_pass中引用 - 不支持在
if或map中动态定义upstream,运行时不可变
proxy_pass 指向 upstream 名称而非 URL
配置反向代理时,proxy_pass 的值如果是 upstream,必须只写名称,不能带协议或路径,否则会退化为普通代理,失去负载均衡能力。
- ✅ 正确:
proxy_pass http://backend_servers; - ❌ 错误:
proxy_pass http://backend_servers/;(末尾斜杠触发重写逻辑,可能丢路径) - ❌ 错误:
proxy_pass http://backend_servers:8080;(端口会被忽略,且语法非法) - 注意:如果
upstream中某台服务器指定了端口(如192.168.1.10:3000),则无需在proxy_pass中重复
健康检查不能靠默认 passive 检测兜底
nginx 开源版默认只做 passive 健康检查(即仅在请求失败时标记服务器为 down,超时后自动尝试恢复),它不主动探测后端是否存活。这意味着:一台进程已僵死但端口仍通的服务器,会持续接收流量,直到首次请求超时。
- 启用主动检查需使用
nginx-plus或开源版配合第三方模块(如nginx-upstream-check-module) - 开源常用折中方案:严格设置
proxy_next_upstream,例如:proxy_next_upstream error timeout http_500 http_502 http_503; -
max_fails=2 fail_timeout=10s是合理起点,避免因瞬时抖动频繁摘除节点 - 别忽略
proxy_read_timeout和proxy_connect_timeout,它们直接影响失败判定节奏
http {
upstream backend_servers {
server 192.168.1.10:3000 max_fails=2 fail_timeout=10s;
server 192.168.1.11:3000 max_fails=2 fail_timeout=10s;
keepalive 32;
}
server {
listen 80;
location / {
proxy_pass http://backend_servers;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_next_upstream error timeout http_500 http_502 http_503;
proxy_connect_timeout 5s;
proxy_read_timeout 10s;
}
}
}
实际部署时,keepalive、proxy_buffering、后端应用自身的连接池配置,三者必须对齐。漏掉任一环,都可能让负载看起来“不均”——不是 nginx 分配不均,而是连接复用没生效或缓冲区提前截断响应。










