Модуль ngx_http_upstream_module

• Пример конфигурации
• Директивы
• upstream
• server
• зона
• состояние
• hash
• ip_hash
• keepalive
• keepalive_requests
• keepalive_time
• keepalive_timeout
• ntlm
• least_conn
• least_time
• очередь
• random
• resolver
• resolver_timeout
• sticky
• sticky_cookie_insert
• Встроенные переменные

Модуль ngx_http_upstream_module используется для определения групп серверов, которые могут быть использованы в директивах proxy_pass, fastcgi_pass, uwsgi_pass, scgi_pass, memcached_pass и grpc_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;
    }
}

Динамически настраиваемая группа с периодическими проверками работоспособности доступна в рамках нашей коммерческой подписки:

resolver 10.0.0.1;

upstream dynamic {
    zone upstream_dynamic 64k;

    server backend1.example.com      weight=5;
    server backend2.example.com:8080 fail_timeout=5s slow_start=30s;
    server 192.0.2.1                 max_fails=3;
    server backend3.example.com      resolve;
    server backend4.example.com      service=http resolve;

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

server {
    location / {
        proxy_pass http://dynamic;
        health_check;
    }
}

Директивы

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

Определяет address и другие parameters сервера. Адрес может быть указан в виде доменного имени или IP-адреса с необязательным портом или как путь к сокету UNIX-домена, указанный после префикса «unix:». Если порт не указан, используется порт 80. Доменное имя, разрешающее несколько IP-адресов, определяет сразу несколько серверов.

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

weight=number

устанавливает вес сервера, по умолчанию 1.

max_conns=number

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

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

С версии 1.5.9 до версии 1.11.5 этот параметр был доступен в рамках нашей коммерческой подписки.

max_fails=number

устанавливает количество неудачных попыток связи с сервером, которое должно произойти в течение периода, заданного параметром fail_timeout, для того, чтобы считать сервер недоступным в течение периода, также заданного параметром fail_timeout. По умолчанию количество неудачных попыток равно 1. Ноль отключает подсчет попыток. Что считается неудачной попыткой, определяется директивами proxy_next_upstream, fastcgi_next_upstream, uwsgi_next_upstream, scgi_next_upstream, memcached_next_upstream и grpc_next_upstream.

fail_timeout=time

устанавливает

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

По умолчанию параметр установлен на 10 секунд.

backup

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

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

down

помечает сервер как постоянно недоступный.

Дополнительно, следующие параметры доступны в рамках нашей коммерческой подписки:

resolve

отслеживает изменения IP-адресов, соответствующих доменному имени сервера, и автоматически изменяет конфигурацию upstream без необходимости перезапуска nginx (1.5.12). Группа серверов должна находиться в общей памяти.

Для работы этого параметра необходимо указать директиву resolver в блоке http или в соответствующем блоке upstream.

route=string

устанавливает имя маршрута сервера.

service=name

разрешает DNS SRV записи и устанавливает имя сервиса name (1.9.13). Для работы этого параметра необходимо указать параметр resolve для сервера и указать имя хоста без номера порта.

Если имя сервиса не содержит точки (“.”), то создается совместимое с RFC имя и протокол TCP добавляется к префиксу сервиса. Например, для поиска записи _http._tcp.backend.example.com SRV необходимо указать директиву:

server backend.example.com service=http resolve;

Если имя сервиса содержит одну или несколько точек, то имя формируется путем объединения префикса сервиса и имени сервера. Например, для поиска записей _http._tcp.backend.example.com и server1.backend.example.com SRV необходимо указать директивы:

server backend.example.com service=_http._tcp resolve;
server example.com service=server1.backend resolve;

SRV-записи с наивысшим приоритетом (записи с одинаковым наименьшим значением приоритета) разрешаются как первичные серверы, остальные SRV-записи разрешаются как резервные серверы. Если для сервера указан параметр backup, записи SRV с высоким приоритетом разрешаются как резервные серверы, остальные записи SRV игнорируются.

slow_start=time

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

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

drain

переводит сервер в режим «опорожнения» (1.13.6). В этом режиме на него будут проксироваться только запросы связанные с сервером.

До версии 1.13.6 параметр можно было изменить только с помощью модуля API.

Если в группе только один сервер, параметры max_fails, fail_timeout и slow_start игнорируются, и такой сервер никогда не будет считаться недоступным.

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

Кроме того, такие группы, в рамках нашей коммерческой подписки, позволяют изменять состав группы или изменять параметры определенного сервера без необходимости перезапуска nginx. Конфигурация доступна через модуль API (1.13.3).

До версии 1.13.3 конфигурация была доступна только через специальный раздел, обрабатываемый upstream_conf.

state /var/lib/nginx/state/servers.conf; # path for Linux
state /var/db/nginx/state/servers.conf;  # path for FreeBSD

В настоящее время состояние ограничено списком серверов с их параметрами. Файл читается при разборе конфигурации и обновляется каждый раз, когда конфигурация вышестоящего уровня изменяется. Избегайте прямого изменения содержимого файла. Директива не может использоваться вместе с директивой server.

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

Данная директива доступна в рамках нашей коммерческой подписки.

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

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

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

Поддержка адресов IPv6 доступна начиная с версий 1.3.2 и 1.2.2.

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

Пример:

upstream backend {
    ip_hash;

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

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

Активирует кэш для подключений к серверам вышестоящего уровня.

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

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

При использовании методов балансировки нагрузки, отличных от метода по умолчанию (round-robin), необходимо активировать их перед директивой keepalive.

Пример конфигурации memcached upstream с подключениями keepalive:

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, чтобы подключения keepalive работали:

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.

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

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

До версии 1.19.10 значение по умолчанию составляло 100.

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

Устанавливает таймаут, в течение которого простаивающее подключение keepalive к серверу вышестоящего уровня остаётся открытым.

Разрешает проксирование запросов с аутентификацией NTLM. Подключение к серверу вышестоящего уровня связывается с подключением клиента после того, как клиент отправит запрос со значением поля заголовка “Authorization”, начинающимся с “Negotiate” или “NTLM”. Дальнейшие запросы клиента будут проксироваться через то же подключение к серверу вышестоящего уровня, сохраняя контекст аутентификации.

Для работы аутентификации NTLM необходимо включить подключения keepalive к серверам вышестоящего уровня. Директива proxy_http_version должна быть установлена на “1.1”, а поле заголовка “Connection” должно быть очищено:

upstream http_backend {
    server 127.0.0.1:8080;

    ntlm;
}

server {
    ...

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

При использовании методов балансировки нагрузки, отличных от метода по умолчанию (round-robin), необходимо активировать их перед директивой ntlm.

Данная директива доступна в рамках нашей коммерческой подписки.

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

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

Если указан параметр header, используется время получения заголовка ответа response header. Если указан параметр last_byte, используется время получения полного ответа full response. Если указан параметр inflight (1.11.6), также учитываются незавершенные запросы.

До версии 1.11.6 незавершенные запросы учитывались по умолчанию.

Данная директива доступна в рамках нашей коммерческой подписки.

Если сервер вышестоящего уровня не может быть выбран немедленно во время обработки запроса, запрос помещается в очередь. Директива задаёт максимальное number запросов, которые могут одновременно находиться в очереди. Если очередь заполнена или сервер для передачи запроса не может быть выбран в течение заданного в параметре timeout периода времени, клиенту будет возвращено сообщение об ошибке 502 (Bad Gateway).

Значение параметра timeout по умолчанию составляет 60 секунд.

При использовании методов балансировки нагрузки, отличных от метода по умолчанию (round-robin), необходимо активировать их перед директивой queue.

Данная директива доступна в рамках нашей коммерческой подписки.

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

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

Метод least_time перенаправляет запрос на сервер с наименьшим средним временем отклика и наименьшим количеством активных соединений. Если указан least_time=header, используется время получения заголовка ответа response header. Если указан least_time=last_byte, используется время получения полного ответа full response.

Метод least_time доступен в рамках нашей коммерческой подписки.

Настраивает серверы имен, используемые для разрешения имён серверов upstream в адреса, например:

resolver 127.0.0.1 [::1]:5353;

Адрес может быть указан как доменное имя или IP-адрес с необязательным портом. Если порт не указан, используется порт 53. Серверы имен запрошиваются в порядке круговой очереди.

По умолчанию nginx ищет как IPv4, так и IPv6-адреса при разрешении. Если поиск IPv4 или IPv6-адресов нежелателен, можно указать параметр ipv4=off (1.23.1) или ipv6=off.

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

resolver 127.0.0.1 [::1]:5353 valid=30s;

Для предотвращения подмены DNS рекомендуется настроить DNS-серверы в надлежащим образом защищённой доверенной локальной сети.

Необязательный параметр status_zone включает сбор статистики DNS-серверов по запросам и ответам в указанной zone.

Данная директива доступна в рамках нашей коммерческой подписки.

Устанавливает таймаут для разрешения имён, например:

resolver_timeout 5s;

Данная директива доступна в рамках нашей коммерческой подписки.

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

cookie

При использовании метода cookie, информация о назначенном сервере передаётся в HTTP-cookie, сгенерированном nginx:

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

    sticky cookie srv_id expires=1h domain=.example.com path=/;
}

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

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

Первый параметр задаёт имя cookie, которое нужно установить или проверить. Значение cookie — шестнадцатеричное представление MD5-хеша IP-адреса и порта или пути сокета UNIX-домена. Однако, если задан параметр «route» директивы server, значение cookie будет значением параметра «route»:

upstream backend {
    server backend1.example.com route=a;
    server backend2.example.com route=b;

    sticky cookie srv_id expires=1h domain=.example.com path=/;
}

В этом случае значение cookie «srv_id» будет либо a, либо b.

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

expires=time

Устанавливает time срока хранения cookie в браузере. Специальное значение max заставит cookie истечь при «31 Dec 2037 23:55:55 GMT». Если параметр не указан, cookie истечёт в конце сессии браузера.

domain=domain

Определяет domain срока хранения cookie. Значение параметра может содержать переменные (1.11.5).

httponly

Добавляет атрибут HttpOnly к cookie (1.7.11).

samesite=strict | lax | none | $variable

Добавляет атрибут SameSite (1.19.4) к cookie с одним из следующих значений: Strict, Lax, None, или используя переменные (1.23.3). В последнем случае, если значение переменной пустое, атрибут SameSite не будет добавлен в cookie, если значение резольвится в Strict, Lax, или None, соответствующее значение будет присвоено, иначе будет присвоено значение Strict.

secure

Добавляет атрибут Secure к cookie (1.7.11).

path=path

Определяет path срока хранения cookie.

Если какие-либо параметры опущены, соответствующие поля cookie не устанавливаются.

route

При использовании метода route, проксируемый сервер назначает клиенту маршрут при получении первого запроса. Все последующие запросы от этого клиента будут содержать информацию о маршрутизации в cookie или URI. Эта информация сравнивается с параметром «route» директивы server для определения сервера, на который должен быть проксирован запрос. Если параметр «route» не указан, имя маршрута будет шестнадцатеричным представлением MD5-хеша IP-адреса и порта или пути сокета UNIX-домена. Если назначенный сервер не может обработать запрос, новый сервер выбирается используемым методом балансировки, как если бы информация о маршрутизации в запросе отсутствовала.

Параметры метода route задают переменные, которые могут содержать информацию о маршрутизации. Первая непустая переменная используется для поиска соответствующего сервера.

Пример:

map $cookie_jsessionid $route_cookie {
    ~.+\.(?P<route>\w+)$ $route;
}

map $request_uri $route_uri {
    ~jsessionid=.+\.(?P<route>\w+)$ $route;
}

upstream backend {
    server backend1.example.com route=a;
    server backend2.example.com route=b;

    sticky route $route_cookie $route_uri;
}

Здесь маршрут берётся из cookie «JSESSIONID», если он присутствует в запросе. В противном случае используется маршрут из URI.

learn

При использовании метода learn (1.7.1) nginx анализирует ответы серверов upstream и определяет сессии, инициированные сервером, обычно передаваемые в HTTP-cookie.

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

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

В примере сервер upstream создаёт сессию, устанавливая cookie «EXAMPLECOOKIE» в ответе. Дальнейшие запросы с этим cookie будут передаваться тому же серверу. Если сервер не может обработать запрос, выбирается новый сервер, как если бы клиент не был привязан.

Параметры create и lookup задают переменные, которые указывают, как создаются новые сессии и как ищутся существующие сессии соответственно. Оба параметра могут быть указаны несколько раз, в этом случае используется первая непустая переменная.

Сессии хранятся в зоне общей памяти, чьи name и size настраиваются параметром zone. Одна мегабайтовая зона может хранить около 4000 сессий на 64-битной платформе. Сессии, которые не обработаны в течение времени, указанного параметром timeout, удаляются из зоны. По умолчанию timeout установлен на 10 минут.

Параметр header (1.13.1) позволяет создать сессию сразу после получения заголовков ответа от сервера upstream.

Параметр sync (1.13.8) включает синхронизацию зоны общей памяти synchronization.

Данная директива доступна в рамках нашей коммерческой подписки.

Данная директива устарела с версии 1.5.7. Вместо неё следует использовать эквивалентную директиву sticky с новым синтаксисом:

sticky cookie name [expires=time] [domain=domain] [path=path];

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

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

$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

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

$upstream_bytes_sent

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

$upstream_cache_status

хранит статус доступа к кешу ответа (0.8.3). Статус может быть «MISS», «BYPASS», «EXPIRED», «STALE», «UPDATING», «REVALIDATED» или «HIT».

$upstream_connect_time

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

$upstream_cookie_name

куки с указанным name, отправленным сервером-источником в поле ответа «Set-Cookie» (1.7.1). Сохраняются только куки из ответа последнего сервера.

$upstream_header_time

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

$upstream_http_name

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

$upstream_last_server_name

хранит имя последнего выбранного сервера-источника (1.25.3); позволяет передавать его через SNI:

proxy_ssl_server_name on;
proxy_ssl_name        $upstream_last_server_name;

Эта переменная доступна в рамках нашей коммерческой подписки.

$upstream_queue_time

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

$upstream_response_length

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

$upstream_response_time

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

$upstream_status

хранит код состояния ответа, полученного от сервера-источника. Коды состояний нескольких ответов разделяются запятыми и двоеточиями, как адреса в переменной $upstream_addr. Если сервер не может быть выбран, переменная хранит код состояния 502 (Bad Gateway).

$upstream_trailer_name

хранит поля из конца ответа, полученного от сервера-источника (1.13.10).