Upstream#

该模块用于定义可以通过 proxy_pass、fastcgi_pass、uwsgi_pass、scgi_pass、memcached_pass 和 grpc_pass 指令引用的服务器组。

配置示例#

upstream backend {
    zone backend 1m;
    server backend1.example.com       weight=5;
    server backend2.example.com:8080;
    server backend3.example.com       service=_example._tcp resolve;
    server unix:/tmp/backend3;

    server backup1.example.com:8080   backup;
    server backup2.example.com:8080   backup;
}

resolver 127.0.0.53 status_zone=resolver;

server {
    location / {
        proxy_pass http://backend;
    }
}

指令#

backup_switch (PRO)#

Added in version 1.9.0: PRO

语法	`backup_switch` `permanent`[=time];
默认值	—
上下文	upstream

该指令启用从活动组（即上次成功找到服务器的组）而不是主组开始服务器选择的功能。如果在活动组中无法为下一个请求找到服务器，搜索转移到备用组，那么该组将成为活动组，后续请求将首先定向到该组中的服务器。

如果定义了 permanent 参数但没有时间值，该组在选择后保持活动状态，不会自动重新检查较低级别的组。如果指定了 time，该组的活动状态在指定间隔后过期，负载均衡器再次检查较低级别的组，如果服务器正常工作则返回到这些组。

示例：

upstream my_backend {
    server primary1.example.com;
    server primary2.example.com;

    server backup1.example.com backup;
    server backup2.example.com backup;

    backup_switch permanent=2m;
}

如果负载均衡器从主服务器切换到备用组，所有后续请求将在2分钟内由该备用组处理。 2分钟过后，负载均衡器会重新检查主服务器，如果它们正常工作，则重新激活它们。

bind_conn (PRO)#

语法	`bind_conn` value;
默认	—
上下文	upstream

当指定为变量字符串的 value 变为不同于 "" 和 "0" 的值时，允许将服务器连接绑定到客户端连接。

警告

bind_conn 指令必须在所有设置负载均衡方法的指令之后使用，否则它将不起作用。如果与 sticky 指令一起使用，那么 bind_conn 必须在 sticky 之后。

警告

使用该指令时，Proxy 模块设置必须允许使用持久连接，例如：

proxy_http_version 1.1;
proxy_set_header Connection "";

该指令的典型用例是代理带有 NTLM 认证的连接，其中需要确保在协商开始时客户端到服务器的绑定：

map $http_authorization   $ntlm {
    ~*^N(?:TLM|egotiate)  1;
}

upstream ntlm_backend {
    server 127.0.0.1:8080;
    bind_conn $ntlm;
}

server {
    # ...
    location / {
        proxy_pass http://ntlm_backend;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        # ...
    }
}

feedback (PRO)#

语法	`feedback` variable [`inverse`] [`factor=`number] [`account=`condition_variable] [`last_byte`];
默认	—
上下文	upstream

在 upstream 中设置基于反馈的负载均衡机制。它通过将每个代理服务器的权重乘以平均反馈值来动态调整负载均衡决策，该值根据 variable 的值随时间变化，并受可选条件约束。

可以指定以下参数：

`variable`	获取反馈值的变量。它应该表示性能或健康指标；假设服务器在头部或其他方式中提供它。该值在每次从服务器的响应中进行评估，并根据 `inverse` 和 `factor` 设置纳入移动平均值。
`inverse`	如果设置了该参数，反馈值被反向解释：较低的值表示更好的性能。
`factor`	计算平均值时考虑反馈值的因子。有效值为 0 到 99 的整数。默认值为 `90`。使用指数平滑公式计算平均值。因子越大，新值对平均值的影响越小；如果指定 `90`，那么将取前一个值的 90% 和新值的仅 10%。
`account`	指定一个条件变量，控制在计算中考虑哪些响应。只有当该响应的条件变量不等于 `""` 或 `"0"` 时，平均值才会用响应的反馈值更新。备注默认情况下，主动检查期间的响应不包括在计算中；将 $upstream_probe 变量与 `account` 结合使用可以包括这些响应或甚至排除其他所有响应。
`last_byte`	允许在接收到完整响应后处理来自代理服务器的数据，而不仅仅是头部。

示例：

upstream backend {

    zone backend 1m;

    feedback $feedback_value factor=80 account=$condition_value;

    server backend1.example.com;
    server backend2.example.com;
}

map $upstream_http_custom_score $feedback_value {
    "high"                      100;
    "medium"                    75;
    "low"                       50;
    default                     10;
}

map $upstream_probe $condition_value {
    "high_priority" "1";
    "low_priority"  "0";
    default         "1";
}

此配置根据响应头字段的特定分数按反馈级别对服务器响应进行分类，并且还在 $upstream_probe 上添加条件，仅考虑来自 high_priority 主动检查的响应或对常规客户端请求的响应。

hash#

语法	`hash` key [`consistent`];
默认	—
上下文	upstream

指定服务器组的负载均衡方法，其中客户端到服务器的映射基于哈希键值。键可以包含文本、变量及其组合。请注意，从组中添加或移除服务器可能会导致大多数键重新映射到不同的服务器。该方法与 Cache::Memcached Perl 库兼容。

如果指定了 consistent 参数，将使用 ketama 一致性哈希方法。该方法确保当向组中添加或移除服务器时，只有少数键会重新映射到不同的服务器。这有助于为缓存服务器实现更高的缓存命中率。该方法与 Cache::Memcached::Fast Perl 库兼容，其中 ketama_points 参数设置为 160。

ip_hash#

语法	`ip_hash`;
默认	—
上下文	upstream

指定组的负载均衡方法，其中请求根据客户端 IP 地址在服务器之间分配。IPv4 地址的前三个八位字节或整个 IPv6 地址用作哈希键。该方法确保来自同一客户端的请求将始终传递到同一服务器，除非该服务器被认为不可用。在这种情况下，客户端请求将传递到另一台服务器，对于该客户端来说，这很可能也是同一台服务器。

如果需要临时移除其中一台服务器，应使用 down 参数标记它，以保持客户端 IP 地址的当前哈希：

upstream backend {
    ip_hash;

    server backend1.example.com;
    server backend2.example.com;
    server backend3.example.com down;
    server backend4.example.com;
}

keepalive#

语法	`keepalive` connections;
默认	—
上下文	upstream

激活到上游服务器的连接缓存。

connections 参数设置每个工作进程缓存中保留的到上游服务器的空闲保持连接的最大数量。当超过此数量时，最近最少使用的连接将被关闭。

备注

特别需要注意的是，keepalive 指令不会限制 Angie 工作进程可以打开的到上游服务器的连接总数。connections 参数应设置为足够小的数字，以便让上游服务器也能处理新的传入连接。

警告

keepalive 指令必须在所有设置负载均衡方法的指令之后使用；否则它不会起作用。

带有保持连接的 memcached 上游配置示例：

upstream memcached_backend {
    server 127.0.0.1:11211;
    server 10.0.0.2:11211;

    keepalive 32;
}

server {
    #...

    location /memcached/ {
        set $memcached_key $uri;
        memcached_pass memcached_backend;
    }

}

对于 HTTP，proxy_http_version 指令应设置为 "1.1"，并清除 Connection 头字段：

upstream http_backend {
    server 127.0.0.1:8080;

    keepalive 16;
}

server {
    #...

    location /http/ {
        proxy_pass http://http_backend;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
    #    ...
    }
}

备注

另外，可以通过将 "Connection: Keep-Alive" 头字段传递给上游服务器来使用 HTTP/1.0 持久连接，尽管不建议使用这种方法。

对于 FastCGI 服务器，需要设置 fastcgi_keep_conn 以使保持连接工作：

upstream fastcgi_backend {
    server 127.0.0.1:9000;

    keepalive 8;
}

server {
    #...

    location /fastcgi/ {
        fastcgi_pass fastcgi_backend;
        fastcgi_keep_conn on;
    #    ...
    }
}

备注

SCGI 和 uwsgi 协议没有定义保持连接的语义。

keepalive_requests#

语法	`keepalive_requests` number;
默认	`keepalive_requests 1000;`
上下文	upstream

设置可以通过一个保持连接提供的最大请求数。达到最大请求数后，连接将被关闭。

定期关闭连接是必要的，以释放每个连接的内存分配。因此，使用过高的最大请求数可能会导致过度的内存使用，不推荐这样做。

keepalive_time#

语法	`keepalive_time` time;
默认	`keepalive_time 1h;`
上下文	upstream

限制通过一个保持连接处理请求的最大时间。达到此时间后，连接将在后续请求处理完成后关闭。

keepalive_timeout#

语法	`keepalive_timeout` timeout;
默认	`keepalive_timeout 60s;`
上下文	upstream

设置与上游服务器的空闲保持连接保持打开状态的超时时间。

least_conn#

语法	`least_conn`;
默认	—
上下文	upstream

指定组应使用负载均衡方法，其中请求将传递给活动连接数最少的服务器，同时考虑服务器的权重。如果有多个这样的服务器，则使用加权轮询负载均衡方法依次尝试。

least_time (PRO)#

语法	`least_time` `header` \| `last_byte` [`factor=`number] [`account=`condition_variable];
默认	—
上下文	upstream

指定组应使用负载均衡方法，其中活动服务器收到请求的机会与其平均响应时间成反比；响应时间越少，服务器接收的请求越多。

`header`	指令考虑接收响应头的平均时间。
`last_byte`	指令使用接收整个响应的平均时间。

`factor`	与 response_time_factor (PRO) 具有相同的目的，如果设置了该参数则覆盖它。
`account`	指定一个条件变量，控制哪些响应包含在计算中。仅当响应的条件变量不是 `""` 或 `"0"` 时才更新平均值。备注默认情况下，主动健康检查期间的响应不包含在计算中；将 $upstream_probe 变量与 `account` 结合使用可以包含这些响应或甚至排除其他所有响应。

当前值在 API 的上游指标中作为服务器 health 对象中的 header_time （仅头部）和 response_time （整个响应）显示。

queue (PRO)#

语法	`queue` number [`timeout=`time];
默认	—
上下文	upstream

如果在第一次尝试时无法将代理服务器分配给请求（例如，在短暂服务中断期间或当负载激增达到 max_conns 限制时），请求不会被拒绝；相反，Angie 尝试将其排队以进行处理。

指令的 number 参数设置工作进程队列中请求的最大数量。如果队列已满，将向客户端返回 502 (Bad Gateway) 错误。

备注

proxy_next_upstream 指令的逻辑也适用于排队请求。具体来说，如果为请求选择了一个服务器但无法将其交给它，请求可能会返回到队列中。

如果在 timeout 设置的时间内未选择服务器来处理排队请求（默认值为 60 秒），将向客户端返回 502 (Bad Gateway) 错误。提前关闭连接的客户端请求也会从队列中移除；在 API 中有通过队列传递的请求状态的计数器。

警告

queue 指令必须在所有设置负载均衡方法的指令之后使用；否则，它将无法工作。

random#

语法	`random` [`two`];
默认	—
上下文	upstream

指定组的负载均衡方法，其中请求传递给随机选择的服务器，同时考虑服务器权重。

如果指定了可选的 two 参数，Angie 会随机选择两个服务器，然后使用 least_conn 方法选择其中一个，将请求传递给活动连接数最少的服务器。

response_time_factor (PRO)#

语法	`response_time_factor` number;
默认	`response_time_factor 90;`
上下文	upstream

为 least_time (PRO) 负载均衡方法使用指数加权移动平均公式计算平均响应时间时，设置**先前**值的平滑因子。

指定的 number 越大，新值对平均值的影响越小；如果指定 90，将取先前值的 90% 和新值的 10%。允许的值范围是 0 到 99（包含）。

当前计算结果在 API 的上游指标中作为服务器 health 对象中的 header_time （仅头部）和 response_time （整个响应）显示。

备注

计算中仅包含成功响应；什么被视为不成功响应由 proxy_next_upstream、fastcgi_next_upstream、uwsgi_next_upstream、scgi_next_upstream、memcached_next_upstream 和 grpc_next_upstream 指令定义。此外，仅当接收并处理所有头部时才重新计算 header_time 值，仅当接收整个响应时才重新计算 response_time。

server#

语法	`server` address [parameters];
默认	—
上下文	upstream

定义服务器的地址和其他参数。地址可以指定为域名或 IP 地址，带可选端口，或作为 UNIX 套接字路径，在 unix: 前缀后指定。如果未指定端口，则使用端口 80。解析为多个 IP 地址的域名一次定义多个服务器。

可以定义以下参数：

`weight=`number	设置服务器的权重。默认为 1。
`max_conns=`number	限制到代理服务器的最大同时活动连接数。默认值为 `0`，表示没有限制。如果服务器组不驻留在共享内存中，则限制对每个工作进程生效。

备注

如果启用了空闲 keepalive 连接、多个工作进程和共享内存，则到代理服务器的活动和空闲连接总数可能超过 max_conns 值。

max_fails=number — 设置应在 fail_timeout 设置的持续时间内发生的与服务器通信的失败尝试次数，以将服务器视为不可用；然后在相同的持续时间后重试。

什么被视为失败尝试由 proxy_next_upstream、 fastcgi_next_upstream、uwsgi_next_upstream、 scgi_next_upstream、memcached_next_upstream 和 grpc_next_upstream 指令定义。

当达到 max_fails 时，服务器也会被 upstream_probe (PRO) 探针视为不健康；它将不会接收客户端请求，直到探针重新认为它健康。

备注

如果一个组中的 server 指令解析为多个服务器，则其 max_fails 设置适用于每个服务器。

如果在解析所有 server 指令后，上游仅包含一个服务器，则 max_fails 设置将无效并被忽略。

`max_fails=1`	默认尝试次数
`max_fails=0`	禁用尝试的计数

fail_timeout=time — 设置在多长时间内应发生指定次数的与服务器通信失败尝试 (max_fails) 才能将服务器视为不可用。然后，服务器在同样的时间内保持不可用状态，然后才会重试。

默认情况下，这设置为 10 秒。

备注

如果一个组中的 server 指令解析为多个服务器，则其 fail_timeout 设置适用于每个服务器。

如果在解析所有 server 指令后，上游仅包含一个服务器，则 fail_timeout 设置将无效并被忽略。

backup

将服务器标记为备用服务器。当主服务器不可用时，将传递请求给它。

如果配置了 backup_switch (PRO) 指令，其主动备用逻辑也会被应用。

down

将服务器标记为永久不可用。

drain (PRO)

将服务器标记为排水状态；这意味着它仅接收来自之前通过 sticky 绑定的会话的请求。否则，它的行为类似于 down。

警告

参数 backup 不能与 hash、ip_hash 和 random 负载均衡方法一起使用。

down 和 drain 参数是互斥的。

resolve

启用监控与域名对应的 IP 地址列表的更改，无需重新加载配置即可更新它。该组应该存储在共享内存区域中；此外，您需要定义一个 resolver。

service=name

启用解析 DNS SRV 记录并设置服务名称。为了使该参数生效，请指定 resolve 服务器参数，提供无端口号的主机名。

如果服务名称中没有点，则该名称根据 RFC 标准形成：服务名称以 _ 为前缀，然后在点后添加 _tcp。因此，服务名称 http 将结果为 _http._tcp。

Angie 通过组合归一化的服务名称和主机名解析 SRV 记录，并通过 DNS 获取该组合的服务器列表，以及它们的优先级和权重。

优先级最高的 SRV 记录（共享最小优先级值的记录）解析为主服务器，其他记录成为备份服务器。如果 backup 与 server 一起设置，优先级最高的 SRV 记录解析为备份服务器，其他记录将被忽略。
权重类似于 server 指令的 weight 参数。如果同时通过指令和 SRV 记录设置权重，则使用指令设置的权重。

这个示例将查找 _http._tcp.backend.example.com 记录：

server backend.example.com service=http resolve;

sid=id

设置组内的服务器 ID。如果参数未设置， ID 将设置为 IP 地址和端口或 UNIX 套接字路径的十六进制 MD5 哈希值。

slow_start=time

设置服务器恢复服务时的时间，在使用 round-robin 或 least_conn 负载均衡方法时恢复其权重。

如果设置了该参数，且服务器在故障后再次被认为是健康的（按照 max_fails 和 upstream_probe (PRO) 的定义），服务器将在指定的时间范围内逐渐恢复其指定的权重。

如果未设置该参数，在类似情况下服务器将立即以其指定的权重开始工作。

备注

如果上游中只有一个 server， slow_start 将无效并被忽略。

state (PRO)#

Syntax	`state` file;
Default	—
Context	upstream

指定持久化存储上游服务器列表的 file。从我们的包安装时，会创建一个指定的 /var/lib/angie/state/ （在 FreeBSD 上为 /var/db/angie/state/）目录，并赋予适当的权限来存储这些文件，因此您只需在配置中添加文件名：

upstream backend {

    zone backend 1m;
    state /var/lib/angie/state/<FILE NAME>;
}

这里的服务器列表格式类似于 server。当通过配置 API 在 /config/http/upstreams/ 部分修改服务器时，文件内容会发生变化。该文件在 Angie 启动或配置重载时读取。

警告

要在 upstream 块中使用 state 指令，其中不应有 server 指令，但需要共享内存区域 (zone)。

sticky#

语法

sticky cookie name [attr=值]...;

sticky route $变量...;

sticky learn zone=区域 create=$创建变量... lookup=$查找变量... [header] [norefresh] [timeout=时间];

sticky learn [zone=区域] lookup=$查找变量... remote_action=uri remote_result=$远程变量 [norefresh] [timeout=时间];

默认值

—

上下文

upstream

配置客户端会话与后端服务器之间的绑定方式，模式由第一个参数指定。若某服务器启用了 sticky，可在其 server 块中使用 drain (PRO) 选项优雅地移除该服务器。

警告

必须在所有负载均衡方法相关指令之后使用 sticky 指令，否则不会生效。如果同时使用 bind_conn (PRO)，则 bind_conn 必须放在 sticky 之后。

使用 Cookie 存储和识别客户端会话。适用于已有 Cookie 会话机制的场景。

客户端初次请求时（尚未绑定服务器），根据当前的负载均衡方法选择服务器， Angie 会为该请求设置 Cookie，用于标识所选服务器。

Cookie 名称由 sticky 指定，值对应 server 指令中的 sid 参数。若配置了 sticky_secret，则该值会被哈希处理。

后续请求若携带该 Cookie，将被路由到其所对应的服务器（通过 sid 匹配）。若该服务器不可用，则根据当前负载均衡策略选择其他服务器。

可以通过指令添加 Cookie 属性；默认只设置了 path=/。属性值可以使用变量。若设置为空值（如 attr=），则删除该属性。例如，sticky cookie path= 会生成不含 path 属性的 Cookie。

以下示例中，Angie 设置一个名为 srv_id、有效期为 1 小时的 Cookie，域名通过变量指定：

upstream backend {
    server backend1.example.com:8080;
    server backend2.example.com:8080;

    sticky cookie srv_id domain=$my_domain max-age=3600;
}

使用预定义的路由 ID，可存在于 URL、Cookie 或请求参数中。灵活性较低，但在已有相关机制的系统中适用性较好。

后端服务器可以为客户端分配一个路由 ID，并通过双方约定的方式返回。该 ID 必须与 server 的 sid 相匹配。同样地，如果启用了 sticky_secret，则该值会被哈希处理。

客户端随后的请求必须包含该 ID，例如通过 cookie 或请求参数。

指令参数为一个变量列表，Angie 会从中取第一个非空值作为路由标识，并与服务器的 sid 进行匹配。

以下示例中，Angie 首先查找 route Cookie，其次查找请求参数：

upstream backend {
    server backend1.example.com:8080 "sid=server 1";
    server backend2.example.com:8080 "sid=server 2";

    sticky route $cookie_route $arg_route;
}

使用动态生成的密钥绑定客户端到服务器。更加灵活，可在运行时分配服务器，会话信息存储于共享内存区域中，并支持多种会话 ID 来源。

会话由后端响应动态生成。使用 create 和 lookup 指定如何创建和查找会话 ID；两者都可接受多个变量。

第一个非空的 create 变量值即为会话 ID，例如可来自后端设置的 Cookie。

会话保存在 zone 指定的共享内存区域中，若在 timeout （默认 1 小时）内未被访问，将被删除。

默认情况下，每次使用会刷新过期时间。使用 norefresh 可关闭此行为，实现严格超时。

客户端请求中包含会话 ID 的变量由 lookup 指定，同样取第一个非空值；若均为空，则视为新请求。

使用 header 可在收到响应头即创建会话；否则默认在完整响应后再创建。

以下示例中，Angie 使用 examplecookie 创建会话：

upstream backend {
    server backend1.example.com:8080;
    server backend2.example.com:8080;

    sticky learn
        create=$upstream_cookie_examplecookie
        lookup=$cookie_examplecookie
        zone=client_sessions:1m;
}

使用 remote_action 和 remote_result 与远程存储交互，动态分配与管理会话 ID。本地共享内存仅作为缓存，远程存储为权威来源。此时不能使用 create 参数，会话 ID 必须由远程存储生成。

会话若在 timeout 时间内未被访问，则被删除（默认 1 小时）。

默认启用刷新机制，可用 norefresh 关闭。

配置中 zone 参数可省略；若未指定，Angie 不会本地缓存任何会话，每次请求都会与远程存储通信（可通过 proxy_cache 缓存其响应）。

工作流程如下：

先从 lookup 指定的变量中取出会话 ID；若均为空，则使用普通负载均衡。
若设置了 zone，Angie 会尝试在本地查找会话；若找到则使用并完成处理。
若未找到，或未配置 zone，则按正常方式选定服务器，然后向 remote_action 指定的地址发送同步子请求，请求中应包含：
- 会话 ID（即 $sticky_sessid）；
- 所选服务器的标识（sid= 或 $sticky_sid）。
建议通过 HTTP 请求头发送（见 proxy_set_header）。
远程存储响应结果：
- 200/201/204 表示确认；若配置了 zone，则可将该会话缓存。
- 409 表示冲突（仅在配置了 zone 时有效）：此会话 ID 已绑定到另一个服务器。存储应返回正确的服务器 ID，通过 remote_result 提取使用。
- 其他响应码或缺少服务器 ID， Angie 会继续使用原选服务器。

remote_result 指定从响应头中提取服务器 ID，可使用 upstream_http_* 变量访问。

示例：使用 Cookie bar 作为初始 ID，远程返回的新 ID 存入 $upstream_http_x_sticky_sid：

http {

    upstream u1 {
        server srv1;
        server srv2;

        sticky learn zone=sz:1m
            lookup=$cookie_bar
            remote_action=/remote_session
            remote_result=$upstream_http_x_sticky_sid;

        zone z 1m;
    }

    server {

        listen localhost;

        location / {
            proxy_pass http://u1/;
        }

        location /remote_session {
            internal;
            proxy_set_header X-Sticky-Sessid $sticky_sessid;
            proxy_set_header X-Sticky-Sid $sticky_sid;
            proxy_set_header X-Sticky-Last $msec;
            proxy_pass http://remote;
        }
    }
}

响应示例：

HTTP/1.1 200 OK
...
X-Sid: web-server-01
X-Session-Backend: backend-pool-1

可用变量：

$upstream_http_x_sid → web-server-01
$upstream_http_x_session_backend → backend-pool-1

由于在 remote_result 中指定了 $upstream_http_x_sid， Angie 将使用其值定位服务器 sid=web-server-01。

sticky 指令考虑 upstream 中服务器状态：

标记为 down 或临时不可用的服务器将被排除；
达到 max_conns 限制的服务器暂不参与调度；
启用了 drain （PRO）的服务器在 sid 匹配时仍可分配会话；
恢复后的服务器会被自动重新启用。

使用 sticky_secret 与 sticky_strict 可进一步控制行为。若无法匹配服务器，默认将使用普通负载均衡；但启用 sticky_strict on; 时，则会返回错误。

注意：zone 参数所指定的共享内存区域不能在多个 upstream 间共享；每个 upstream 应使用独立 zone。

sticky_secret#

语法	`sticky_secret` string;
默认值	—
上下文	upstream

将 string 作为盐值添加到 MD5 哈希函数中，用于 sticky 指令在 cookie 和 route 模式下。 string 可以包含变量，例如 $remote_addr：

upstream backend {
    server backend1.example.com:8080;
    server backend2.example.com:8080;

    sticky cookie cookie_name;
    sticky_secret my_secret.$remote_addr;
}

盐值被附加到被哈希的值上；要独立验证哈希机制：

$ echo -n "<VALUE><SALT>" | md5sum

sticky_strict#

语法	`sticky_strict` `on` \| `off`;
默认值	`sticky_strict off;`
上下文	upstream

启用时，如果所需的服务器不可用，Angie 将返回 HTTP 502 错误给客户端，而不是像在上游中没有可用服务器时那样使用任何其他可用的服务器。

upstream#

语法	`upstream` name { ... }
默认值	—
上下文	http

定义一组服务器。服务器可以监听不同的端口。此外，可以混合监听 TCP 和 UNIX 域套接字的服务器。

示例：

upstream backend {
    server backend1.example.com weight=5;
    server 127.0.0.1:8080       max_fails=3 fail_timeout=30s;
    server unix:/tmp/backend3;

    server backup1.example.com  backup;
}

默认情况下，请求在服务器之间使用加权轮询平衡方法分配。在上述示例中，每 7 个请求将按以下方式分配：5 个请求发送到 backend1.example.com，每个第二和第三个服务器各 1 个请求。

如果在与服务器的通信中发生错误，请求将传递给下一个服务器，依此类推，直到所有可用服务器都被尝试。如果无法从任何服务器获得成功响应，客户端将收到与最后一个服务器的通信结果。

zone#

语法	`zone` name [size];
默认值	—
上下文	upstream

定义共享内存区的名称和大小，该内存区保存在工作进程之间共享的组配置和运行时状态。多个组可以共享同一个区域。在这种情况下，只需指定一次大小即可。

内置变量#

http_upstream 模块支持以下内置变量：

`$sticky_sessid`#

与 sticky 中的 remote_action 一起使用；存储从 lookup 中获取的初始会话 ID。

`$sticky_sid`#

与 sticky 中的 remote_action 一起使用；存储先前与会话相关联的服务器 ID。

`$upstream_addr`#

保存上游服务器的 IP 地址和端口，或 UNIX 域套接字的路径。如果在请求处理期间联系了多个服务器，它们的地址用逗号分隔，例如：

192.168.1.1:80, 192.168.1.2:80, unix:/tmp/sock

如果发生从一个服务器组到另一个服务器组的内部重定向，由 X-Accel-Redirect 或 error_page 发起，则来自不同组的服务器地址用冒号分隔，例如：

192.168.1.1:80, 192.168.1.2:80, unix:/tmp/sock : 192.168.10.1:80, 192.168.10.2:80

如果无法选择服务器，该变量将保留 server group 的 name。

`$upstream_bytes_received`#

从上游服务器接收的字节数。来自多个连接的值用逗号和冒号分隔，类似于 $upstream_addr 变量中的地址。

`$upstream_bytes_sent`#

发送到上游服务器的字节数。来自多个连接的值用逗号和冒号分隔，类似于 $upstream_addr 变量中的地址。

`$upstream_cache_status`#

保存访问响应缓存的状态。状态可以是 MISS、BYPASS、EXPIRED、STALE、UPDATING、 REVALIDATED 或 HIT：

MISS：缓存中未找到响应，请求被转发到上游服务器。
BYPASS：绕过缓存，请求直接转发到上游服务器。
EXPIRED：缓存的响应过期，并向上游服务器发送用于更新内容的新请求。
STALE：缓存的响应过期，但将提供给客户端直到最终从上游服务器获取更新。
UPDATING：缓存的响应过期，但将提供给客户端直到当前正在进行的来自上游服务器的更新完成。
REVALIDATED：缓存的响应过期，但已成功重新验证并且不需要来自上游服务器的更新。
HIT：响应是从缓存中提供的。

如果完全绕过缓存而未访问它，则该变量未设置。

`$upstream_connect_time`#

保存与上游服务器建立连接所花费的时间；该时间以秒为单位，精确到毫秒。对于 SSL，包括握手所花费的时间。多个连接的时间用逗号和冒号分隔，类似于 $upstream_addr 变量中的地址。

`$upstream_header_time`#

保存从上游服务器接收响应头所花费的时间；该时间以秒为单位，精确到毫秒。多个响应的时间用逗号和冒号分隔，类似于 $upstream_addr 变量中的地址。

`$upstream_http_<name>`#

保存服务器响应头字段。例如，Server 响应头字段可以通过 $upstream_http_server 变量访问。将头字段名称转换为变量名称的规则与以 $http_ 前缀开头的变量相同。仅保存最后一个服务器响应中的头字段。

`$upstream_queue_time`#

保存请求在选择服务器之前在 queue 中花费的时间；该时间以秒为单位，精确到毫秒。多个选择尝试的时间用逗号和冒号分隔，类似于 $upstream_addr 变量中的地址。

`$upstream_response_length`#

保存从上游服务器获取的响应的长度；该长度以字节为单位。多个响应的长度用逗号和冒号分隔，类似于 $upstream_addr 变量中的地址。

`$upstream_response_time`#

保存接收来自上游服务器的响应所花费的时间；该时间以秒为单位，精确到毫秒。多个响应的时间用逗号和冒号分隔，类似于 $upstream_addr 变量中的地址。

`$upstream_status`#

保存从上游服务器获取的响应的状态代码。多个响应的状态代码用逗号和冒号分隔，类似于 $upstream_addr 变量中的地址。如果无法选择服务器，则该变量保留 502（Bad Gateway）状态代码。

`$upstream_sticky_status`#

粘性请求的状态。

`""`	没有启用粘性的请求发送到上游。
`NEW`	没有粘性信息的请求。
`HIT`	带有粘性信息的请求路由到所需的服务器。
`MISS`	带有粘性信息的请求路由到通过负载均衡算法选择的服务器。

多个连接的值用逗号和冒号分隔，类似于 $upstream_addr 变量中的地址。

`$upstream_trailer_<name>`#

保存从上游服务器获取的响应末尾的字段。