用于将多个服务器器定义成服务器器组，⽽而
由 proxy_pass ， fastcgi_pass 等指令进⾏行行引⽤用
upstream backend {
server backend1.example.com
weight=5;
server backend2.example.com:8080
;
server unix:/tmp/backend3;
server backup1.example.com:8080
backup;
server backup2.example.com:8080
backup;
}
server {
location / {
proxy_pass http://backend;
}
}
指令：
16.1 upstream
定义后端服务器器组，会引⼊入⼀一个新的上下⽂文
Syntax: upstream name { ... }
Default: —
Context: http
16.2 server
定义服务器器 address ，可以将地址指定为域名或IP
地址，使⽤用可选端⼝口，或者指定为 unix: 前缀后指
定的 UNIX 域套接字路路径。如果未指定端⼝口，则使⽤用
端⼝口80
Syntax: server address [parameters];
Default: —
Context: upstream
参数：
weight=number # 权重，默认为1
max_conns # 连接后端报务器器最⼤大并发活动
连接数
max_fails=number # 连接后端服务器器最⼤大
失败次数，超出指定的次数时， server 将
被标记为不不可⽤用,默认为1
fail_timeout=time # 后端服务器器在指定超
时时间内未做出回应，也会被认为不不可⽤用，
默认10s
backup # 将服务器器标记为 backup ，表示备
份服务器器（ sorry server ），即所有服务器器
均不不可⽤用时才启⽤用
down # 将服务器器标记为 down ，表示不不可
⽤用，配合 ip_hash 使⽤用，实现灰度发布
16.3 ip_hash
源地址 hash 调度⽅方法
Syntax: ip_hash;
Default: —
Context: upstream
16.4 least_conn
最少连接调度算法，当 server 拥有不不同的权重时其
为 wlc ，当所有后端主机连接数相同时，则使
⽤用 wrr ，适⽤用于⻓长连接
Syntax: least_conn;
Default: —
Context: upstream
16.5 hash
基于指定的 key 的 hash 表来实现对请求的调度，此
处的 key 可以直接⽂文本、变量量或⼆二者组合。将请求
分类，同⼀一类请求将发往同⼀一
个 upstreamserver ，使⽤用 consistent 参数， 将
使⽤用 ketama ⼀一致性 hash 算法，适⽤用于后端
是 Cache 服务器器（如 varnish ）时使⽤用，提⾼高缓存
服务器器的缓存命中率
Syntax: hash key [consistent];
Default: —
Context: upstream
16.6 keepalive
为每个worker进程保留留的空闲的⻓长连接数量量,可节约
nginx端⼝口，并减少连接管理理的消耗
Syntax: keepalive connections;
Default: —
Context: upstream
16.7 health_check （商业版）
健康状态检测机制
Syntax: health_check [parameters];
Default: —
Context: location
参数：
interval=time # 检测的频率，默认为5秒
fails=number # 判定服务器器不不可⽤用的失败
检测次数；默认为1次
passes=number # 判定服务器器可⽤用的失败检
测次数；默认为1次
uri=uri # 做健康状态检测测试的⽬目标uri；
默认为/match=NAME：健康状态检测的结果
评估调⽤用此处指定的match配置块
16.8 match （商业版）
对 backend server 做健康状态检测时，定义其结
果判断机制
Syntax: match name { ... }
Default: —
Context: http
参数
status code[ code ...] # 期望的响应状
态码
header HEADER[operator value] # ：期
望存在响应⾸首部，也可对期望的响应⾸首部的
值基于⽐比较操作符和值进⾏行行⽐比较
body # 期望响应报⽂文的主体部分应该有的内
容