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

Синтаксис	backup_switch permanent[=время];
По умолчанию	—
Контекст	upstream

Директива включает активные резервные серверы для upstream, где она используется. Если для запроса не удается выбрать сервер в основной группе, и он переходит к резервной группе, эта группа становится активной, если директива задана. Последующие запросы сначала направляются на серверы активной группы.

Когда permanent определен без значения времени, группа остаётся активной после выбора, и автоматическая переоценка не происходит. Если время установлено, активный статус истекает через заданный интервал, и балансировщик снова проверяет основную группу, возвращаясь к ней, если серверы работают нормально.

Пример:

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

Синтаксис	bind_conn значение;
По умолчанию	—
Контекст	upstream

Позволяет привязать серверное соединение к клиентскому в момент, когда значение, заданное строкой из переменных, становится отличным от "" и "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

Синтаксис	feedback переменная [inverse] [factor=число] [account=условная_переменная] [last_byte];
По умолчанию	—
Контекст	upstream

Задает в upstream механизм балансировки нагрузки по обратной связи. Он динамически корректирует решения при балансировке, умножая вес каждого проксируемого сервера на среднее значение обратной связи, которое меняется с течением времени в зависимости от значения переменной и подчиняется необязательному условию.

Могут быть заданы следующие параметры:

переменная	Переменная, из которой берется значение обратной связи. Она должна представлять собой метрику производительности или состояния; предполагается, что сервер передает ее в заголовках или иным образом. Значение оценивается при каждом ответе от сервера и учитывается в скользящем среднем согласно настройкам 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 ключ [consistent];
По умолчанию	—
Контекст	upstream

Задает метод балансировки нагрузки для группы, при котором соответствие клиента серверу определяется при помощи хэшированного значения ключа. В качестве ключа может использоваться текст, переменные и их комбинации. Следует отметить, что любое добавление или удаление серверов в группе может привести к перераспределению большинства ключей на другие серверы. Метод совместим с библиотекой Perl Cache::Memcached.

Если задан параметр consistent, то вместо вышеописанного метода будет использоваться метод консистентного хэширования ketama. Метод гарантирует, что при добавлении сервера в группу или его удалении на другие серверы будет перераспределено минимальное число ключей. Применение метода для кэширующих серверов обеспечивает больший процент попаданий в кэш. Метод совместим с библиотекой Perl Cache::Memcached::Fast при значении параметра ketama_points, равном 160.

ip_hash

Синтаксис	ip_hash;
По умолчанию	—
Контекст	upstream

Задает для группы метод балансировки нагрузки, при котором запросы распределяются по серверам на основе IP-адресов клиентов. В качестве ключа для хэширования используются первые три октета IPv4-адреса клиента или IPv6-адрес клиента целиком. Метод гарантирует, что запросы одного и того же клиента будут всегда передаваться на один и тот же сервер. Если же этот сервер будет считаться недоступным, то запросы этого клиента будут передаваться на другой сервер. С большой долей вероятности это также будет один и тот же сервер.

Если один из серверов нужно убрать на некоторое время, то для сохранения текущего хэширования IP-адресов клиентов этот сервер нужно пометить параметром down:

upstream backend {
    ip_hash;

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

keepalive

Синтаксис	keepalive соединения;
По умолчанию	—
Контекст	upstream

Задействует кэш соединений для группы серверов.

Параметр соединения устанавливает максимальное число неактивных постоянных соединений с серверами группы, которые будут сохраняться в кэше каждого рабочего процесса. При превышении этого числа наиболее давно не используемые соединения закрываются.

Примечание

Следует особо отметить, что директива keepalive не ограничивает общее число соединений с серверами группы, которые рабочие процессы Angie могут открыть. Параметр соединения следует устанавливать достаточно консервативно, чтобы серверы группы по-прежнему могли обрабатывать новые входящие соединения.

Внимание

Директива 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 "";
    #    ...
    }
}

Примечание

Хоть это и не рекомендуется, но также возможно использование постоянных соединений с HTTP/1.0, путем передачи поля заголовка "Connection: Keep-Alive" серверу группы.

Для работы постоянных соединений с 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 число;
По умолчанию	keepalive_requests 1000;
Контекст	upstream

Задает максимальное число запросов, которые можно сделать по одному постоянному соединению. После того как сделано максимальное число запросов, соединение закрывается.

Периодическое закрытие соединений необходимо для освобождения памяти, выделенной под конкретные соединения. Поэтому использование слишком большого максимального числа запросов может приводить к чрезмерному потреблению памяти и не рекомендуется.

keepalive_time

Синтаксис	keepalive_time время;
По умолчанию	keepalive_time 1h;
Контекст	upstream

Ограничивает максимальное время, в течение которого могут обрабатываться запросы в рамках постоянного соединения. По достижении заданного времени соединение закрывается после обработки очередного запроса.

keepalive_timeout

Синтаксис	keepalive_timeout время;
По умолчанию	keepalive_timeout 60s;
Контекст	upstream

Задает таймаут, в течение которого неактивное постоянное соединение с сервером группы не будет закрыто.

least_conn

Синтаксис	least_conn;
По умолчанию	—
Контекст	upstream

Задает для группы метод балансировки нагрузки, при котором запрос передается серверу с наименьшим числом активных соединений, с учетом весов серверов. Если подходит сразу несколько серверов, они выбираются циклически (в режиме round-robin) с учетом их весов.

least_time

Синтаксис	least_time header | last_byte [factor=число] [account=условная_переменная];
По умолчанию	—
Контекст	upstream

Задает для группы метод балансировки нагрузки, при котором вероятность передачи запроса активному серверу обратно пропорциональна среднему времени его ответа; чем оно меньше, тем больше запросов будет получать сервер.

header	Директива учитывает среднее время получения заголовков ответа.
last_byte	Директива использует среднее время получения полного ответа.

factor	Выполняет ту же функцию, что и response_time_factor, и переопределяет его, если параметр задан.
account	Указывает условную переменную, которая контролирует, какие ответы учитываются при расчете. Среднее значение обновляется, только если условная переменная ответа не равна "" или "0". Примечание По умолчанию ответы в ходе активных проверо` не включаются в расчет; комбинация переменной $upstream_probe с account позволяет включить эти ответы или даже исключить все остальное.

Текущие значения представлены как header_time (только заголовки) и response_time (ответы целиком) в объекте health сервера среди метрик апстрима в API.

queue

Синтаксис	queue число [timeout=время];
По умолчанию	—
Контекст	upstream

Если для запроса не удается назначить проксируемый сервер с первой попытки (например, при краткосрочном перебое в работе или всплеске нагрузки с достижением предела max_conns), запрос не отклоняется; вместо этого Angie ADC пытается поставить его в очередь на обработку.

Численный параметр директивы задает максимальное количество запросов в очереди рабочего процесса. Если очередь целиком заполнена, клиенту отдается ошибка 502 (Bad Gateway).

Примечание

К запросам в очереди также применяется логика директивы proxy_next_upstream. В частности, если для запроса был выбран сервер, но передать его туда не удалось, то он может вернуться в очередь.

Если сервер для передачи запроса в очереди не был выбран за время timeout (по умолчанию — 60 секунд), клиенту отдается ошибка 502 (Bad Gateway). Еще из очереди удаляются запросы от клиентов, преждевременно закрывших соединение; в API есть счетчики состояний запросов, проходящих через очередь.

Внимание

Директива queue должна использоваться после всех директив, задающих тот или иной метод балансировки нагрузки, иначе она не будет работать.

random

Синтаксис	random [two];
По умолчанию	—
Контекст	upstream

Задает для группы метод балансировки нагрузки, при котором запрос передается случайно выбранному серверу, с учетом весов серверов.

Если указан необязательный параметр two, Angie случайным образом выбирает два сервера, из которых выбирает сервер, используя метод least_conn, при котором запрос передается на сервер с наименьшим количеством активных соединений.

response_time_factor

Синтаксис	response_time_factor число;
По умолчанию	response_time_factor 90;
Контекст	upstream

Задает для метода балансировки нагрузки least_time коэффициент сглаживания предыдущего значения при вычислении среднего времени ответа по формуле экспоненциально взвешенного скользящего среднего.

Чем больше указанное число, тем меньше новые значения влияют на среднее; если указать 90, то будет взято 90 % от предыдущего значения и лишь 10 % от нового. Допустимые значения — от 0 до 99 включительно.

Текущие результаты вычислений представлены как header_time (только заголовки) и response_time (ответы целиком) в объекте health сервера среди метрик апстрима в API.

Примечание

При подсчете учитываются только успешные ответы; что считать неуспешным ответом, определяют директивы proxy_next_upstream, fastcgi_next_upstream, uwsgi_next_upstream, scgi_next_upstream, memcached_next_upstream и grpc_next_upstream. Кроме того, значение header_time пересчитывается, только если получены и обработаны все заголовки, а response_time — только если получен весь ответ.

server

Синтаксис	server адрес [параметры];
По умолчанию	—
Контекст	upstream

Задает адрес и другие параметры сервера. Адрес может быть указан в виде доменного имени или IP-адреса, и необязательного порта, или в виде пути UNIX-сокета, который указывается после префикса unix:. Если порт не указан, используется порт 80. Доменное имя, которому соответствует несколько IP-адресов, задает сразу несколько серверов.

Могут быть заданы следующие параметры:

weight=число	Задает вес сервера. По умолчанию — 1.
max_conns=число	Ограничивает максимальное число одновременных активных соединений к проксируемому серверу. Значение по умолчанию равно 0 и означает, что ограничения нет. Если группа не находится в зоне разделяемой памяти, то ограничение работает отдельно для каждого рабочего процесса.

Примечание

При включенных неактивных постоянных соединениях, нескольких рабочих процессах и зоне разделяемой памяти суммарное число активных и неактивных соединений с проксируемым сервером может превышать значение max_conns.

max_fails=число — задает число неудачных попыток связи с сервером, которые должны произойти в течение заданного fail_timeout времени для того, чтобы сервер считался недоступным; после этого он будет повторно проверен через то же самое время.

Что считается неудачной попыткой, определяется директивами proxy_next_upstream, fastcgi_next_upstream, uwsgi_next_upstream, scgi_next_upstream, memcached_next_upstream и grpc_next_upstream.

При превышении max_fails сервер также признается неработающим с точки зрения upstream_probe; клиентские запросы не будут направляться к нему, пока проверки не признают его работающим.

Примечание

Если директива server в группе разрешается в несколько серверов, ее настройка max_fails применяется к каждому серверу отдельно.

Если после разрешения всех директив server в апстриме остается только один сервер, настройка max_fails не действует и будет проигнорирована.

max_fails=1	Число попыток по умолчанию;
max_fails=0	Отключает учет попыток.

fail_timeout=время — задает период времени, в течение которого должно произойти определенное число неудачных попыток связи с сервером (max_fails), чтобы сервер считался недоступным. Затем сервер остается недоступным в течение того же самого времени, прежде чем будет проверен повторно.

Значение по умолчанию — 10 секунд.

Примечание

Если директива server в группе разрешается в несколько серверов, ее настройка fail_timeout применяется к каждому серверу отдельно.

Если после разрешения всех директив server в апстриме остается только один сервер, настройка fail_timeout не действует и будет проигнорирована.

backup	Помечает сервер как запасной. На него будут передаваться запросы в случае, если не работают основные серверы. Можно создать несколько групп резервирования серверов и задать уровень для каждой группы с помощью backup=<уровень_группы>. Например, backup=1 или просто backup — группа резервных серверов первого уровня, (в API отображается как true), backup=2 — группа резервных серверов второго уровня, (в API отображается как соответствующее число). Если задана директива backup_switch, также применяется ее логика активного резервирования.
down	Помечает сервер как постоянно недоступный.
drain	Помечает сервер как разгружаемый (draining); это значит, что он получает только запросы сессий, привязанных ранее через sticky. В остальном поведение такое же, как в режиме down.

Осторожно

Параметр backup нельзя использовать совместно с методами балансировки нагрузки hash, ip_hash и random.

Параметры down и drain взаимно исключающие.

resolve

Позволяет отслеживать изменения списка IP-адресов, соответствующего доменному имени, и обновлять его без перезагрузки конфигурации. При этом группа должна находиться в зоне разделяемой памяти; также должен быть определен преобразователь имен в адреса.

service=имя

Включает преобразование SRV-записей DNS и задает имя сервиса. Для работы параметра необходимо задать параметр resolve у сервера, не указывая порт сервера при имени хоста. Если в имени службы нет точек, формируется имя по стандарту RFC: к имени службы добавляется префикс _, затем через точку добавляется _tcp. Так, имя службы http даст в результате _http._tcp. Angie разрешает SRV-записи, объединяя нормализованное имя службы и имя хоста и получая список серверов для полученной комбинации через DNS, вместе с их приоритетами и весами. SRV-записи с наивысшим приоритетом (те, которые имеют минимальное значение приоритета) разрешаются как основные серверы, а прочие записи становятся запасными серверами. Если backup установлено с server, SRV-записи с наивысшим приоритетом разрешаются как запасные серверы, а прочие записи игнорируются. Вес аналогичен параметру weight директивы server. Если вес задан как в самой директиве, так и в SRV-записи, используется вес, установленный в директиве.

В этом примере выполняется поиск записи _http._tcp.backend.example.com:

server backend.example.com service=http resolve;

sid=id

Задает ID сервера в группе. Если параметр не задан, то ID задается как шестнадцатеричный MD5-хэш IP-адреса и порта или пути UNIX-сокета.

slow_start=время

Задает время восстановления веса сервера, возвращающегося к работе при балансировке нагрузки методом round-robin или least_conn. Если параметр задан и сервер после сбоя снова считается работающим с точки зрения max_fails и upstream_probe, то такой сервер равномерно набирает указанный для него вес в течение заданного времени. Если параметр не задан, то в аналогичной ситуации сервер сразу начинает работу с указанным для него весом.

Примечание

Если в апстриме задан только один server, slow_start не работает и будет игнорироваться.

state

Синтаксис	state файл;
По умолчанию	—
Контекст	upstream

Указывает файл, где постоянно хранится список серверов апстрима. При установке из наших пакетов для хранения таких файлов специально создается каталог /var/lib/angie/state/ (/var/db/angie/state/ во FreeBSD) с соответствующими правами доступа, и в конфигурации остается добавить лишь имя файла:

upstream backend {

    zone backend 1m;
    state /var/lib/angie/state/<ИМЯ ФАЙЛА>;
}

Список серверов здесь имеет формат, аналогичный server. Содержимое файла изменяется при любом изменении серверов в разделе /config/http/upstreams/ через API конфигурации. Файл считывается при запуске Angie ADC или перезагрузке конфигурации.

Осторожно

Чтобы использовать директиву state в блоке upstream, в нем не должно быть директив server, но нужна зона разделяемой памяти (zone).

sticky

Синтаксис	sticky cookie name [attr=значение]...; sticky route $variable...; sticky learn zone=зона create=$create_var1... lookup=$lookup_var1... [header] [timeout=время]; sticky learn zone=зона lookup=$lookup_var1... remote_action=uri remote_result=$remote_var [timeout=время];
По умолчанию	—
Контекст	upstream

Настраивает привязку клиентских сессий к проксируемым серверам в режиме, заданном первым параметром; для разгрузки серверов, у которых задана директива sticky, можно использовать опцию drain в блоке server.

Внимание

Директива sticky должна использоваться после всех директив, задающих тот или иной метод балансировки нагрузки, иначе она не будет работать. Если она используется наряду с директивой bind_conn, то bind_conn должна стоять после sticky.

Режим cookieРежим routeРежим learnРежим learn с remote_action

Этот режим использует cookie для хранения сессий. Он подходит для ситуаций, когда cookie уже используются для управления сессиями.

Здесь запрос от клиента, пока не привязанного к какому-то серверу, отправляется на сервер, выбираемый согласно настроенному методу балансировки. При этом Angie устанавливает cookie с уникальным значением, идентифицирующим сервер.

Имя cookie (name) задается директивой sticky, а значение (value) соответствует параметру sid директивы server. Учтите, что параметр дополнительно хэшируется, если задана директива sticky_secret.

Последующие запросы от клиента, содержащие такой cookie, передаются на сервер, заданный значением cookie, то есть сервер с указанным sid. Если выбрать сервер не удается или выбранный сервер не может обработать запрос, то будет выбран другой сервер согласно настроенному методу балансировки.

Директива позволяет назначать атрибуты такого cookie; единственный атрибут, устанавливаемый по умолчанию, — path=/. Значения атрибутов задаются строками с переменными. Чтобы удалить атрибут, задайте для него пустое значение: attr=. Так, sticky cookie path= задает cookie без атрибута path.

Здесь Angie создает cookie srv_id со сроком действия в 1 час и доменом, заданным переменной:

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

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

sticky_secret

Синтаксис	sticky_secret строка;
По умолчанию	—
Контекст	upstream

Добавляет строку как соль в функцию MD5-хэширования для директивы sticky в режимах cookie и route. Строка может содержать переменные, например $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 ADC будет возвращать клиенту ошибку HTTP 502, если желаемый сервер недоступен, вместо использования любого другого доступного сервера, как это происходит, когда в группе нет доступных серверов.

upstream

Синтаксис	upstream имя { ... }
По умолчанию	—
Контекст	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;
}

По умолчанию запросы распределяются по серверам циклически (в режиме round-robin) с учетом весов серверов. В вышеприведенном примере каждые 7 запросов будут распределены так: 5 запросов на backend1.example.com и по одному запросу на второй и третий серверы.

Если при попытке работы с сервером происходит ошибка, то запрос передается следующему серверу, и так далее до тех пор, пока не будут опробованы все работающие серверы. Если не удастся получить успешный ответ ни от одного из серверов, то клиенту будет возвращен результат работы с последним сервером.

zone

Синтаксис	zone имя [размер];
По умолчанию	—
Контекст	upstream

Задает имя и размер зоны разделяемой памяти, в которой хранятся конфигурация группы и ее рабочее состояние, разделяемые между рабочими процессами. В одной и той же зоне могут быть сразу несколько групп. В этом случае достаточно указать размер только один раз.

Встроенные переменные

Модуль http_upstream поддерживает следующие встроенные переменные:

$sticky_sessid

Используется с remote_action в sticky; хранит начальный идентификатор сессии, взятый из lookup.

$sticky_sid

Используется с remote_action в sticky; хранит идентификатор сервера, предварительно связанный с сессией.

$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

Если сервер не может быть выбран, то переменная хранит имя группы серверов.

$upstream_bytes_received

число байт, полученных от сервера группы. Значения нескольких соединений разделяются запятыми и двоеточиями подобно адресам в переменной $upstream_addr.

$upstream_bytes_sent

число байт, переданных на сервер группы. Значения нескольких соединений разделяются запятыми и двоеточиями подобно адресам в переменной $upstream_addr.

$upstream_cache_status

хранит статус доступа к кэшу ответов. Статус может быть одним из MISS, BYPASS, EXPIRED, STALE, UPDATING, REVALIDATED или HIT:

• MISS: Ответ не найден в кэше, и запрос передан на сервер.

• BYPASS: Кэш обойден, и запрос напрямую передан на сервер.

• EXPIRED: Ответ в кэше устарел, и на сервер передан новый запрос для обновления контента.

• STALE: Ответ в кэше устарел, но по-прежнему передается клиентам, пока через какое-то время не произойдет обновление контента c сервера.

• UPDATING: Ответ в кэше устарел, но по-прежнему передается клиентам, пока уже идущее обновление контента c сервера не завершится.

• REVALIDATED: Ответ в кэше устарел, но был успешно перепроверен и не нуждается в обновлении с сервера.

• HIT: Ответ был взят из кэша.

Если запрос пошел в обход кэша без обращения к нему, переменная не устанавливается.

$upstream_connect_time

хранит время, затраченное на установление соединения с сервером группы; время хранится в секундах с точностью до миллисекунд. В случае SSL включает в себя время, потраченное на рукопожатие. Времена нескольких соединений разделяются запятыми и двоеточиями подобно адресам в переменной $upstream_addr.

$upstream_cookie_<имя>

cookie с указанным именем, переданный сервером группы в поле "Set-Cookie" заголовка ответа. Необходимо иметь в виду, что cookie запоминаются только из ответа последнего сервера.

$upstream_header_time

хранит время, затраченное на получение заголовка ответа от сервера группы; время хранится в секундах с точностью до миллисекунд. Времена нескольких ответов разделяются запятыми и двоеточиями подобно адресам в переменной $upstream_addr.

$upstream_http_<имя>

хранят поля заголовка ответа сервера. Например, поле заголовка ответа Server доступно в переменной $upstream_http_server. Правила преобразования имен полей заголовка ответа в имена переменных такие же, как для переменных с префиксом "$http_". Необходимо иметь в виду, что поля заголовка запоминаются только из ответа последнего сервера.

$upstream_queue_time

хранит время, проведенное запросом в очереди до очередного выбора сервера и выраженное в секундах с точностью до миллисекунд. Времена нескольких попыток разделяются запятыми и двоеточиями подобно адресам в переменной $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_<имя>

Хранит поля из конца ответа, полученного от сервера группы.