Модуль ngx_http_upstream_module

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

Модуль 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

ограничивает максимальное 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). Группа серверов должна находиться в разделяемой памяти.

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

До версии 1.27.3 этот параметр был доступен только в рамках нашей коммерческой подписки.

service=name

включает разрешение DNS-записей SRV и задаёт имя службы name (1.9.13). Чтобы этот параметр работал, необходимо указать параметр resolve для сервера и задать имя хоста без номера порта.

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

server backend.example.com service=http resolve;

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

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

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

До версии 1.27.3 этот параметр был доступен только в рамках нашей коммерческой подписки.

route=string

задаёт имя маршрута сервера.

До версии 1.29.6 этот параметр был доступен только в рамках нашей коммерческой подписки.

drain

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

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

До версии 1.29.6 этот параметр был доступен только в рамках нашей коммерческой подписки.

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

slow_start=time

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

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

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

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

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

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

Указывает file, в котором хранится состояние группы с динамически изменяемой конфигурацией.

Примеры:

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

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

Включает или отключает кэширование keepalive-соединений с upstream-серверами. Начиная с версии 1.29.7 кэширование соединений включено по умолчанию, и эти соединения не используются совместно разными location.

Параметр local (1.29.7) отключает совместное использование кэшированных keepalive-соединений разными location, даже если адрес upstream-сервера совпадает. Если параметр local не указан, можно повторно использовать любое подходящее кэшированное соединение с тем же upstream-сервером независимо от location.

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

Начиная с версии 1.29.7 keepalive-соединения включены по умолчанию; установленный по умолчанию предел составляет 32 соединений для каждого рабочего процесса.

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

До версии 1.29.7 при использовании методов балансировки нагрузки, отличных от метода циклического перебора по умолчанию, их необходимо было активировать перед директивой keepalive.

Пример конфигурации upstream для memcached с 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» (по умолчанию начиная с версии 1.29.7) или «2», а поле заголовка «Connection» следует очистить. Этот пример предназначен для версий до 1.29.7:

upstream http_backend {
    server 127.0.0.1:8080;

    keepalive 16;
}

server {
    ...

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

В качестве альтернативы можно использовать постоянные соединения HTTP/1.0, передавая upstream-серверу поле заголовка «Connection: Keep-Alive», однако этот способ не рекомендуется.

Для работы keepalive-соединений с 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-соединений отсутствует.

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

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

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

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

Задаёт тайм-аут, в течение которого неактивное keepalive-соединение с upstream-сервером остаётся открытым.

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

Для работы аутентификации NTLM необходимо включить keepalive-соединения с upstream-серверами. Директиву proxy_http_version следует задать равной «1.1» (по умолчанию начиная с версии 1.29.7) или «2», а поле заголовка «Connection» следует очистить. Этот пример предназначен для версий до 1.29.7:

upstream http_backend {
    server 127.0.0.1:8080;

    ntlm;
}

server {
    ...

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

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

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

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

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

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

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

До версии 1.31.0 эта директива была доступна только в рамках нашей коммерческой подписки.

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

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

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

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

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

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

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

Метод 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 (1.17.5) включает сбор статистики запросов и ответов DNS-сервера в указанной zone. Параметр доступен в рамках нашей коммерческой подписки.

Начиная с версии 1.17.5 и до версии 1.27.3 эта директива была доступна только в рамках нашей коммерческой подписки.

Задаёт тайм-аут разрешения имён, например:

resolver_timeout 5s;

Начиная с версии 1.17.5 и до версии 1.27.3 эта директива была доступна только в рамках нашей коммерческой подписки.

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

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

Добавляет к cookie атрибут SameSite (1.19.4) с одним из следующих значений: 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) включает синхронизацию общей зоны памяти. Параметр доступен в рамках нашей коммерческой подписки.

До версии 1.29.6 эта директива была доступна только в рамках нашей коммерческой подписки.

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

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

$upstream_addr

содержит IP-адрес и порт либо путь к UNIX-сокету upstream-сервера. Если при обработке запроса было установлено соединение с несколькими серверами, их адреса разделяются запятыми, например: “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-сервера (1.11.4). Значения для нескольких соединений разделяются запятыми и двоеточиями, как адреса в переменной $upstream_addr.

$upstream_bytes_sent

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

$upstream_cache_status

содержит состояние обращения к кэшу ответов (0.8.3). Состояние может быть одним из следующих: “MISS”, “BYPASS”, “EXPIRED”, “STALE”, “UPDATING”, “REVALIDATED” или “HIT”.

$upstream_connect_time

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

$upstream_cookie_name

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

$upstream_header_time

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

$upstream_http_name

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

$upstream_last_addr

содержит IP-адрес либо путь к UNIX-сокету последнего выбранного upstream-сервера (1.29.3).

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

$upstream_last_server_name

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

proxy_ssl_server_name on;
proxy_ssl_name        $upstream_last_server_name;

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

$upstream_queue_time

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

$upstream_response_length

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

$upstream_response_time

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

$upstream_status

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

$upstream_trailer_name

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