Módulo HTTP#

El módulo HTTP principal implementa la funcionalidad básica de un servidor HTTP: esto incluye la definición de bloques de servidor, la configuración de ubicaciones para el enrutamiento de peticiones, la entrega de archivos estáticos y el control de acceso, la configuración de redirecciones, el soporte de conexiones keep-alive y la gestión de cabeceras de petición y respuesta.

Los demás módulos de esta sección amplían esta funcionalidad, permitiendo configurar y optimizar de forma flexible el servidor HTTP para distintos escenarios y requisitos.

Directivas#

absolute_redirect#

Sintaxis

absolute_redirect on | off;

Predeterminado

absolute_redirect on;

Contexto

http, server, location

Si está deshabilitada, las redirecciones emitidas por Angie serán relativas.

Véase también las directivas server_name_in_redirect y port_in_redirect.

aio#

Sintaxis

aio on | off | threads [=pool];

Predeterminado

aio off;

Contexto

http, server, location

Activa o desactiva el uso de operaciones de E/S de archivos asíncronas (AIO) en FreeBSD y Linux:

location /video/ {
  aio            on;
  output_buffers 1 64k;
}

En FreeBSD, AIO puede usarse a partir de FreeBSD 4.3. Antes de FreeBSD 11.0, AIO podía enlazarse estáticamente en el núcleo:

options VFS_AIO

o cargarse dinámicamente como un módulo del núcleo:

kldload aio

En Linux, AIO puede usarse desde la versión 2.6.22 del núcleo. Además, es necesario habilitar directio, de lo contrario la lectura será bloqueante:

location /video/ {
  aio            on;
  directio       512;
  output_buffers 1 128k;
}

En Linux, directio solo puede usarse para leer bloques alineados en fronteras de 512 bytes (o 4K en XFS). El final de un archivo no alineado se lee en modo bloqueante. Lo mismo se aplica a las peticiones de rango de bytes y a las peticiones FLV que no empiezan desde el inicio del archivo: la lectura de datos no alineados al principio y al final de un archivo será bloqueante.

Cuando AIO y sendfile están habilitados simultáneamente en Linux, AIO se usa para los archivos cuyo tamaño es mayor o igual al especificado en la directiva directio, mientras que sendfile se usa para archivos más pequeños o cuando directio está deshabilitado:

location /video/ {
  sendfile       on;
  aio            on;
  directio       8m;
}

Finalmente, los archivos pueden leerse y enviarse usando multihilo, sin bloquear un proceso worker:

location /video/ {
  sendfile       on;
  aio            threads;
}

Las operaciones de lectura y envío de archivos se delegan a los hilos del pool especificado. Si se omite el nombre del pool, se usa el pool llamado "default". El nombre del pool también puede definirse mediante variables:

aio threads=pool$disk;

Por defecto, el multihilo está deshabilitado; debe activarse con el parámetro de configuración --with-threads. Actualmente, el multihilo solo es compatible con los métodos epoll, kqueue y eventport. El envío multihilo de archivos solo está soportado en Linux.

Véase también la directiva sendfile.

aio_write#

Sintaxis

aio_write on | off;

Predeterminado

aio_write off;

Contexto

http, server, location

Si aio está habilitado, especifica si se utiliza para la escritura de archivos. Actualmente, esto solo funciona cuando se usa aio threads y está limitado a la escritura de archivos temporales con datos recibidos de servidores proxificados.

alias#

Sintaxis

alias path;

Predeterminado

Contexto

location

Define un reemplazo para la ubicación especificada. Por ejemplo, con la siguiente configuración:

location /i/ {
  alias /data/w3/images/;
}

al solicitar /i/top.gif, se enviará el archivo /data/w3/images/top.gif.

El valor path puede contener variables, excepto $document_root y $realpath_root.

Si alias se usa dentro de una ubicación definida con una expresión regular, dicha expresión debe contener capturas y alias debe referirse a esas capturas, por ejemplo:

location ~ ^/users/(.+\.(?:gif|jpe?g|png))$ {
  alias /data/w3/images/$1;
}

Cuando la ubicación coincide con la última parte del valor de la directiva:

location /images/ {
  alias /data/w3/images/;
}

es mejor usar la directiva root en su lugar:

location /images/ {
  root /data/w3;
}

auth_delay#

Sintaxis

auth_delay time;

Predeterminado

auth_delay 0s;

Contexto

http, server, location

Retrasa el procesamiento de las solicitudes no autorizadas con el código de respuesta 401 para prevenir ataques de temporización cuando el acceso está limitado por contraseña o por el resultado de una subrequest.

auto_redirect#

Sintaxis

auto_redirect [on | off | default];

Predeterminado

auto_redirect default;

Contexto

http, server, location

Controla el comportamiento de la redirección cuando una ubicación con prefijo termina en una barra inclinada:

location /prefix/ {
    auto_redirect on;
}

Aquí, una petición a /prefix provoca una redirección a /prefix/.

El valor on habilita explícitamente la redirección, mientras que off la desactiva. Cuando se establece en default, la redirección solo se habilita si la ubicación procesa solicitudes con api, proxy_pass, fastcgi_pass, uwsgi_pass, scgi_pass, memcached_pass o grpc_pass.

chunked_transfer_encoding#

Sintaxis

chunked_transfer_encoding on | off;

Predeterminado

chunked_transfer_encoding on;

Contexto

http, server, location

Permite desactivar la codificación de transferencia fragmentada (chunked) en HTTP/1.1. Puede resultar útil cuando se utiliza software que no admite esta codificación a pesar de ser un requisito del estándar.

client#

Sintaxis

client { ... }

Predeterminado

Contexto

http

Crea un contexto especial client para procesar peticiones HTTP internas que Angie realiza por sí mismo sin la intervención de un cliente externo.

El contexto client aísla el tráfico de servicio de varios módulos de Angie del tráfico de usuario, permitiendo un control adicional sobre este. Dentro de este contexto, solo pueden definirse location`s con nombre (con el prefijo :samp:`@); no son accesibles desde peticiones HTTP externas y solo pueden invocarse de forma programática mediante mecanismos internos del servidor.

El contexto client se utiliza para:

  • enviar peticiones a la autoridad certificadora en el módulo ACME a través de la location @acme predefinida, que puede configurarse adicionalmente con directivas del módulo Proxy;

  • peticiones a la API de Docker en el módulo Docker a través de las location @docker_events y @docker_containers predefinidas, que pueden configurarse adicionalmente con directivas del módulo Proxy;

  • comprobaciones de estado de servidores proxificados mediante upstream_probe (PRO);

  • el modo sticky learn con remote_action en el módulo de stream Upstream.

El soporte para múltiples bloques client permite agrupar ajustes comunes para varios bloques location dentro de cada bloque, lo que ayuda a evitar duplicación de configuración.

Las directivas especificadas en cada bloque client solo se heredan en los bloques location declarados explícitamente dentro de él. En particular, por eso no afectan la configuración de otros módulos que usan de forma implícita el bloque client para peticiones salientes (por ejemplo, ACME o Docker).

Ejemplo de uso de múltiples bloques client con herencia de ajustes:

client {

    proxy_set_header Host docker.example.com;
    proxy_set_header Authorization "Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==";

    location @docker_events {

    }

    location @docker_containers {

    }
}

client {

    upstream_probe_timeout 3s;
    proxy_method GET;
    proxy_set_header Host backend.example.com;
    proxy_set_header X-Real-IP $remote_addr;

    location @health_check {

        proxy_pass http://upstream-server/health;
    }
}

Nota

Aquí se permiten las mismas directivas que en location`s normales, pero solo funcionan los manejadores de contenido (como :ref:`js_content o autoindex) y los manejadores de variables (como map), así como las directivas que generan peticiones por sí mismas, como upstream_probe.

Las directivas que operan en otras etapas de procesamiento de la petición (como limit_req, auth_request, try_files, filtros de imagen, XSLT, etc.) no funcionan aquí.

client_body_buffer_size#

Sintaxis

client_body_buffer_size size;

Predeterminado

client_body_buffer_size 8k|16k;

Contexto

http, server, location

Define el tamaño del búfer para leer el cuerpo de la petición del cliente. Si el cuerpo de la petición es mayor que el búfer, el cuerpo completo o solo una parte se escribe en un archivo temporal. Por defecto, el tamaño del búfer equivale a dos páginas de memoria. En x86, otras plataformas de 32 bits y x86-64, esto es 8K. En otras plataformas de 64 bits, normalmente es 16K.

client_body_in_file_only#

Sintaxis

client_body_in_file_only on | clean | off;

Predeterminado

client_body_in_file_only off;

Contexto

http, server, location

Determina si se guarda el cuerpo completo de la petición del cliente en un archivo. Esta directiva puede usarse durante la depuración, o cuando se utiliza la variable $request_body_file o el método $r->request_body_file del módulo Perl.

on

los archivos temporales no se eliminan después de procesar la petición

clean

permite eliminar los archivos temporales tras procesar la petición

client_body_in_single_buffer#

Sintaxis

client_body_in_single_buffer on | off;

Predeterminado

client_body_in_single_buffer off;

Contexto

http, server, location

Determina si se guarda el cuerpo completo de la petición del cliente en un solo búfer. La directiva se recomienda cuando se usa la variable $request_body para reducir el número de operaciones de copia implicadas.

client_body_temp_path#

Sintaxis

client_body_temp_path path [level1 [level2 [level3]]];

Predeterminado

client_body_temp_path client_body_temp; (la ruta depende de la opción de compilación --http-client-body-temp-path)

Contexto

http, server, location

Define un directorio para almacenar archivos temporales con cuerpos de peticiones de clientes. Se puede usar hasta una jerarquía de subdirectorios de tres niveles bajo el directorio especificado. Por ejemplo, en la siguiente configuración:

client_body_temp_path /spool/angie/client_temp 1 2;

la ruta de un archivo temporal podría ser:

/spool/angie/client_temp/7/45/00000123457

client_body_timeout#

Sintaxis

client_body_timeout time;

Predeterminado

client_body_timeout 60s;

Contexto

http, server, location

Define un tiempo de espera para leer el cuerpo de la petición del cliente. El tiempo de espera se establece solo entre dos operaciones de lectura sucesivas, no para la transmisión completa del cuerpo de la petición. Si un cliente no transmite nada dentro de este tiempo, la petición finaliza con el error 408 (Request Time-out).

client_header_buffer_size#

Sintaxis

client_header_buffer_size size;

Predeterminado

client_header_buffer_size 1k;

Contexto

http, server

Define el tamaño del búfer para leer la cabecera de la petición del cliente. Para la mayoría de las peticiones, un búfer de 1K es suficiente. Sin embargo, si la petición incluye cookies largas o proviene de un cliente WAP, podría no caber en 1K. Si la línea de petición o un campo de cabecera no caben en este búfer, se asignan búferes más grandes, configurados mediante la directiva large_client_header_buffers.

Si la directiva se especifica en el nivel server, puede usarse el valor del servidor por defecto. Véase la sección Selección de servidor virtual para más detalles.

client_header_timeout#

Sintaxis

client_header_timeout time;

Predeterminado

client_header_timeout 60s;

Contexto

http, server

Define un tiempo de espera para leer la cabecera de la petición del cliente. Si un cliente no transmite la cabecera completa dentro de este tiempo, la petición finaliza con el error 408 (Request Time-out).

client_max_body_size#

Sintaxis

client_max_body_size size;

Predeterminado

client_max_body_size 1m;

Contexto

http, server, location

Define el tamaño máximo permitido para el cuerpo de la petición del cliente. Si el tamaño en una petición excede el valor configurado, se devuelve al cliente el error 413 (Request Entity Too Large). Ten en cuenta que los navegadores no pueden mostrar correctamente este error.

0

desactiva la comprobación del tamaño del cuerpo de la petición del cliente

connection_pool_size#

Sintaxis

connection_pool_size size;

Predeterminado

connection_pool_size 256 | 512;

Contexto

http, server, location

Permite un ajuste fino de las asignaciones de memoria por conexión. Esta directiva tiene un impacto mínimo en el rendimiento y, en general, no debería usarse. Por defecto:

256 (bytes)

en plataformas de 32 bits

512 (bytes)

en plataformas de 64 bits

default_type#

Sintaxis

default_type mime-type;

Predeterminado

default_type text/plain;

Contexto

http, server, location

Define el tipo MIME por defecto de una respuesta. La asignación de extensiones de nombres de archivo a tipos MIME puede configurarse con la directiva types.

directio#

Sintaxis

directio size | off;

Predeterminado

directio off;

Contexto

http, server, location

Activa el uso de la bandera O_DIRECT (FreeBSD, Linux), la bandera F_NOCACHE (macOS) o la función directio() (Solaris), al leer archivos cuyo tamaño sea mayor o igual al valor especificado. La directiva desactiva automáticamente el uso de sendfile para una petición determinada. Se recomienda para servir archivos grandes:

directio 4m;

o al usar aio en Linux.

directio_alignment#

Sintaxis

directio_alignment size;

Predeterminado

directio_alignment 512;

Contexto

http, server, location

Define la alineación para directio. En la mayoría de los casos, una alineación de 512 bytes es suficiente. Sin embargo, al usar XFS en Linux, debe aumentarse a 4K.

error_page#

Sintaxis

error_page code ... [=[response]] uri;

Predeterminado

Contexto

http, server, location, if in location

Define el URI que se mostrará para los errores especificados. El valor uri puede usar variables.

Ejemplo:

error_page 404             /404.html;
error_page 500 502 503 504 /50x.html;

Esto provoca una redirección interna al uri especificado, cambiando el método de la petición del cliente a "GET" (para todos los métodos distintos de "GET" y "HEAD").

Además, es posible cambiar el código de respuesta a otro usando la sintaxis =response, por ejemplo:

error_page 404 =200 /empty.gif;

Si una respuesta de error es procesada por un servidor proxificado o un servidor FastCGI/uwsgi/SCGI/gRPC, y el servidor puede devolver distintos códigos de respuesta (p. ej., 200, 302, 401 o 404), es posible pasar el código que devuelva:

error_page 404 = /404.php;

Si no es necesario cambiar el URI y el método durante la redirección interna, es posible delegar el procesamiento del error a un location con nombre:

location / {
  error_page 404 = @fallback;
}

location @fallback {
  proxy_pass http://backend;
}

Nota

Si ocurre un error durante el procesamiento del URI, se devuelve al cliente la respuesta con el código del último error ocurrido.

También es posible usar redirecciones URL para el manejo de errores:

error_page 403      http://example.com/forbidden.html;
error_page 404 =301 http://example.com/notfound.html;

En este caso, por defecto, se devuelve al cliente el código de respuesta 302. Solo puede cambiarse a uno de los códigos de redirección (301, 302, 303, 307 y 308).

etag#

Sintaxis

etag on | off;

Predeterminado

etag on;

Contexto

http, server, location

Activa o desactiva la generación automática de la cabecera de respuesta ETag para recursos estáticos.

http#

Sintaxis

http { ... }

Predeterminado

Contexto

main

Proporciona el contexto de archivo de configuración en el que se especifican las directivas del servidor HTTP.

if_modified_since#

Sintaxis

if_modified_since off | exact | before;

Predeterminado

if_modified_since exact;

Contexto

http, server, location

Especifica cómo comparar la fecha de modificación de una respuesta con la fecha del campo de cabecera If-Modified-Since en la petición:

off

la respuesta siempre se considera modificada

exact

coincidencia exacta

before

la fecha de modificación de la respuesta es menor o igual que la fecha en el campo de cabecera If-Modified-Since de la petición

ignore_invalid_headers#

Sintaxis

ignore_invalid_headers on | off;

Predeterminado

ignore_invalid_headers on;

Contexto

http, server

Controla si Angie ignora los campos de cabecera con nombres no válidos. Los nombres válidos están compuestos por letras en inglés, dígitos, guiones y, posiblemente, guiones bajos (según lo controle la directiva underscores_in_headers).

Si la directiva se especifica en el nivel server, puede usarse el valor del servidor por defecto.

internal#

Sintaxis

internal;

Predeterminado

Contexto

location

Especifica que un location determinado solo puede usarse para peticiones internas. Para peticiones externas, se devuelve al cliente el error 404 (Not Found).

Las peticiones internas son las siguientes:

  • peticiones redirigidas por las directivas error_page, index, random_index y try_files;

  • peticiones redirigidas por la cabecera de respuesta X-Accel-Redirect desde un servidor upstream;

  • subpeticiones generadas por el comando include virtual del módulo SSI, por las directivas del módulo Addition y por las directivas auth_request y mirror;

  • peticiones modificadas por la directiva rewrite.

Ejemplo:

error_page 404 /404.html;

location = /404.html {
  internal;
}

Nota

Existe un límite de 10 redirecciones internas por petición para evitar ciclos de procesamiento que pueden ocurrir en configuraciones incorrectas. Si se alcanza este límite, se devuelve el error 500 (Internal Server Error). En tales casos, puede verse el mensaje rewrite or internal redirection cycle en el registro de errores.

keepalive_disable#

Sintaxis

keepalive_disable none | browser ...;

Predeterminado

keepalive_disable msie6;

Contexto

http, server, location

Desactiva las conexiones keep-alive con navegadores problemáticos. Los parámetros browser especifican qué navegadores se verán afectados.

none

habilita las conexiones keep-alive con todos los navegadores

msie6

desactiva las conexiones keep-alive con versiones antiguas de MSIE, una vez recibida una petición POST

safari

desactiva las conexiones keep-alive con Safari y navegadores similares a Safari en macOS y sistemas operativos similares a macOS

keepalive_requests#

Sintaxis

keepalive_requests number;

Predeterminado

keepalive_requests 1000;

Contexto

http, server, location

Define el número máximo de peticiones que pueden servirse a través de una sola conexión keep-alive. Una vez alcanzado el número máximo de peticiones, la conexión se cierra.

El cierre periódico de conexiones es necesario para liberar asignaciones de memoria por conexión. Por lo tanto, usar un número máximo demasiado alto de peticiones puede provocar un uso excesivo de memoria y no se recomienda.

keepalive_time#

Sintaxis

keepalive_time time;

Predeterminado

keepalive_time 1h;

Contexto

http, server, location

Limita el tiempo máximo durante el cual pueden procesarse peticiones a través de una misma conexión keep-alive. Una vez alcanzado este tiempo, la conexión se cierra tras procesar la petición siguiente.

keepalive_timeout#

Sintaxis

keepalive_timeout timeout [header_timeout];

Predeterminado

keepalive_timeout 75s;

Contexto

http, server, location

timeout

define un tiempo de espera durante el cual una conexión keep-alive del cliente permanecerá abierta en el lado del servidor

0

desactiva las conexiones keep-alive de clientes

El segundo parámetro, opcional, establece un valor en el campo de cabecera de respuesta Keep-Alive: timeout=time. Los dos parámetros pueden diferir.

El campo de cabecera Keep-Alive: timeout=time es reconocido por Mozilla y Konqueror. MSIE cierra las conexiones keep-alive por sí mismo en aproximadamente 60 segundos.

large_client_header_buffers#

Sintaxis

large_client_header_buffers number size;

Predeterminado

large_client_header_buffers 4 8k;

Contexto

http, server

Define el número máximo y el tamaño de los búferes usados para leer cabeceras grandes de peticiones de clientes. Una línea de petición no puede exceder el tamaño de un búfer, o se devuelve al cliente el error 414 (Request-URI Too Large). Un campo de cabecera tampoco puede exceder el tamaño de un búfer, o se devuelve el error 400 (Bad Request).

Los búferes se asignan solo bajo demanda. Por defecto, el tamaño del búfer es de 8K bytes. Si, tras finalizar el procesamiento de la petición, una conexión pasa al estado keep-alive, estos búferes se liberan.

Si la directiva se especifica en el nivel server, puede usarse el valor del servidor por defecto.

limit_except#

Sintaxis

limit_except method1 [method2...] { ... };

Predeterminado

Contexto

location

Limita los métodos HTTP permitidos dentro de una ubicación. El parámetro method puede ser uno de los siguientes: GET, HEAD, POST, PUT, DELETE, MKCOL, COPY, MOVE, OPTIONS, PROPFIND, PROPPATCH, LOCK, UNLOCK o PATCH.

Permitir el método GET hace que el método HEAD también esté permitido. El acceso a otros métodos puede limitarse usando las directivas de los módulos Access y Auth Basic:

limit_except GET {
  allow 192.168.1.0/32;
  deny  all;
}

Nota

La restricción en este ejemplo se aplica a todos los métodos excepto GET y HEAD.

limit_rate#

Sintaxis

limit_rate rate;

Predeterminado

limit_rate 0;

Contexto

http, server, location, if in location

Limita la velocidad de transmisión de la respuesta hacia un cliente. La velocidad se especifica en bytes por segundo. El valor cero desactiva la limitación de velocidad.

El límite se aplica por petición; por lo tanto, si un cliente abre dos conexiones simultáneamente, la velocidad total será el doble del límite especificado.

El valor del parámetro puede contener variables. Esto puede ser útil en casos donde la velocidad deba limitarse en función de una condición determinada:

map $slow $rate {
  1     4k;
  2     8k;
}

limit_rate $rate;

El límite de velocidad también puede establecerse en la variable $limit_rate, aunque este método no se recomienda:

server {

  if ($slow) {
    set $limit_rate 4k;
  }

}

El límite de velocidad también puede establecerse en el campo de cabecera X-Accel-Limit-Rate de la respuesta de un servidor proxificado. Esta capacidad puede desactivarse mediante las directivas proxy_ignore_headers, fastcgi_ignore_headers, uwsgi_ignore_headers y scgi_ignore_headers.

limit_rate_after#

Sintaxis

limit_rate_after size;

Predeterminado

limit_rate_after 0;

Contexto

http, server, location, if in location

Define la cantidad inicial después de la cual la transmisión de una respuesta al cliente será limitada en velocidad. El valor del parámetro puede contener variables.

Ejemplo:

location /flv/ {
 flv;
 limit_rate_after 500k;
 limit_rate       50k;
}

lingering_close#

Sintaxis

lingering_close on | always | off;

Predeterminado

lingering_close on;

Contexto

http, server, location

Controla cómo Angie cierra las conexiones de clientes.

on

indica a Angie que espere y procese datos adicionales de un cliente antes de cerrar completamente la conexión, pero solo si la heurística sugiere que el cliente puede estar enviando más datos.

always

obliga a Angie a esperar y procesar datos adicionales del cliente de forma incondicional.

off

indica a Angie que nunca espere más datos y cierre la conexión inmediatamente. Este comportamiento rompe el protocolo y no debe usarse en circunstancias normales.

Para controlar el cierre de conexiones HTTP/2, la directiva debe especificarse en el nivel server.

lingering_time#

Sintaxis

lingering_time time;

Predeterminado

lingering_time 30s;

Contexto

http, server, location

Cuando lingering_close está activo, esta directiva especifica el tiempo máximo durante el cual Angie procesará (leerá e ignorará) datos adicionales provenientes del cliente. Después de ese tiempo, la conexión se cerrará, aunque lleguen más datos.

lingering_timeout#

Sintaxis

lingering_timeout time;

Predeterminado

lingering_timeout 5s;

Contexto

http, server, location

Cuando lingering_close está activo, esta directiva especifica el tiempo máximo de espera para que lleguen más datos del cliente. Si no se reciben datos durante este tiempo, la conexión se cierra. De lo contrario, los datos se leen y se ignoran, y Angie vuelve a esperar más datos. El ciclo de "esperar-leer-ignorar" se repite, pero nunca más allá del tiempo especificado por la directiva lingering_time.

Durante un apagado ordenado (graceful shutdown), las conexiones keep-alive de clientes solo se cierran si han estado inactivas al menos durante el tiempo especificado en lingering_timeout.

Nota

En nginx, una directiva similar se llama keepalive_min_timeout.

listen#

Sintaxis

listen address[:port] [default_server] [ssl] [http2 | quic] [proxy_protocol] [setfib=number] [fastopen=number] [backlog=number] [rcvbuf=size] [sndbuf=size] [accept_filter=filter] [deferred] [bind] [ipv6only=on | off] [reuseport] [so_keepalive=on|off|[keepidle]:[samp:keepintvl]:[samp:keepcnt]];

listen port [default_server] [ssl] [http2 | quic] [proxy_protocol] [setfib=number] [fastopen=number] [backlog=number] [rcvbuf=size] [sndbuf=size] [accept_filter=filter] [deferred] [bind] [ipv6only=on | off] [reuseport] [so_keepalive=on|off|[keepidle]:[samp:keepintvl]:[samp:keepcnt]];

listen unix:path [default_server] [ssl] [http2 | quic] [proxy_protocol] [backlog=number] [rcvbuf=size] [sndbuf=size] [accept_filter=filter] [deferred] [bind] [so_keepalive=on|off|[keepidle]:[samp:keepintvl]:[samp:keepcnt]];

Predeterminado

listen *:80 | *:8000;

Contexto

server

Define la address y el port para el socket de escucha, o la ruta de un socket UNIX donde el servidor aceptará peticiones. Una address también puede ser un nombre de host, por ejemplo:

listen 127.0.0.1:8000;
listen 127.0.0.1;
listen 8000;
listen *:8000;
listen localhost:8000;

Las direcciones IPv6 se especifican entre corchetes:

listen [::]:8000;
listen [::1];

Los sockets UNIX se especifican con el prefijo unix::

listen unix:/var/run/angie.sock;

Pueden especificarse tanto address como port, o solo address o solo port. Cuando se omiten algunas partes, se aplican las siguientes reglas:

  • Si solo se da la address, se usa el puerto 80.

  • Si solo se da el port, Angie escucha en todas las interfaces IPv4 disponibles (y también IPv6, si está habilitado). El primer bloque server para ese puerto se convierte en el servidor por defecto para peticiones con una cabecera Host no coincidente.

  • Si la directiva se omite por completo, Angie usa *:80 cuando se ejecuta con privilegios de superusuario, o *:8000 en caso contrario.

default_server

El servidor con este parámetro especificado será el servidor por defecto para el par address:port dado (juntos forman un socket de escucha).

Si no hay directivas con el parámetro default_server, el servidor por defecto para el socket de escucha será el primer servidor en la configuración que atienda ese socket.

ssl

Indica que todas las conexiones aceptadas en este socket de escucha deben funcionar en modo SSL. Esto permite una configuración más compacta para el servidor que maneja tanto peticiones HTTP como HTTPS.

http2

Configura el puerto para aceptar conexiones HTTP/2. Normalmente, para que esto funcione debe especificarse también el parámetro ssl, aunque Angie también puede configurarse para aceptar conexiones HTTP/2 sin SSL.

Obsoleto desde la versión 1.2.0.

Usa en su lugar la directiva http2.

quic

Configura el puerto para aceptar conexiones QUIC. Para usar esta opción, Angie debe tener el módulo HTTP/3 habilitado y configurado. Con quic activado, también se puede especificar reuseport para que puedan usarse múltiples procesos worker.

proxy_protocol

Indica que todas las conexiones aceptadas en este socket de escucha deben usar el protocolo PROXY.

La directiva listen también puede especificar varios parámetros adicionales relacionados con llamadas al sistema de sockets. Estos parámetros pueden indicarse en cualquier directiva listen, pero solo una vez para un socket de escucha determinado.

setfib=number

Define la tabla de enrutamiento, FIB (la opción SO_SETFIB) para el socket de escucha. Actualmente solo funciona en FreeBSD.

fastopen=number

Activa “TCP Fast Open” para el socket de escucha y limita la longitud máxima de la cola de conexiones que aún no han completado el handshake de tres vías.

Advertencia

No actives “TCP Fast Open” a menos que el servidor pueda manejar recibir el mismo paquete SYN con datos más de una vez.

backlog=number

Define el parámetro backlog en la llamada listen() que limita la longitud máxima de la cola de conexiones pendientes. Por defecto, backlog se establece en -1 en FreeBSD, DragonFly BSD y macOS, y en 511 en otras plataformas.

rcvbuf=size

Define el tamaño del búfer de recepción (la opción SO_RCVBUF) para el socket de escucha.

sndbuf=size

Define el tamaño del búfer de envío (la opción SO_SNDBUF) para el socket de escucha.

accept_filter=filter

Define el nombre del filtro de aceptación (la opción SO_ACCEPTFILTER) para el socket de escucha, que filtra conexiones entrantes antes de pasarlas a accept(). Solo funciona en FreeBSD y NetBSD 5.0+. Los valores posibles son dataready y httpready.

deferred

Indica usar un accept() diferido (la opción de socket TCP_DEFER_ACCEPT) en Linux.

bind

Indica realizar una llamada bind() separada para un par address:port dado. Esto es útil porque si existen varias directivas listen con el mismo puerto pero distintas direcciones, y una de ellas escucha en todas las direcciones (*:port), Angie hará bind() solo a *:port. En este caso, se realizará una llamada getsockname() para determinar la dirección que aceptó la conexión. Si se usan parámetros como setfib, fastopen, backlog, rcvbuf, sndbuf, accept_filter, deferred, ipv6only, reuseport o so_keepalive, entonces para un par address:port dado siempre se realizará una llamada bind() separada.

ipv6only=on | off

Determina (mediante la opción de socket IPV6_V6ONLY) si un socket IPv6 que escucha en una dirección comodín [::] aceptará solo conexiones IPv6 o tanto IPv6 como IPv4. Este parámetro está activado por defecto y solo puede configurarse una vez al inicio.

reuseport

Indica crear un socket de escucha individual para cada proceso worker (usando la opción de socket SO_REUSEPORT en Linux 3.9+ y DragonFly BSD, o SO_REUSEPORT_LB en FreeBSD 12+), permitiendo al kernel distribuir conexiones entrantes entre procesos worker. Actualmente solo funciona en Linux 3.9+, DragonFly BSD y FreeBSD 12+.

Advertencia

El uso inapropiado del parámetro reuseport puede tener implicaciones de seguridad.

multipath

Activa la aceptación de conexiones mediante Multipath TCP (MPTCP), soportado en el kernel Linux desde la versión 5.6. Este parámetro es incompatible con quic.

so_keepalive=on | off | [keepidle]:[samp:keepintvl]:[samp:keepcnt]

Configura el comportamiento de “TCP keepalive” para el socket de escucha.

''

si este parámetro se omite, se aplican los valores de configuración del sistema operativo para el socket

on

activa la opción SO_KEEPALIVE para el socket

off

desactiva la opción SO_KEEPALIVE para el socket

Algunos sistemas operativos permiten configurar los parámetros de TCP keepalive por socket mediante las opciones TCP_KEEPIDLE, TCP_KEEPINTVL y TCP_KEEPCNT. En dichos sistemas, pueden configurarse usando los parámetros keepidle, keepintvl y keepcnt. Se pueden omitir uno o dos parámetros; en tal caso se aplican los valores predeterminados del sistema. Por ejemplo:

so_keepalive=30m::10

establecerá el tiempo de inactividad (TCP_KEEPIDLE) en 30 minutos, mantendrá el intervalo de sondeo (TCP_KEEPINTVL) en su valor por defecto del sistema, y fijará el número de sondas (TCP_KEEPCNT) en 10.

Ejemplo:

listen 127.0.0.1 default_server accept_filter=dataready backlog=1024;

location#

Sintaxis

location ([ = | ~ | ~* | ^~ ] uri | @name)+ { ... }

Predeterminado

Contexto

server, location

Define la configuración en función de si el URI de la petición coincide con alguna de las expresiones de coincidencia.

La coincidencia se realiza contra un URI normalizado, después de decodificar el texto en formato “%XX”, resolver las referencias a componentes de ruta relativa “.” y “..”, y la posible compresión de dos o más barras consecutivas en una sola barra.

Un location puede definirse mediante una cadena prefijo o mediante una expresión regular.

Las expresiones regulares se especifican con un modificador precedente:

~*

Coincidencia sin distinción de mayúsculas

~

Coincidencia sensible a mayúsculas

Para encontrar un location que coincida con una petición, Angie primero comprueba los definidos con cadenas prefijo (prefix locations). Entre ellos, se selecciona y recuerda el de coincidencia más larga.

Nota

En sistemas operativos sin distinción de mayúsculas, como macOS, la coincidencia de prefijos es insensible a mayúsculas. Sin embargo, la coincidencia se limita a locales de un solo byte.

Después se comprueban las expresiones regulares en el orden en que aparecen en el archivo de configuración. La búsqueda se detiene en la primera coincidencia encontrada y se utiliza la configuración correspondiente. Si no se encuentra coincidencia con ninguna expresión regular, se usa la configuración del prefijo recordado anteriormente.

Con algunas excepciones que se mencionan más abajo, los bloques location pueden anidarse.

Las expresiones regulares pueden crear grupos de captura que pueden usarse posteriormente en otras directivas.

Si el prefijo más largo coincide con el modificador ^~, entonces no se comprueban las expresiones regulares.

También, con el modificador =, es posible definir una coincidencia exacta entre URI y location. Si se encuentra una coincidencia exacta, la búsqueda termina. Por ejemplo, si una petición a / ocurre con frecuencia, definir location =/ acelerará el procesamiento, ya que la búsqueda finaliza tras la primera comparación. Un location de coincidencia exacta no puede contener anidados, pues define una coincidencia única.

Ejemplo:

location =/ {
   #configuration A
}

location / {
   #configuration B
}

location /documents/ {
   #configuration C
}

location ^~/images/ {
   #configuration D
}

location ~*\.(gif|jpg|jpeg)$ {
   #configuration E
}
  • Una petición / coincidirá con la configuración A,

  • una petición /index.html coincidirá con la configuración B,

  • una petición /documents/document.html coincidirá con la configuración C,

  • una petición /images/1.gif coincidirá con la configuración D,

  • y una petición /documents/1.jpg coincidirá con la configuración E.

Nota

Si un location prefijo termina con una barra y auto_redirect está habilitado, ocurre lo siguiente: Cuando llega una petición con un URI que no tiene la barra final, pero coincide exactamente con el prefijo, se devuelve una redirección 301 permanente, apuntando al URI solicitado con la barra añadida.

Con un location de coincidencia exacta, no se aplica redirección:

location /user/ {
  proxy_pass http://user.example.com;
}

location =/user {
  proxy_pass http://login.example.com;
}

El prefijo @ define un location nombrado. Dichas ubicaciones no se usan en el procesamiento normal de peticiones, sino que están destinadas únicamente a redirecciones internas. No pueden anidarse ni contener ubicaciones anidadas.

Ubicaciones combinadas#

Varios contextos location que definan bloques de configuración idénticos pueden compactarse listando todas sus expresiones de coincidencia en un único location con un único bloque de configuración. A esto se le llama un location combinado.

Supongamos que las configuraciones A, D y E del ejemplo anterior definen configuraciones idénticas; puedes combinarlas en un único location:

location =/
         ^~/images/
         ~*\.(gif|jpg|jpeg)$ {
   # configuración general
}

Un location nombrado también puede formar parte de la combinación:

location =/
         @named_combined {
   #...
}

Advertencia

Un location combinado no puede tener un espacio entre la expresión de coincidencia y su modificador. Forma correcta: location ~*/match(ing|es|er)$ ....

Nota

Actualmente, un location combinado no puede inmediatamente contener proxy_pass u otras directivas similares con URI establecido, ni api o alias. Sin embargo, estas directivas sí pueden usarse en ubicaciones anidadas dentro de un location combinado.

log_not_found#

Sintaxis

log_not_found on | off;

Predeterminado

log_not_found on;

Contexto

http, server, location

Activa o desactiva el registro de errores sobre archivos no encontrados en error_log.

log_subrequest#

Sintaxis

log_subrequest on | off;

Predeterminado

log_subrequest off;

Contexto

http, server, location

Activa o desactiva el registro de subpeticiones en access_log.

max_headers#

Sintaxis

max_headers number;

Predeterminado

max_headers 1000;

Contexto

http, server

Define el número máximo de campos de cabecera de petición del cliente permitidos. Si se excede este límite, se devuelve un error 400 (Bad Request).

Cuando esta directiva se establece en el nivel server, puede aplicarse el valor del servidor por defecto. Para más información, consulta la sección Selección de servidor virtual.

max_ranges#

Sintaxis

max_ranges number;

Predeterminado

Contexto

http, server, location

Limita el número máximo permitido de rangos en peticiones con byte-range. Las peticiones que exceden el límite se procesan como si no hubieran especificado rangos. Por defecto, el número de rangos no está limitado.

0

desactiva completamente el soporte de byte-range

merge_slashes#

Sintaxis

merge_slashes on | off;

Predeterminado

merge_slashes on;

Contexto

http, server

Activa o desactiva la compresión de dos o más barras consecutivas en un URI en una sola barra.

Ten en cuenta que la compresión es esencial para la coincidencia correcta de locations de tipo prefijo y expresiones regulares. Sin ella, la petición //scripts/one.php no coincidiría con

location /scripts/ { }

y podría procesarse como un archivo estático. Así se convierte en /scripts/one.php.

Desactivar la compresión puede ser necesario si un URI contiene nombres codificados en base64, ya que base64 utiliza el carácter “/” internamente. Sin embargo, por motivos de seguridad, es mejor evitar desactivarla.

Si la directiva se especifica en el nivel server, puede usarse el valor del servidor por defecto.

msie_padding#

Sintaxis

msie_padding on | off;

Predeterminado

msie_padding on;

Contexto

http, server, location

Activa o desactiva la adición de comentarios en respuestas para clientes MSIE con códigos de estado superiores a 400, para aumentar el tamaño de la respuesta a 512 bytes.

msie_refresh#

Sintaxis

msie_refresh on | off;

Predeterminado

msie_refresh off;

Contexto

http, server, location

Activa o desactiva la emisión de refresh en lugar de redirecciones para clientes MSIE.

open_file_cache#

Sintaxis

open_file_cache off;

open_file_cache max=N [inactive=time];

Predeterminado

open_file_cache off;

Contexto

http, server, location

Configura una caché que puede almacenar:

  • descriptores de archivos abiertos, sus tamaños y tiempos de modificación;

  • información sobre existencia de directorios;

  • errores de búsqueda de archivos, como “archivo no encontrado”, “sin permiso de lectura”, etc.

El almacenamiento en caché de errores debe activarse por separado mediante la directiva open_file_cache_errors.

max

define el número máximo de elementos en la caché; en caso de desbordamiento, se eliminan los elementos menos utilizados recientemente (LRU);

inactive

define el tiempo tras el cual un elemento se elimina de la caché si no ha sido accedido durante este período; por defecto, está establecido en 60 segundos.

off

desactiva la caché.

Ejemplo:

open_file_cache          max=1000 inactive=20s;
open_file_cache_valid    30s;
open_file_cache_min_uses 2;
open_file_cache_errors   on;

open_file_cache_errors#

Sintaxis

open_file_cache_errors on | off;

Predeterminado

open_file_cache_errors off;

Contexto

http, server, location

Activa o desactiva el almacenamiento en caché de errores de búsqueda de archivos mediante open_file_cache.

open_file_cache_min_uses#

Sintaxis

open_file_cache_min_uses number;

Predeterminado

open_file_cache_min_uses 1;

Contexto

http, server, location

Define el número mínimo de accesos a un archivo durante el período configurado por el parámetro inactive de la directiva open_file_cache, requeridos para que un descriptor de archivo permanezca abierto en la caché.

open_file_cache_valid#

Sintaxis

open_file_cache_valid time;

Predeterminado

open_file_cache_valid 60s;

Contexto

http, server, location

Define un período tras el cual los elementos de open_file_cache deben ser validados.

output_buffers#

Sintaxis

output_buffers number size;

Predeterminado

output_buffers 2 32k;

Contexto

http, server, location

Define el número y tamaño de los búferes usados para leer una respuesta desde disco.

port_in_redirect#

Sintaxis

port_in_redirect on | off;

Predeterminado

port_in_redirect on;

Contexto

http, server, location

Activa o desactiva la inclusión del puerto en las redirecciones absolutas emitidas por Angie.

El uso del nombre de servidor principal en redirecciones se controla mediante la directiva server_name_in_redirect.

postpone_output#

Sintaxis

postpone_output size;

Predeterminado

postpone_output 1460;

Contexto

http, server, location

Si es posible, la transmisión de datos al cliente se pospondrá hasta que Angie tenga al menos el número especificado de bytes para enviar.

0

desactiva el aplazamiento de transmisión de datos

read_ahead#

Sintaxis

read_ahead size;

Predeterminado

read_ahead 0;

Contexto

http, server, location

Define la cantidad de lectura anticipada para el kernel al trabajar con archivos.

En Linux se utiliza la llamada al sistema posix_fadvise(0, 0, 0, POSIX_FADV_SEQUENTIAL), por lo que el parámetro de tamaño se ignora.

En FreeBSD se utiliza la llamada al sistema fcntl(O_READAHEAD, size ), soportada desde FreeBSD 9.0-CURRENT.

recursive_error_pages#

Sintaxis

recursive_error_pages on | off;

Predeterminado

recursive_error_pages off;

Contexto

http, server, location

Activa o desactiva la realización de varias redirecciones usando la directiva error_page. El número de estas redirecciones está limitado.

request_pool_size#

Sintaxis

request_pool_size size;

Predeterminado

request_pool_size 4k;

Contexto

http, server

Permite ajustar con precisión las asignaciones de memoria por petición. Esta directiva tiene un impacto mínimo en el rendimiento y generalmente no debería usarse.

reset_timedout_connection#

Sintaxis

reset_timedout_connection on | off;

Predeterminado

reset_timedout_connection off;

Contexto

http, server, location

Activa o desactiva el reseteo de conexiones que expiran por timeout y de conexiones cerradas con el código no estándar 444. El reseteo se realiza de la siguiente manera: antes de cerrar un socket, se le aplica la opción SO_LINGER con un valor de tiempo de espera de 0. Cuando se cierra el socket, se envía un TCP RST al cliente y se libera toda la memoria asociada a ese socket. Esto ayuda a evitar que un socket ya cerrado permanezca largo tiempo en estado FIN_WAIT1 con los búferes llenos.

Nota

Las conexiones keep-alive se cierran normalmente cuando expiran.

resolver#

Sintaxis

resolver address ... [valid=time] [ipv4=on | off] [ipv6=on | off] [status_zone=zone];

Predeterminado

Contexto

http, server, location, upstream

Configura los servidores de nombres usados para resolver los nombres de servidores upstream en direcciones, por ejemplo:

resolver 127.0.0.53 [::1]:5353;

La dirección puede especificarse como nombre de dominio o dirección IP, con un puerto opcional. Si no se especifica el puerto, se utiliza el 53. Los servidores de nombres se consultan en modo round-robin.

Por defecto, Angie almacena en caché las respuestas usando el valor TTL devuelto en la respuesta.

valid

parámetro opcional que permite sobrescribir el período de validez de la caché de respuestas

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

Por defecto, Angie buscará tanto direcciones IPv4 como IPv6 al resolver.

ipv4=off

desactiva la búsqueda de direcciones IPv4

ipv6=off

desactiva la búsqueda de direcciones IPv6

status_zone

parámetro opcional; activa la recogida de métricas de peticiones y respuestas de los servidores DNS (/status/resolvers/<zone>) en la zona especificada

Truco

Para prevenir ataques de suplantación DNS, se recomienda usar servidores DNS en una red local de confianza y debidamente securizada.

Truco

Al ejecutar en Docker, usa la dirección del servidor DNS interno correspondiente, como 127.0.0.11.

resolver_timeout#

Sintaxis

resolver_timeout time;

Predeterminado

resolver_timeout 30s;

Contexto

http, server, location, upstream

Define un tiempo de espera para la resolución de nombres, por ejemplo:

resolver_timeout 5s;

root#

Sintaxis

root path;

Predeterminado

root html;

Contexto

http, server, location, if in location

Define el directorio raíz para las peticiones. Por ejemplo, con la siguiente configuración:

location /i/ {
  root /data/w3;
}

El archivo /data/w3/i/top.gif se enviará en respuesta a la petición /i/top.gif.

El valor path puede contener variables, excepto $document_root y $realpath_root.

La ruta al archivo se construye simplemente añadiendo el URI al valor de la directiva root. Si el URI debe modificarse, debe usarse la directiva alias.

satisfy#

Sintaxis

satisfy all | any;

Predeterminado

satisfy all;

Contexto

http, server, location

Permite el acceso si todos (all) o al menos uno (any) de los módulos Access, Auth Basic o Auth Request autorizan el acceso.

location / {
  satisfy any;

  allow 192.168.1.0/32;
  deny  all;

  auth_basic           "closed site";
  auth_basic_user_file conf/htpasswd;
}

send_lowat#

Sintaxis

send_lowat size;

Predeterminado

send_lowat 0;

Contexto

http, server, location

Si la directiva se define con un valor distinto de cero, Angie intentará minimizar el número de operaciones de envío en los sockets de cliente, usando bien la bandera NOTE_LOWAT del método kqueue, o bien la opción de socket SO_SNDLOWAT. En ambos casos se usa el tamaño especificado.

send_timeout#

Sintaxis

send_timeout time;

Predeterminado

send_timeout 60s;

Contexto

http, server, location

Define un tiempo de espera para la transmisión de una respuesta al cliente. El tiempo se aplica únicamente entre dos operaciones de escritura consecutivas, no a la transmisión completa de la respuesta. Si el cliente no recibe nada en este intervalo, la conexión se cierra.

sendfile#

Sintaxis

sendfile on | off;

Predeterminado

sendfile off;

Contexto

http, server, location, if in location

Activa o desactiva el uso de sendfile().

aio puede usarse para precargar datos para sendfile():

location /video/ {
  sendfile       on;
  tcp_nopush     on;
  aio            on;
}

En esta configuración, sendfile() se invoca con la bandera SF_NODISKIO, lo que evita que bloquee en operaciones de E/S de disco, informando en su lugar de que los datos no están en memoria. Angie entonces inicia una carga de datos asíncrona leyendo un byte. En la primera lectura, el kernel de FreeBSD carga en memoria los primeros 128K de un archivo, mientras que las lecturas posteriores solo cargan bloques de 16K. Esto puede modificarse mediante la directiva read_ahead.

sendfile_max_chunk#

Sintaxis

sendfile_max_chunk size;

Predeterminado

sendfile_max_chunk 2m;

Contexto

http, server, location

Limita la cantidad de datos que pueden transferirse en una sola llamada a sendfile(). Sin este límite, una conexión rápida podría monopolizar completamente el proceso de trabajo.

server#

Sintaxis

server { ... }

Predeterminado

Contexto

http

Define la configuración para un servidor virtual. No hay una separación estricta entre servidores virtuales basados en IP (basados en la dirección IP) y basados en nombre (basados en la cabecera de petición “Host”). En su lugar, las directivas listen describen todas las direcciones y puertos que deben aceptar conexiones para el servidor, y la directiva server_name lista todos los nombres de servidor.

Se pueden encontrar ejemplos de configuración en el documento Cómo procesa Angie una petición.

server_name#

Sintaxis

server_name name ...;

Predeterminado

server_name "";

Contexto

server

Define los nombres de un servidor virtual, por ejemplo:

server {
  server_name example.com www.example.com;
}

El primer nombre se convierte en el nombre principal del servidor.

Los nombres de servidor pueden incluir un asterisco (“*”) sustituyendo la primera o última parte de un nombre:

server {
  server_name example.com *.example.com www.example.*;
}

Tales nombres se denominan nombres comodín (wildcard names).

Los dos primeros nombres del ejemplo anterior pueden combinarse en uno:

server {
  server_name .example.com;
}

También es posible usar expresiones regulares en los nombres de servidor, precediendo el nombre con una virgulilla (“~”):

server {
  server_name ~^www\d+\.example\.com$ www.example.com;
}

Las expresiones regulares pueden contener capturas que luego pueden usarse en otras directivas:

server {
  server_name ~^(www\.)?(.+)$;

  location / {
     root /sites/$2;
  }
}

server {
  server_name _;

  location / {
     root /sites/default;
  }
}

Los grupos de captura con nombre en expresiones regulares crean variables que luego pueden usarse en otras directivas:

server {
  server_name ~^(www\.)?(?<domain>.+)$;

  location / {
     root /sites/$domain;
  }
}

server {
  server_name _;

  location / {
     root /sites/default;
  }
}

Nota

Si la directiva se define como $hostname, se utiliza el nombre de host del servidor web.

También puedes especificar un nombre de servidor vacío (""):

server {
    server_name www.example.com "";
}

Al buscar un servidor virtual por nombre que coincida con múltiples opciones (por ejemplo, tanto un comodín como una expresión regular), se seleccionará la primera opción coincidente siguiendo este orden de prioridad:

  • nombre exacto;

  • nombre más largo con comodín al principio, como *.example.com;

  • nombre más largo con comodín al final, como mail.*;

  • la primera expresión regular coincidente (en orden de aparición en la configuración), incluyendo un nombre vacío.

Advertencia

Para que server_name funcione con TLS, es necesario terminar la conexión TLS. La directiva coincide con el Host en una petición HTTP, por lo que el handshake debe completarse y la conexión estar descifrada.

server_name_in_redirect#

Sintaxis

server_name_in_redirect on | off;

Predeterminado

server_name_in_redirect off;

Contexto

http, server, location

Activa o desactiva el uso del nombre de servidor principal, especificado mediante la directiva server_name, en las redirecciones absolutas emitidas por Angie.

on

se usa el nombre de servidor principal especificado en la directiva server_name

off

se usa el valor del campo de cabecera “Host” de la petición. Si este campo no está presente, se utiliza la dirección IP del servidor.

El uso de un puerto en las redirecciones se controla con la directiva port_in_redirect.

server_names_hash_bucket_size#

Sintaxis

server_names_hash_bucket_size size;

Predeterminado

server_names_hash_bucket_size 32 | 64 | 128;

Contexto

http

Define el tamaño de bloque (bucket size) para las tablas hash de nombres de servidor. El valor por defecto depende del tamaño de la línea de caché del procesador. Los detalles sobre la configuración de tablas hash se describen en un documento separado.

server_names_hash_max_size#

Sintaxis

server_names_hash_max_size size;

Predeterminado

server_names_hash_max_size 512;

Contexto

http

Define el tamaño máximo de las tablas hash de nombres de servidor. Los detalles sobre la configuración de tablas hash se describen en un documento separado.

server_tokens#

Sintaxis

server_tokens on | off | build | string;

Predeterminado

server_tokens on;

Contexto

http, server, location

Activa o desactiva la inclusión de la versión de Angie en las páginas de error y en el campo de cabecera de respuesta Server. El parámetro build activa la inclusión del nombre de compilación, definido mediante el parámetro correspondiente de configure, junto con la versión.

Added in version 1.1.0: PRO

En Angie PRO, si la directiva define una string, que también puede contener variables, las páginas de error y el campo de cabecera de respuesta Server utilizarán el valor de la cadena interpolada con variables en lugar del nombre del servidor, versión y nombre de compilación. Una string vacía desactiva completamente la emisión del campo Server.

status_zone#

Sintaxis

status_zone off | zone | key zone=zone[:number];

Predeterminado

Contexto

server, location, if in location

Reserva una zona de memoria compartida para recopilar las métricas de /status/http/location_zones/<zone> y /status/http/server_zones/<zone>.

Varios contextos server pueden compartir la misma zona para la recogida de datos; el valor especial off desactiva la recogida de datos en bloques location anidados.

La sintaxis con un único valor zone combina todas las métricas del contexto actual en una sola zona de memoria compartida:

server {

    listen 80;
    server_name *.example.com;

    status_zone single;
    # ...
}

La sintaxis alternativa permite definir los siguientes parámetros:

key

Una cadena con variables, cuyo valor determina la agrupación de las peticiones en la zona. Todas las peticiones que produzcan valores idénticos tras la sustitución se agrupan juntas. Si la sustitución produce un valor vacío, las métricas no se actualizan.

zone

El nombre de la zona de memoria compartida.

number (opcional)

El número máximo de grupos separados para recopilar métricas. Si nuevos valores de key superan este límite, se agrupan bajo zone.

El valor por defecto es 1.

En el siguiente ejemplo, todas las peticiones que compartan el mismo valor de $host se agrupan en la zona host_zone. Las métricas se rastrean por separado para cada $host único hasta un máximo de 10 grupos de métricas. Una vez alcanzado este límite, cualquier valor adicional de $host se incluye bajo host_zone:

server {

    listen 80;
    server_name *.example.com;

    status_zone $host zone=host_zone:10;

    location / {

        proxy_pass http://example.com;
    }
}

De este modo, las métricas resultantes se dividen entre hosts individuales en la salida de la API.

subrequest_output_buffer_size#

Sintaxis

subrequest_output_buffer_size size;

Predeterminado

subrequest_output_buffer_size 4k | 8k;

Contexto

http, server, location

Define el tamaño del búfer usado para almacenar el cuerpo de la respuesta de una subrequest. Por defecto, el tamaño del búfer es igual a una página de memoria. Esto corresponde a 4K o 8K, dependiendo de la plataforma. Puede configurarse más pequeño si es necesario.

Nota

La directiva es aplicable solo a subrequests cuyos cuerpos de respuesta se guardan en memoria. Por ejemplo, tales subrequests son creados por SSI.

tcp_nodelay#

Sintaxis

tcp_nodelay on | off;

Predeterminado

tcp_nodelay on;

Contexto

http, server, location

Activa o desactiva el uso de la opción TCP_NODELAY. La opción se activa cuando una conexión pasa al estado keep-alive. Además, se activa en conexiones SSL, para el proxying sin búfer y para proxying de WebSocket.

tcp_nopush#

Sintaxis

tcp_nopush on | off;

Predeterminado

tcp_nopush off;

Contexto

http, server, location

Activa o desactiva el uso de la opción de socket TCP_NOPUSH en FreeBSD o la opción TCP_CORK en Linux. Estas opciones solo se activan cuando se usa sendfile. Al activarse, permiten:

  • enviar la cabecera de respuesta y el inicio de un archivo en un único paquete (en Linux y FreeBSD 4.*);

  • enviar un archivo en paquetes completos.

try_files#

Sintaxis

try_files file ... uri;

try_files file ... =code;

Predeterminado

Contexto

server, location

Verifica la existencia de archivos en el orden especificado y utiliza el primer archivo encontrado para procesar la petición; el procesamiento se realiza en el contexto actual. La ruta a un archivo se construye a partir del parámetro file según las directivas root y alias. Es posible verificar la existencia de un directorio añadiendo una barra al final del nombre, por ejemplo $uri/. Si no se encuentra ningún archivo, se realiza una redirección interna al uri especificado en el último parámetro. Por ejemplo:

location /images/ {
  try_files $uri /images/default.gif;
}

location = /images/default.gif {
  expires 30s;
}

El último parámetro también puede apuntar a un location con nombre, como se muestra en los ejemplos siguientes. El último parámetro también puede ser un código:

location / {
  try_files $uri $uri/index.html $uri.html =404;
}

En el siguiente ejemplo:

location / {
  try_files $uri $uri/ @drupal;
}

la directiva try_files es equivalente a:

location / {
  error_page 404 = @drupal;
  log_not_found off;
}

Y aquí:

location ~ \.php$ {
  try_files $uri @drupal;

  fastcgi_pass ...;

  fastcgi_param SCRIPT_FILENAME /path/to$fastcgi_script_name;

#  ...
}

try_files comprueba la existencia del archivo PHP antes de pasar la petición al servidor FastCGI.

Ejemplo con proxying a Mongrel:
location / {
  try_files /system/maintenance.html
           $uri $uri/index.html $uri.html
           @mongrel;
}

location @mongrel {
  proxy_pass http://mongrel;
}
Ejemplo para Drupal/FastCGI:
location / {
  try_files $uri $uri/ @drupal;
}

location ~ \.php$ {
  try_files $uri @drupal;

  fastcgi_pass ...;

  fastcgi_param SCRIPT_FILENAME /path/to$fastcgi_script_name;
  fastcgi_param SCRIPT_NAME     $fastcgi_script_name;
  fastcgi_param QUERY_STRING    $args;

#  ... otros fastcgi_param
}

location @drupal {
  fastcgi_pass ...;

  fastcgi_param SCRIPT_FILENAME /path/to/index.php;
  fastcgi_param SCRIPT_NAME     /index.php;
  fastcgi_param QUERY_STRING    q=$uri&$args;

#  ... otros fastcgi_param
}
Ejemplo para Wordpress y Joomla:
location / {
  try_files $uri $uri/ @wordpress;
}

location ~ \.php$ {
  try_files $uri @wordpress;

  fastcgi_pass ...;

  fastcgi_param SCRIPT_FILENAME /path/to$fastcgi_script_name;
#  ... otros fastcgi_param
}

location @wordpress {
  fastcgi_pass ...;

  fastcgi_param SCRIPT_FILENAME /path/to/index.php;
#  ... otros fastcgi_param
}

types#

Sintaxis

types { ... }

Predeterminado

types text/html html; image/gif gif; image/jpeg jpg;

Contexto

http, server, location

Asocia extensiones de nombre de archivo con tipos MIME de las respuestas. Las extensiones no distinguen entre mayúsculas y minúsculas. Varias extensiones pueden asignarse a un mismo tipo, por ejemplo:

types {
  application/octet-stream bin exe dll;
  application/octet-stream deb;
  application/octet-stream dmg;
}

Una tabla de asignación suficientemente completa se distribuye con Angie y se encuentra en el archivo conf/mime.types.

Para hacer que un location concreto devuelva el tipo MIME "application/octet-stream" en todas las respuestas, se puede usar la siguiente configuración:

location /download/ {
  types        { }
  default_type application/octet-stream;
}

types_hash_bucket_size#

Sintaxis

types_hash_bucket_size size;

Predeterminado

types_hash_bucket_size 64;

Contexto

http, server, location

Define el tamaño de bloque (bucket size) para las tablas hash de tipos. Los detalles de la configuración de tablas hash se tratan por separado.

types_hash_max_size#

Sintaxis

types_hash_max_size size;

Predeterminado

types_hash_max_size 1024;

Contexto

http, server, location

Define el tamaño máximo de las tablas hash de tipos. Los detalles de la configuración de tablas hash se tratan por separado.

underscores_in_headers#

Sintaxis

underscores_in_headers on | off;

Predeterminado

underscores_in_headers off;

Contexto

http, server

Activa o desactiva el uso de guiones bajos en los nombres de campos de cabecera de las peticiones de cliente. Cuando el uso de guiones bajos está desactivado, los campos de cabecera que contengan guiones bajos se marcan como inválidos y quedan sujetos a la directiva ignore_invalid_headers.

Si la directiva se especifica en el nivel server, puede usarse el valor del servidor por defecto.

variables_hash_bucket_size#

Sintaxis

variables_hash_bucket_size size;

Predeterminado

variables_hash_bucket_size 64;

Contexto

http

Define el tamaño de bloque (bucket size) para la tabla hash de variables. Los detalles de la configuración de tablas hash se tratan por separado.

variables_hash_max_size#

Sintaxis

variables_hash_max_size size;

Predeterminado

variables_hash_max_size 1024;

Contexto

http

Define el tamaño máximo de la tabla hash de variables. Los detalles de la configuración de tablas hash se tratan por separado.

Variables integradas#

El módulo http_core admite variables integradas con nombres que coinciden con las variables de Apache Server. Ante todo, se trata de variables que representan campos de cabecera de las peticiones del cliente, como $http_user_agent, $http_cookie, etc. Además, existen otras variables:

$angie_version#

Versión de Angie

$arg_<name>#

argumento name en la línea de petición

$args#

argumentos en la línea de petición

$binary_remote_addr#

dirección del cliente en forma binaria; la longitud del valor es siempre de 4 bytes para direcciones IPv4 o 16 bytes para IPv6

$body_bytes_sent#

número de bytes enviados al cliente, sin contar la cabecera de la respuesta; esta variable es compatible con el parámetro "%B" del módulo Apache mod_log_config

$bytes_sent#

número de bytes enviados a un cliente

$connection#

número de serie de la conexión

$connection_requests#

número actual de peticiones realizadas a través de una conexión

$connection_time#

tiempo de la conexión en segundos con resolución en milisegundos

$content_length#

campo de cabecera Content-Length de la petición

$content_type#

campo de cabecera Content-Type de la petición

$document_root#

valor de las directivas root o alias para la petición actual

$document_uri#

igual que $uri

$host#

en este orden de precedencia: nombre de host de la línea de petición, o nombre de host del campo de cabecera "Host", o el nombre de servidor que coincide con la petición

$hostname#

nombre del host

$http_<name>#

campo de cabecera arbitrario de la petición; la última parte del nombre de la variable corresponde al nombre del campo convertido a minúsculas con guiones sustituidos por guiones bajos

$https#

on si la conexión funciona en modo SSL, o una cadena vacía en caso contrario

$is_args#

? si la línea de petición contiene argumentos, o una cadena vacía en caso contrario

$limit_rate#

configurar esta variable habilita la limitación de la velocidad de respuesta; véase limit_rate

$msec#

hora actual en segundos con resolución en milisegundos

$pid#

PID del proceso trabajador

$pipe#

p si la petición fue pipelined, . en caso contrario

$proxy_protocol_addr#

dirección del cliente desde la cabecera del protocolo PROXY

El protocolo PROXY debe habilitarse previamente configurando el parámetro proxy_protocol en la directiva listen.

$proxy_protocol_port#

puerto del cliente desde la cabecera del protocolo PROXY

El protocolo PROXY debe habilitarse previamente configurando el parámetro proxy_protocol en la directiva listen.

$proxy_protocol_server_addr#

dirección del servidor desde la cabecera del protocolo PROXY

El protocolo PROXY debe habilitarse previamente configurando el parámetro proxy_protocol en la directiva listen.

$proxy_protocol_server_port#

puerto del servidor desde la cabecera del protocolo PROXY

El protocolo PROXY debe habilitarse previamente configurando el parámetro proxy_protocol en la directiva listen.

$proxy_protocol_tlv_<name>#

TLV desde la cabecera del protocolo PROXY. El name puede ser un nombre de tipo TLV o su valor numérico. En este último caso, el valor es hexadecimal y debe ir precedido de 0x:

$proxy_protocol_tlv_alpn
$proxy_protocol_tlv_0x01

Los TLV SSL también pueden accederse mediante el nombre del tipo TLV o su valor numérico, ambos precedidos por ssl_:

$proxy_protocol_tlv_ssl_version
$proxy_protocol_tlv_ssl_0x21

Se admiten los siguientes nombres de tipo TLV:

  • alpn (0x01) - protocolo de capa superior usado en la conexión

  • authority (0x02) - nombre de host enviado por el cliente

  • unique_id (0x05) - identificador único de la conexión

  • netns (0x30) - nombre del namespace

  • ssl (0x20) - estructura binaria SSL TLV

Se admiten los siguientes nombres de tipo TLV SSL:

  • ssl_version (0x21) - versión de SSL usada en la conexión del cliente

  • ssl_cn (0x22) - Common Name del certificado SSL

  • ssl_cipher (0x23) - nombre del cifrado utilizado

  • ssl_sig_alg (0x24) - algoritmo usado para firmar el certificado

  • ssl_key_alg (0x25) - algoritmo de clave pública

Además, se admite el siguiente nombre especial de tipo TLV SSL:

  • ssl_verify - resultado de la verificación del certificado SSL del cliente: 0 si el cliente presentó un certificado y se verificó correctamente, distinto de cero en caso contrario

El protocolo PROXY debe habilitarse previamente configurando el parámetro proxy_protocol en la directiva listen.

$query_string#

igual que $args

$realpath_root#

ruta absoluta correspondiente al valor de las directivas root o alias para la petición actual, con todos los enlaces simbólicos resueltos a rutas reales

$remote_addr#

dirección del cliente

$remote_port#

puerto del cliente

$remote_user#

nombre de usuario suministrado mediante autenticación básica

$request#

línea de petición original completa

$request_body#

cuerpo de la petición

El valor de la variable está disponible en los location procesados por las directivas proxy_pass, fastcgi_pass, uwsgi_pass y scgi_pass cuando el cuerpo de la petición se ha leído en un búfer de memoria.

$request_body_file#

Nombre de un archivo temporal con el cuerpo de la petición. Al final del procesamiento, el archivo debe eliminarse. Para escribir siempre el cuerpo de la petición en un archivo, activa client_body_in_file_only. Cuando se pasa el nombre de un archivo temporal en una petición proxy o en una petición a un servidor FastCGI/uwsgi/SCGI, el envío del cuerpo de la petición debe deshabilitarse con las directivas proxy_pass_request_body off, fastcgi_pass_request_body off, uwsgi_pass_request_body off o scgi_pass_request_body off respectivamente.

$request_completion#

OK si la petición se ha completado, o una cadena vacía en caso contrario

$request_filename#

ruta del archivo para la petición actual, basada en las directivas root o alias y en el URI solicitado

$request_id#

identificador único de la petición generado a partir de 16 bytes aleatorios, en hexadecimal

$request_length#

longitud de la petición (incluyendo línea de petición, cabeceras y cuerpo)

$request_method#

método de la petición, normalmente GET o POST

$request_time#

tiempo de procesamiento de la petición en segundos con resolución en milisegundos; tiempo transcurrido desde que se leyeron los primeros bytes del cliente

$request_uri#

URI original completo de la petición (con argumentos)

$scheme#

esquema de la petición, "http" o "https"

$sent_http_<name>#

campo de cabecera arbitrario de la respuesta; la última parte del nombre de la variable corresponde al nombre del campo convertido a minúsculas con guiones sustituidos por guiones bajos

$sent_trailer_<name>#

campo arbitrario enviado al final de la respuesta; la última parte del nombre de la variable corresponde al nombre del campo convertido a minúsculas con guiones sustituidos por guiones bajos

$server_addr#

dirección del servidor que aceptó la petición.

El cálculo del valor de esta variable suele requerir una llamada al sistema. Para evitarla, las directivas listen deben especificar direcciones y usar el parámetro bind.

$server_name#

nombre del servidor que aceptó la petición

$server_port#

puerto del servidor que aceptó la petición

$server_protocol#

protocolo de la petición, normalmente "HTTP/1.0", "HTTP/1.1" o "HTTP/2.0"

$status#

estado de la respuesta

$time_iso8601#

hora local en formato estándar ISO 8601

$time_local#

hora local en formato Common Log Format

$tcpinfo_rtt, $tcpinfo_rttvar, $tcpinfo_snd_cwnd, $tcpinfo_rcv_space#

información sobre la conexión TCP del cliente; disponible en sistemas que admiten la opción de socket TCP_INFO

$uri#

URI actual en la petición, normalizado.

El valor de $uri puede cambiar durante el procesamiento de la petición, por ejemplo, al realizar redirecciones internas o al usar archivos índice.