Upstream#

Proporciona un contexto para describir grupos de servidores que pueden usarse en la directiva proxy_pass.

Ejemplo de configuración#

upstream backend {
    hash $remote_addr consistent;
    zone backend 1m;

    server backend1.example.com:1935  weight=5;
    server unix:/tmp/backend3;
    server backend3.example.com       service=_example._tcp resolve;

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

resolver 127.0.0.53 status_zone=resolver;

server {
    listen 1936;
    proxy_pass backend;
}

Directivas#

upstream#

Sintaxis	`upstream` nombre { ... }
Predeterminado	—
Contexto	stream

Describe un grupo de servidores. Los servidores pueden escuchar en diferentes puertos. Además, se pueden mezclar servidores que escuchen en sockets TCP y UNIX.

Ejemplo:

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

    server backup1.example.com:1935  backup;
}

De forma predeterminada, las conexiones se distribuyen entre los servidores utilizando un método de balanceo de carga round-robin ponderado. En el ejemplo anterior, cada 7 conexiones se distribuyen de la siguiente forma: 5 conexiones van a backend1.example.com:1935 y una conexión a cada uno de los servidores segundo y tercero.

Si ocurre un error durante la comunicación con un servidor, la conexión se pasará al siguiente servidor, y así sucesivamente hasta que se prueben todos los servidores en funcionamiento. Si la comunicación con todos los servidores falla, la conexión se cerrará.

server#

Sintaxis	`server` dirección [parámetros];
Predeterminado	—
Contexto	upstream

Define la dirección y otros parámetros de un servidor. La dirección puede especificarse como un nombre de dominio o una dirección IP con un puerto obligatorio, o como una ruta de socket de dominio UNIX especificada tras el prefijo unix:. Un nombre de dominio que resuelva en varias direcciones IP define múltiples servidores a la vez.

Se pueden definir los siguientes parámetros:

`weight=`número	Establece el peso del servidor; por defecto, 1.
`max_conns=`número	Limita el número máximo de conexiones activas simultáneas al servidor proxy. El valor por defecto es `0`, lo que significa que no hay límite. Si el grupo de servidores no reside en la memoria compartida, la limitación funciona por cada proceso worker.

max_fails=número — establece el número de intentos fallidos de comunicación con el servidor que deben ocurrir en el período definido por fail_timeout para considerar al servidor como no disponible; luego se reintenta tras el mismo período.

Aquí, un intento fallido es un error o un timeout al establecer una conexión con el servidor.

Nota

Si una directiva server en un grupo resuelve en varios servidores, su configuración max_fails se aplica a cada servidor individualmente.

Si un upstream contiene solo un servidor después de que todas sus directivas server se resuelvan, la configuración max_fails no tiene efecto y será ignorada.

`max_fails=1`	Número de intentos por defecto.
`max_fails=0`	Desactiva el cómputo de intentos.

fail_timeout=tiempo — establece el período de tiempo durante el cual debe ocurrir un número especificado de intentos fallidos de comunicación con el servidor (max_fails) para considerarlo no disponible. El servidor permanece no disponible durante la misma cantidad de tiempo antes de que se vuelva a intentar.

Por defecto, está configurado en 10 segundos.

Nota

Si una directiva server en un grupo resuelve en varios servidores, su configuración fail_timeout se aplica a cada servidor individualmente.

Si un upstream contiene solo un servidor después de que todas sus directivas server se resuelvan, la configuración fail_timeout no tiene efecto y será ignorada.

`backup`	Marca el servidor como servidor de respaldo. Se le asignarán peticiones cuando los servidores principales no estén disponibles.
`down`	Marca el servidor como no disponible de forma permanente.
`drain` (PRO)	Marca el servidor como en drenaje; esto significa que solo recibe peticiones de las sesiones que fueron vinculadas anteriormente con sticky. De lo contrario, se comporta de forma similar a `down`.

Advertencia

El parámetro backup no puede usarse junto con los métodos de balanceo de carga hash y random.

Los parámetros down y drain son mutuamente excluyentes.

Added in version 1.3.0.

resolve

Habilita la monitorización de cambios en la lista de direcciones IP que corresponde a un nombre de dominio, actualizándola sin necesidad de recargar la configuración. El grupo debe residir en una zona de memoria compartida; además, debe definirse un resolver.

service=nombre

Habilita la resolución de registros DNS SRV y establece el nombre del servicio. Para que este parámetro funcione, también debe especificarse el parámetro resolve, sin especificar el puerto del servidor en el nombre de host.

Si no hay puntos en el nombre del servicio, el nombre se forma de acuerdo con el estándar RFC: el nombre del servicio se antepone con _, luego se añade _tcp tras un punto. Así, el nombre de servicio http resultará en _http._tcp.

Angie resuelve los registros SRV combinando el nombre de servicio normalizado y el nombre de host, y obteniendo la lista de servidores para la combinación vía DNS, junto con sus prioridades y pesos.

Los registros SRV de máxima prioridad (los que comparten el valor de prioridad mínima) se resuelven en servidores principales, y los demás registros se convierten en servidores de respaldo. Si se configura backup con server, los registros SRV de máxima prioridad se resuelven como servidores de respaldo, y los demás registros se ignoran.
El peso es similar al parámetro weight de la directiva server. Si el peso está configurado tanto en la directiva como en el registro SRV, se usa el peso definido en la directiva.

Este ejemplo buscará el registro _http._tcp.backend.example.com:

server backend.example.com service=http resolve;

Added in version 1.2.0: Angie

Added in version 1.1.0-P1: Angie PRO

sid=id

Establece el ID del servidor en el grupo. Si el parámetro no se especifica, el ID se establece como un hash MD5 hexadecimal de la dirección IP y el puerto o de la ruta del socket de dominio UNIX.

Added in version 1.4.0.

slow_start=tiempo

Establece el tiempo que tarda un servidor en recuperar su peso al volver a estar en servicio con los métodos de balanceo de carga round-robin o least_conn.

Si el parámetro está configurado y un servidor vuelve a considerarse saludable tras un fallo según max_fails y upstream_probe (PRO), el servidor recupera gradualmente su peso designado durante el período de tiempo especificado.

Si el parámetro no está configurado, en una situación similar el servidor comienza a trabajar inmediatamente con su peso designado.

Nota

Si solo se especifica un server en el upstream, slow_start no tiene efecto y será ignorado.

state (PRO)#

Added in version 1.4.0: PRO

Sintaxis	`state` archivo;
Predeterminado	—
Contexto	upstream

Especifica el archivo donde se almacena de forma persistente la lista de servidores del upstream. Al instalar desde nuestros paquetes, se crea un directorio dedicado /var/lib/angie/state/ (/var/db/angie/state/ en FreeBSD) con los permisos adecuados para almacenar dichos archivos, por lo que solo es necesario añadir el nombre de archivo en la configuración:

upstream backend {

    zone backend 1m;
    state /var/lib/angie/state/<NOMBRE DE ARCHIVO>;
}

El formato de la lista de servidores aquí es similar a s_server. El contenido del archivo cambia siempre que los servidores se modifiquen en la sección /config/stream/upstreams/ mediante la API de configuración. El archivo se lee al iniciar Angie o al recargar la configuración.

Advertencia

Para usar la directiva state en un bloque upstream, no debe haber directivas server en él, pero se requiere una zona de memoria compartida (zone).

zone#

Sintaxis	`zone` nombre [tamaño];
Predeterminado	—
Contexto	upstream

Define el nombre y tamaño de la zona de memoria compartida que almacena la configuración y el estado en tiempo de ejecución del grupo, compartido entre los procesos worker. Varios grupos pueden usar la misma zona. En este caso, basta con especificar el tamaño una sola vez.

backup_switch (PRO)#

Added in version 1.10.0: PRO

Sintaxis	`backup_switch` `permanent`[=tiempo];
Predeterminado	—
Contexto	upstream

La directiva habilita la capacidad de iniciar la selección de servidores no desde el grupo principal, sino desde el grupo activo, es decir, aquel en el que previamente se encontró un servidor con éxito. Si no se puede encontrar un servidor en el grupo activo para la siguiente petición, y la búsqueda se traslada al grupo de respaldo, este grupo de respaldo se convierte en activo, y las siguientes peticiones se dirigen primero a los servidores de este grupo.

Si se define el parámetro permanent sin un valor de tiempo, el grupo permanece activo tras la selección y no se produce la re-comprobación automática de grupos con niveles de prioridad más bajos. Si se especifica tiempo, el estado activo del grupo expira tras el intervalo definido, y el balanceador de carga vuelve a comprobar los grupos con niveles de prioridad más bajos, retornando a ellos si los servidores funcionan normalmente.

Ejemplo:

upstream media_backend {
    server primary1.example.com:1935;
    server primary2.example.com:1935;

    server reserve1.example.com:1935 backup;
    server reserve2.example.com:1935 backup;

    backup_switch permanent=2m;
}

Si el balanceador de carga cambia de los servidores principales al grupo de respaldo, todas las peticiones posteriores son gestionadas por este grupo de respaldo durante 2 minutos. Tras expirar los 2 minutos, el balanceador vuelve a comprobar los servidores principales y los hace activos de nuevo si funcionan con normalidad.

feedback (PRO)#

Added in version 1.7.0: PRO

Sintaxis	`feedback` variable [`inverse`] [`factor=`número] [`account=`variable_condición];
Predeterminado	—
Contexto	upstream

Habilita un mecanismo de balanceo de carga basado en retroalimentación para el upstream. Ajusta dinámicamente las decisiones de balanceo multiplicando el peso de cada servidor proxy por el valor promedio de retroalimentación, que cambia con el tiempo según el valor de variable y está sujeto a una condición opcional.

Se pueden especificar los siguientes parámetros:

`variable`	La variable de la que se toma el valor de retroalimentación. Debe representar una métrica de rendimiento o salud; se asume que la proporciona el servidor. El valor se evalúa con cada respuesta del servidor y se incorpora al promedio móvil según la configuración de `inverse` y `factor`.
`inverse`	Si se establece, el valor de retroalimentación se interpreta de forma inversa: valores más bajos indican mejor rendimiento.
`factor`	El factor por el cual se pondera el valor de retroalimentación al calcular el promedio. Valores válidos son enteros de 0 a 99. El valor por defecto es `90`. El promedio se calcula usando la fórmula de suavizado exponencial. Cuanto mayor sea el factor, menos afectarán los valores nuevos al promedio; si se especifica `90`, se tomará el 90% del valor anterior y solo el 10% del valor nuevo.
`account`	Especifica una variable de condición que controla cómo se contabilizan las conexiones en el cálculo. El valor promedio se actualiza con el valor de retroalimentación solo si la variable de condición no es igual a `""` ni a `"0"`. Nota Por defecto, el tráfico de las sondas no se incluye en el cálculo; combinar la variable $upstream_probe con `account` permite incluirlas o incluso excluir todo lo demás.

Ejemplo:

upstream backend {

    zone backend 1m;

    feedback $feedback_value factor=80 account=$condition_value;

    server backend1.example.com:1935  weight=1;
    server backend2.example.com:1935  weight=2;
}

map $protocol $feedback_value {
    "TCP"                      100;
    "UDP"                      75;
    default                    10;
}

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

Esta configuración clasifica los servidores por niveles de retroalimentación basados en los protocolos usados en sesiones individuales, y además añade una condición sobre $upstream_probe para contabilizar solo las sondas de high_priority o las sesiones de clientes normales.

hash#

Sintaxis	`hash` clave [`consistent`];
Predeterminado	—
Contexto	upstream

Especifica un método de balanceo de carga para el grupo donde la asignación cliente-servidor se determina usando un valor hash de la clave. La clave puede contener texto, variables y sus combinaciones. Ejemplo de uso:

hash $remote_addr;

El método es compatible con la librería Perl Cache::Memcached.

Si se especifica el parámetro consistent, se usará el método de consistent hashing de ketama en lugar del método anterior. Este método garantiza que, al añadir o eliminar un servidor del grupo, solo un número mínimo de claves se reasignará a otros servidores. Usar el método para servidores de caché proporciona una mayor tasa de aciertos de caché. El método es compatible con la librería Perl Cache::Memcached::Fast con el parámetro ketama_points configurado en 160.

least_conn#

Sintaxis	`least_conn`;
Predeterminado	—
Contexto	upstream

Especifica un método de balanceo de carga para el grupo donde una conexión se asigna al servidor con el menor número de conexiones activas, teniendo en cuenta los pesos de los servidores. Si varios servidores son adecuados, se seleccionan de manera cíclica (round-robin) con sus pesos considerados.

least_time (PRO)#

Sintaxis	`least_time` `connect` \| `first_byte` \| `last_byte` [`factor=`número] [`account=`variable_condición];
Predeterminado	—
Contexto	upstream

Especifica un método de balanceo de carga para el grupo donde la probabilidad de asignar una conexión a un servidor activo es inversamente proporcional a su tiempo de respuesta promedio; cuanto menor sea el tiempo, más conexiones recibirá el servidor.

`connect`	La directiva considera el tiempo promedio para establecer una conexión.
`first_byte`	La directiva usa el tiempo promedio para recibir el primer byte de la respuesta.
`last_byte`	La directiva usa el tiempo promedio para recibir la respuesta completa.

Added in version 1.7.0: PRO

`factor`	Cumple la misma función que response_time_factor (PRO) y lo sobrescribe si el parámetro está definido.
`account`	Especifica una variable de condición que controla qué conexiones se contabilizan en el cálculo. El valor promedio se actualiza solo si la variable de condición de la conexión no es igual a `""` ni a `"0"`. Nota Por defecto, las sondas no se incluyen en el cálculo; combinar la variable $upstream_probe con `account` permite incluirlas o incluso excluir todo lo demás.

Los valores actuales se presentan como connect_time, first_byte_time y last_byte_time en el objeto health del servidor, entre las métricas upstream en la API.

random#

Sintaxis	`random` [`two`];
Predeterminado	—
Contexto	upstream

Especifica un método de balanceo de carga para el grupo donde una conexión se asigna a un servidor seleccionado aleatoriamente, teniendo en cuenta los pesos de los servidores.

Si se especifica el parámetro opcional two, Angie selecciona aleatoriamente dos servidores y luego elige un servidor usando el método especificado. El método predeterminado es least_conn, que asigna una conexión al servidor con el menor número de conexiones activas.

response_time_factor (PRO)#

Sintaxis	`response_time_factor` número;
Predeterminado	`response_time_factor 90;`
Contexto	upstream

Define el factor de suavizado para el método de balanceo de carga least_time (PRO), usando el valor previo al calcular el tiempo de respuesta promedio según la fórmula de media móvil exponencial ponderada.

Cuanto mayor sea el número especificado, menos influyen los valores nuevos en el promedio; si se especifica 90, se tomará el 90% del valor anterior y solo el 10% del valor nuevo. Los valores válidos van del 0 al 99 inclusive.

Los resultados actuales del cálculo se presentan como connect_time (tiempo de establecimiento de conexión), first_byte_time (tiempo de recepción del primer byte de la respuesta) y last_byte_time (tiempo de recepción de la respuesta completa) en el objeto health del servidor, dentro de las métricas upstream en la API.

Nota

Solo se consideran las respuestas correctas en el cálculo; qué constituye una respuesta fallida se determina mediante las directivas proxy_next_upstream.

sticky#

Added in version 1.6.0: Angie

Added in version 1.6.0: Angie PRO

Sintaxis

sticky route $variable...;

sticky learn zone=zona create=$var_create1... lookup=$var_lookup1... [connect] [norefresh] [timeout=tiempo];

sticky learn lookup=$var_lookup1... remote_action=uri remote_result=$var_remoto [remote_uri=uri];

Predeterminado

—

Contexto

upstream

Configura sesiones sticky entre clientes y servidores upstream, dependiendo del modo especificado en el primer parámetro. Para retirar gradualmente servidores con sticky de la rotación, puede usarse la opción drain (PRO) en el bloque server.

Advertencia

La directiva sticky debe aparecer después de todas las directivas de método de balanceo de carga, de lo contrario no funcionará.

Este modo usa identificadores de ruta predefinidos que pueden derivarse de metadatos de la conexión. Es menos flexible porque depende de identificadores conocidos, pero resulta útil cuando dichos valores ya están disponibles.

Cuando se establece una conexión, el servidor backend puede asignar un ID de ruta y devolverlo mediante un método que ambas partes comprendan. Este ID debe coincidir con el parámetro sid de la directiva server. Si se configura sticky_secret, el ID se calcula con hash.

Las conexiones futuras que incluyan este ID serán dirigidas al mismo servidor, siempre que Angie pueda recuperar el ID desde una variable especificada.

La directiva toma una lista de variables de las cuales extraer el ID de ruta. El primer valor no vacío se compara con el sid de cada servidor. Si hay coincidencia, la conexión se enruta en consecuencia. De lo contrario, se usa el método de balanceo por defecto.

Ejemplo usando $route, mapeado desde $ssl_preread_server_name:

stream {

    map $ssl_preread_server_name $route {
        a.example.com            a;
        b.example.com            b;
        default                  "";
    }

    upstream backend {
        server 127.0.0.1:8081 sid=a;
        server 127.0.0.1:8082 sid=b;

        sticky route $route;
    }

    server {
        listen 127.0.0.1:8080;
        ssl_preread on;
        proxy_pass backend;
    }
}

Este modo asigna clientes a servidores backend de forma dinámica usando IDs de sesión derivados de los metadatos de conexión. Las sesiones se almacenan en memoria compartida y pueden reutilizarse en conexiones futuras.

Use create para definir cómo se generan los nuevos IDs de sesión, y lookup para definir cómo se recuperan. Se pueden especificar múltiples variables para cada caso.

El primer valor no vacío de create define el ID de sesión, por ejemplo, el nombre del servidor backend.

Las sesiones se almacenan en la zona de memoria compartida especificada por zone. Si una sesión no se utiliza durante timeout (predeterminado: 1 hora), se elimina.

Por defecto, la expiración de la sesión se renueva en cada uso. Use norefresh para desactivar este comportamiento.

Las conexiones entrantes que incluyan un ID de sesión coincidente (vía lookup) se enrutan al servidor correspondiente. Si no hay coincidencia o el servidor está inactivo, se usa el balanceo normal.

Use connect para crear la sesión tan pronto como se establezca la conexión con el upstream. Sin esto, la creación se difiere hasta después de completar el procesamiento. (Para UDP, las sesiones se crean inmediatamente tras la selección del servidor).

Ejemplo usando $rdp_cookie tanto para lookup como para create:

stream {

    upstream backend {
        server 127.0.0.1:3390 sid=a;
        server 127.0.0.1:3391 sid=b;

        sticky learn lookup=$rdp_cookie create=$rdp_cookie zone=sessions:1m;
    }

    server {
        listen 127.0.0.1:3389;
        ssl_preread on;
        proxy_pass backend;
    }
}

Este modo permite que las sesiones se creen y recuperen dinámicamente desde un almacén de sesiones externo usando remote_action y remote_result.

A diferencia del modo learn con zone, este no almacena en caché las sesiones localmente y realiza una petición al almacén remoto en cada conexión.

remote_action debe referirse a un location dentro del bloque client. remote_uri define el URI de la petición (predeterminado: /) y puede incluir variables.

Flujo general:

Extraer el ID de sesión de la primera variable lookup no vacía. Si no existe, se usa el balanceo normal.
Enviar una subpetición HTTP sincrónica al almacén remoto (definido por remote_action) incluyendo:
- El ID de sesión ($sticky_sessid)
- El ID del servidor elegido — desde el parámetro sid= o un nombre de servidor con hash ($sticky_sid)
Estas variables se exponen al contexto HTTP como $stream_sticky_sessid y $stream_sticky_sid.
El almacén remoto responde:
- 200/201/204: confirma el servidor seleccionado
- Puede devolver un ID alternativo mediante cabecera (gestionado por remote_result)
- Otro estado o ID ausente: se vuelve al servidor original

Ejemplo de configuración:

http {

    client {

        location @sticky_client1 {
            proxy_set_header X-Sticky-Sessid $stream_sticky_sessid;
            proxy_set_header X-Sticky-Sid $stream_sticky_sid;
            proxy_set_header X-Sticky-Last $msec;
            proxy_pass http://127.0.0.1:8080;

            proxy_cache remote;
            proxy_cache_valid 200 1d;
            proxy_cache_key $scheme$proxy_host$request_uri$stream_sticky_sessid;
        }
    }
}

stream {

    upstream u {
        server 127.0.0.1:8081 sid=backend-01;
        server 127.0.0.1:8082 sid=backend-02;

        sticky learn lookup=$remote_addr
                       remote_action=@sticky_client1
                       remote_result=$upstream_http_x_sticky_sid
                       remote_uri=/foo;
    }

    server {
        listen 127.0.0.1:8080;
        proxy_pass u;
    }
}

Ejemplo de respuesta del almacén remoto:

HTTP/1.1 200 OK
...
X-Sticky-Sid: backend-01
X-Session-Info: active

Angie expone:

$upstream_http_x_sticky_sid = backend-01
$upstream_http_x_session_info = active

Como $upstream_http_x_sticky_sid está definido en remote_result, se usa para seleccionar el sid correspondiente.

La directiva sticky considera el estado de los servidores upstream:

Servidores marcados como down o temporalmente inactivos son ignorados.
Servidores que superan max_conns se omiten temporalmente.
Servidores con drain (PRO) pueden seguir siendo seleccionados si su sid coincide.
Si un servidor previamente inactivo se recupera, sticky volverá a usarlo.

El comportamiento de sticky puede ajustarse con sticky_secret y sticky_strict. Si no se encuentra un servidor coincidente o está inactivo:

Con sticky_strict deshabilitado: se recurre al balanceo por defecto.
Con sticky_strict on;: la petición se rechaza.

Cada zone usada en sticky debe ser exclusiva para un único upstream. Las zonas no pueden compartirse entre varios bloques upstream.

sticky_secret#

Added in version 1.6.0: Angie

Added in version 1.6.0: Angie PRO

Sintaxis	`sticky_secret` cadena;
Predeterminado	—
Contexto	upstream

Añade la cadena como sal a la función de hash MD5 para la directiva sticky en modo route. La cadena puede contener variables, por ejemplo, $remote_addr:

upstream backend {
    server 127.0.0.1:8081 sid=a;
    server 127.0.0.1:8082 sid=b;

    sticky route $route;
    sticky_secret my_secret.$remote_addr;
}

La sal se añade tras el valor a hashear; para verificar independientemente el mecanismo de hash:

$ echo -n "<VALOR><SAL>" | md5sum

sticky_strict#

Added in version 1.6.0: Angie

Added in version 1.6.0: Angie PRO

Sintaxis	`sticky_strict` `on` \| `off`;
Predeterminado	`sticky_strict off;`
Contexto	upstream

Cuando está habilitado, Angie devuelve un error de conexión al cliente si el servidor de destino no está disponible, en lugar de recurrir a otro servidor disponible, que es el comportamiento predeterminado cuando no se encuentra un servidor coincidente.

Variables integradas#

El módulo stream_upstream admite las siguientes variables integradas:

`$sticky_sessid`#

Se usa con remote_action en sticky; almacena el identificador de sesión inicial tomado de lookup.

`$sticky_sid`#

Se usa con remote_action en sticky; almacena el identificador del servidor previamente asociado con la sesión.

sticky_sid contiene el valor del parámetro sid= de la directiva server en el bloque upstream, si se especificó, o el hash MD5 del nombre del servidor.

`$upstream_addr`#

Almacena la dirección IP y el puerto, o la ruta al socket UNIX del servidor upstream. Si se contactaron varios servidores durante el proxying, sus direcciones se separan por comas, por ejemplo:

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

Si no se puede seleccionar un servidor, la variable conserva el nombre del grupo de servidores.

`$upstream_bytes_received`#

Número de bytes recibidos desde un servidor upstream. Los valores de varias conexiones se separan por comas y dos puntos, de manera similar a las direcciones en la variable $upstream_addr.

`$upstream_bytes_sent`#

Número de bytes enviados a un servidor upstream. Los valores de varias conexiones se separan por comas y dos puntos, de manera similar a las direcciones en la variable $upstream_addr.

`$upstream_connect_time`#

Tiempo para conectarse al servidor upstream; el tiempo se mide en segundos con resolución de milisegundos. Los tiempos de varias conexiones se separan por comas y dos puntos, de manera similar a las direcciones en la variable $upstream_addr.

`$upstream_first_byte_time`#

Tiempo para recibir el primer byte de datos; el tiempo se mide en segundos con resolución de milisegundos. Los tiempos de varias conexiones se separan por comas, de manera similar a las direcciones en la variable $upstream_addr.

`$upstream_session_time`#

Duración de la sesión en segundos con resolución de milisegundos. Los tiempos de varias conexiones se separan por comas, de manera similar a las direcciones en la variable $upstream_addr.

`$upstream_sticky_status`#

Estado de las conexiones sticky.

`""`	Conexión dirigida al upstream sin sticky habilitado.
`NEW`	Conexión sin información sticky.
`HIT`	Conexión con información sticky dirigida al backend deseado.
`MISS`	Conexión con información sticky dirigida al backend seleccionado por el algoritmo de balanceo de carga.

Los valores de múltiples conexiones se separan por comas y dos puntos, de manera similar a las direcciones en la variable $upstream_addr.

Upstream#

Ejemplo de configuración#

Directivas#

upstream#

server#

state (PRO)#

zone#

backup_switch (PRO)#

feedback (PRO)#

hash#

least_conn#

least_time (PRO)#

random#

response_time_factor (PRO)#

sticky#

sticky_secret#

sticky_strict#

Variables integradas#

$sticky_sessid#

$sticky_sid#

$upstream_addr#

$upstream_bytes_received#

$upstream_bytes_sent#

$upstream_connect_time#

$upstream_first_byte_time#

$upstream_session_time#

$upstream_sticky_status#

`$sticky_sessid`#

`$sticky_sid`#

`$upstream_addr`#

`$upstream_bytes_received`#

`$upstream_bytes_sent`#

`$upstream_connect_time`#

`$upstream_first_byte_time`#

`$upstream_session_time`#

`$upstream_sticky_status`#