# Conexiones, Sesiones, Solicitudes, Registros ## Mecanismos de procesamiento de conexiones Angie admite varios métodos de procesamiento de conexiones. La disponibilidad de un método específico depende de la plataforma que se esté utilizando. En plataformas que admiten múltiples métodos, Angie suele seleccionar automáticamente el método más eficiente. No obstante, si es necesario, se puede elegir explícitamente un método de procesamiento de conexiones usando la directiva [use](https://es.angie.software//angie/docs/configuration/modules/core.md#use). Los siguientes métodos de procesamiento de conexiones están disponibles: | Método | Descripción | |-------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | `select` | Un método estándar. El módulo de soporte se crea automáticamente en plataformas que no disponen de métodos más eficientes. Las opciones de compilación `--with-select_module` y `--without-select_module` pueden usarse para habilitar o deshabilitar la construcción de este módulo de forma forzada. | | `poll` | Un método estándar. El módulo de soporte se crea automáticamente en plataformas que no disponen de métodos más eficientes. Las opciones de compilación `--with-poll_module` y `--without-poll_module` pueden usarse para habilitar o deshabilitar la construcción de este módulo de forma forzada. | | `kqueue` | Un método eficiente disponible en FreeBSD 4.1+, OpenBSD 2.9+, NetBSD 2.0 y macOS. | | `epoll` | Un método eficiente disponible en Linux 2.6+. | | `/dev/poll` | Un método eficiente disponible en Solaris 7 11/99+, HP/UX 11.22+ (eventport), IRIX 6.5.15+ y Tru64 UNIX 5.1A+. | | `eventport` | El método `event ports` está disponible en Solaris 10+. (Debido a problemas conocidos, se recomienda utilizar el método `/dev/poll` en su lugar.) | ## Procesamiento de solicitudes HTTP Una solicitud HTTP atraviesa una serie de fases, durante las cuales se realiza un tipo específico de procesamiento en cada fase. | `Post-read` | La fase inicial. En esta fase se invoca el módulo [RealIP](https://es.angie.software//angie/docs/configuration/modules/http/http_realip.md#http-realip). | |------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | `Server-rewrite` | La fase en la que se procesan las directivas del módulo [Rewrite](https://es.angie.software//angie/docs/configuration/modules/http/http_rewrite.md#http-rewrite), definidas dentro de un bloque `server` (pero fuera de un bloque `location`). | | `Find-config` | Una fase especial en la que se selecciona una [location](https://es.angie.software//angie/docs/configuration/modules/http/index.md#location) basada en la URI de la solicitud. | | `Rewrite` | Similar a la fase `Server-rewrite`, pero se aplica a las reglas [rewrite](https://es.angie.software//angie/docs/configuration/modules/http/http_rewrite.md#id4) definidas dentro del bloque de location seleccionado en la fase anterior. | | `Post-rewrite` | Una fase especial en la que la solicitud se redirige a una nueva ubicación, como en la fase `Find-config`, si su URI fue modificada durante la fase `Rewrite`. | | `Preaccess` | Durante esta fase, módulos estándar de Angie como [Limit Req](https://es.angie.software//angie/docs/configuration/modules/http/http_limit_req.md#http-limit-req) registran sus manejadores. | | `Access` | La fase en la que se verifica la autorización del cliente para realizar la solicitud, normalmente invocando módulos estándar de Angie como [Auth Basic](https://es.angie.software//angie/docs/configuration/modules/http/http_auth_basic.md#http-auth-basic). | | `Post-access` | Una fase especial en la que se procesa la directiva [satisfy any](https://es.angie.software//angie/docs/configuration/modules/http/index.md#satisfy). | | `Precontent` | Las directivas de módulos estándar, como [try_files](https://es.angie.software//angie/docs/configuration/modules/http/index.md#try-files) y [mirror](https://es.angie.software//angie/docs/configuration/modules/http/http_mirror.md#id1), registran sus manejadores durante esta fase. | | `Content` | La fase en la que normalmente se genera la respuesta. Varios módulos estándar de Angie registran sus manejadores en esta etapa, incluyendo [Index](https://es.angie.software//angie/docs/configuration/modules/http/http_index.md#http-index). Las directivas [proxy_pass](https://es.angie.software//angie/docs/configuration/modules/http/http_proxy.md#proxy-pass), [fastcgi_pass](https://es.angie.software//angie/docs/configuration/modules/http/http_fastcgi.md#fastcgi-pass), [uwsgi_pass](https://es.angie.software//angie/docs/configuration/modules/http/http_uwsgi.md#uwsgi-pass), [scgi_pass](https://es.angie.software//angie/docs/configuration/modules/http/http_scgi.md#scgi-pass) y [grpc_pass](https://es.angie.software//angie/docs/configuration/modules/http/http_grpc.md#grpc-pass) también se gestionan aquí.

Los manejadores se invocan de forma secuencial hasta que uno de ellos genera la salida. | | `Log` | La fase final, en la que se registra la solicitud. Actualmente, solo el módulo [Log](https://es.angie.software//angie/docs/configuration/modules/http/http_log.md#http-log) registra su manejador en esta etapa para el registro de acceso. | ## Procesamiento de sesiones TCP/UDP Una sesión TCP/UDP de un cliente atraviesa una serie de fases, durante las cuales se realiza un tipo específico de procesamiento en cada fase: | `Post-accept` | La fase inicial tras aceptar una conexión del cliente. En esta fase se invoca el módulo [RealIP](https://es.angie.software//angie/docs/configuration/modules/stream/stream_realip.md#stream-realip). | |-----------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | `Pre-access` | Una fase preliminar para comprobar el acceso. Los módulos [Set](https://es.angie.software//angie/docs/configuration/modules/stream/stream_set.md#stream-set) se invocan durante esta fase. | | `Access` | La fase en la que se limita el acceso del cliente antes del procesamiento real de datos. El módulo [Access](https://es.angie.software//angie/docs/configuration/modules/stream/stream_access.md#stream-access) se invoca en esta etapa. | | `SSL` | La fase en la que tiene lugar la terminación TLS/SSL. El módulo [SSL](https://es.angie.software//angie/docs/configuration/modules/stream/stream_ssl.md#stream-ssl) se invoca durante esta fase. | | `Preread` | La fase para leer los bytes iniciales de datos en el [búfer de prelectura](https://es.angie.software//angie/docs/configuration/modules/stream/index.md#s-preread-buffer-size) para permitir que módulos como [SSL Preread](https://es.angie.software//angie/docs/configuration/modules/stream/stream_ssl_preread.md#stream-ssl-preread) analicen los datos antes del procesamiento. | | `Content` | Una fase obligatoria en la que realmente se procesan los datos, normalmente involucrando el módulo [Return](https://es.angie.software//angie/docs/configuration/modules/stream/stream_return.md#stream-return) para enviar una respuesta al cliente. La directiva [proxy_pass](https://es.angie.software//angie/docs/configuration/modules/stream/stream_proxy.md#s-proxy-pass) también se maneja aquí. | | `Log` | La fase final en la que se registra el resultado del procesamiento de la sesión del cliente. El módulo [Log](https://es.angie.software//angie/docs/configuration/modules/stream/stream_log.md#stream-log) se invoca en esta fase. | ## Procesamiento de solicitudes ### Selección de servidor virtual Inicialmente, se crea una conexión dentro del contexto de un servidor predeterminado. El nombre del servidor puede determinarse en las siguientes etapas del procesamiento de la solicitud, cada una de las cuales está involucrada en la selección de la configuración del servidor: - Durante el protocolo de enlace SSL, de antemano, según el SNI. - Después de procesar la línea de solicitud. - Después de procesar el campo de cabecera `Host`. Si el nombre del servidor no se determina después de procesar la línea de solicitud o el campo de cabecera `Host`, Angie utilizará un nombre vacío como nombre de servidor. En cada una de estas etapas, se pueden aplicar diferentes configuraciones de servidor. Por lo tanto, ciertas directivas deben especificarse con precaución: - En el caso de la directiva [ssl_protocols](https://es.angie.software//angie/docs/configuration/modules/http/http_ssl.md#ssl-protocols), la lista de protocolos es establecida por la biblioteca OpenSSL antes de que se aplique la configuración del servidor según el nombre solicitado a través de SNI. Como resultado, los protocolos solo deben especificarse para el servidor predeterminado. - Las directivas [client_header_buffer_size](https://es.angie.software//angie/docs/configuration/modules/http/index.md#client-header-buffer-size) y [merge_slashes](https://es.angie.software//angie/docs/configuration/modules/http/index.md#merge-slashes) se aplican antes de leer la línea de solicitud. Por lo tanto, estas directivas utilizan la configuración del servidor predeterminado o la configuración del servidor elegida por SNI. - En el caso de las directivas [ignore_invalid_headers](https://es.angie.software//angie/docs/configuration/modules/http/index.md#ignore-invalid-headers), [large_client_header_buffers](https://es.angie.software//angie/docs/configuration/modules/http/index.md#large-client-header-buffers) y [underscores_in_headers](https://es.angie.software//angie/docs/configuration/modules/http/index.md#underscores-in-headers), que están involucradas en el procesamiento de los campos de cabecera de solicitud, la configuración del servidor depende adicionalmente de si se actualizó según la línea de solicitud o el campo de cabecera `Host`. - Una respuesta de error se gestiona mediante la directiva [error_page](https://es.angie.software//angie/docs/configuration/modules/http/index.md#error-page) en el servidor que está procesando actualmente la solicitud. ### Servidores virtuales basados en nombres Angie determina primero qué servidor debe manejar la solicitud. Considere una configuración simple donde los tres servidores virtuales escuchan en el puerto 80: ```nginx server { listen 80; server_name example.org www.example.org; # ... } server { listen 80; server_name example.net www.example.net; # ... } server { listen 80; server_name example.com www.example.com; # ... } ``` En esta configuración, Angie determina qué servidor debe manejar la solicitud basándose únicamente en el campo de cabecera `Host`. Si el valor de esta cabecera no coincide con ningún nombre de servidor o si la solicitud no contiene este campo de cabecera, Angie enviará la solicitud al servidor predeterminado para este puerto. En la configuración anterior, el servidor predeterminado es el primero, que es el comportamiento predeterminado estándar de Angie. También se puede especificar explícitamente qué servidor debe ser el predeterminado utilizando el parámetro `default_server` en la directiva [listen](https://es.angie.software//angie/docs/configuration/modules/http/index.md#listen): ```nginx server { listen 80 default_server; server_name example.net www.example.net; # ... } ``` #### NOTE Tenga en cuenta que el servidor predeterminado es una propiedad del socket de escucha, no del nombre del servidor. ### Nombres internacionalizados Los [nombres de dominio internacionalizados (IDN)](https://en.wikipedia.org/wiki/Internationalized_domain_name) deberían especificarse utilizando una representación ASCII (Punycode) en la directiva [server_name](https://es.angie.software//angie/docs/configuration/modules/http/index.md#server-name) (nombre del servidor): ```nginx server { listen 80; server_name xn--e1afmkfd.xn--80akhbyknj4f; # пример.испытание # ... } ``` ### Prevención de solicitudes con nombres de servidor indefinidos Si no se deben permitir solicitudes sin el campo de cabecera `Host`, se puede definir un servidor que simplemente descarte esas solicitudes: ```nginx server { listen 80; server_name ""; return 444; } ``` En esta configuración, el nombre del servidor se establece como una cadena vacía, que coincide con las solicitudes sin el campo de cabecera `Host`. A continuación se devuelve un código especial no estándar 444, que cierra la conexión. ### Combinación de servidores virtuales basados en nombre y en IP Examinemos una configuración más compleja en la que algunos servidores virtuales escuchan en diferentes direcciones: ```nginx server { listen 192.168.1.1:80; server_name example.org www.example.org; # ... } server { listen 192.168.1.1:80; server_name example.net www.example.net; # ... } server { listen 192.168.1.2:80; server_name example.com www.example.com; # ... } ``` En esta configuración, Angie primero verifica la dirección IP y el puerto de la solicitud contra las directivas [listen](https://es.angie.software//angie/docs/configuration/modules/http/index.md#listen) de los bloques [server](https://es.angie.software//angie/docs/configuration/modules/http/index.md#server). Luego verifica el campo de cabecera `Host` de la solicitud frente a las entradas [server_name](https://es.angie.software//angie/docs/configuration/modules/http/index.md#server-name) de los bloques [server](https://es.angie.software//angie/docs/configuration/modules/http/index.md#server) que coincidieron con la dirección IP y el puerto. Si no se encuentra el nombre del servidor, la solicitud será procesada por el servidor predeterminado. Por ejemplo, una solicitud para `www.example.com` recibida en el puerto 192.168.1.1:80 será manejada por el servidor predeterminado para ese puerto — es decir, por el primer servidor — ya que `www.example.com` no está definido para este puerto. Como se mencionó anteriormente, un servidor predeterminado es una propiedad del puerto de escucha, y se pueden definir diferentes servidores predeterminados para distintos puertos: ```nginx server { listen 192.168.1.1:80; server_name example.org www.example.org; # ... } server { listen 192.168.1.1:80 default_server; server_name example.net www.example.net; # ... } server { listen 192.168.1.2:80 default_server; server_name example.com www.example.com; # ... } ``` ### Elección de ubicaciones Consideremos una configuración simple de un sitio web PHP: ```nginx server { listen 80; server_name example.org www.example.org; root /data/www; location / { index index.html index.php; } location ~* \.(gif|jpg|png)$ { expires 30d; } location ~ \.php$ { fastcgi_pass localhost:9000; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } } ``` Angie primero busca la `location` de prefijo más específica dada por cadenas literales, independientemente del orden en que estén listadas. En la configuración anterior, la única ubicación de prefijo es `location /`, que coincide con cualquier solicitud y se utilizará como último recurso. Luego, Angie comprueba las ubicaciones definidas por expresiones regulares en el orden en que aparecen en el archivo de configuración. La primera expresión coincidente detiene la búsqueda, y Angie utilizará esa `location`. Si ninguna expresión regular coincide con una solicitud, Angie utilizará la `location` de prefijo más específica encontrada anteriormente. #### NOTE Las ubicaciones de todos los tipos solo prueban la parte URI de la línea de solicitud, excluyendo los argumentos. Esto se debe a que los argumentos en la cadena de consulta pueden especificarse de varias maneras, por ejemplo: - `/index.php?user=john&page=1` - `/index.php?page=1&user=john` Además, las cadenas de consulta pueden contener cualquier número de parámetros: - `/index.php?page=1&something+else&user=john` Ahora veamos cómo se procesarían las solicitudes en la configuración anterior: - La solicitud `/logo.gif` primero coincide con el prefijo `location /` y luego con la expresión regular `.(gif|jpg|png)$`. Por lo tanto, es manejada por la última ubicación. Usando la directiva `root /data/www`, la solicitud se asigna al archivo `/data/www/logo.gif`, y el archivo se envía al cliente. - La solicitud `/index.php` también coincide inicialmente con el prefijo `location /` y luego con la expresión regular `.(php)$`. En consecuencia, es manejada por esta última ubicación, y la solicitud se pasa a un servidor FastCGI que escucha en `localhost:9000`. La directiva [fastcgi_param](https://es.angie.software//angie/docs/configuration/modules/http/http_fastcgi.md#fastcgi-param) establece el parámetro FastCGI `SCRIPT_FILENAME` a `/data/www/index.php`, y el servidor FastCGI ejecuta el archivo. La variable [$document_root](https://es.angie.software//angie/docs/configuration/modules/http/index.md#v-document-root) se establece con el valor de la directiva `root`, y la variable [$fastcgi_script_name](https://es.angie.software//angie/docs/configuration/modules/http/http_fastcgi.md#v-fastcgi-script-name) se establece con el URI de la solicitud, es decir, `/index.php`. - La solicitud `/about.html` solo coincide con el prefijo `location /`, por lo que se maneja en esta ubicación. Usando la directiva `root /data/www`, la solicitud se asigna al archivo `/data/www/about.html`, y el archivo se envía al cliente. El manejo de la solicitud `/` es más complejo. Solo coincide con el prefijo `location /`, por lo que se maneja en esta ubicación. La directiva [index](https://es.angie.software//angie/docs/configuration/modules/http/http_index.md#id1) entonces comprueba la existencia de archivos de índice según sus parámetros y la directiva `root /data/www`. Si el archivo `/data/www/index.html` no existe pero el archivo `/data/www/index.php` sí, la directiva realiza una redirección interna a `/index.php`, y Angie busca las ubicaciones nuevamente como si la solicitud hubiera sido enviada por un cliente. Como se mencionó anteriormente, la solicitud redirigida finalmente será manejada por el servidor FastCGI. ## Proxy y balanceo de carga Uno de los usos más comunes de Angie es configurarlo como servidor proxy. En este rol, Angie recibe solicitudes, las reenvía a los servidores proxied, obtiene las respuestas de esos servidores y las envía de vuelta a los clientes. Un servidor proxy simple: ```nginx server { location / { proxy_pass http://backend:8080; } ``` La directiva [proxy_pass](https://es.angie.software//angie/docs/configuration/modules/http/http_proxy.md#proxy-pass) indica a Angie que pase las solicitudes del cliente al backend `backend:8080` (el servidor proxied). Hay muchas [directivas](https://es.angie.software//angie/docs/configuration/modules/http/http_proxy.md#http-proxy) adicionales disponibles para configurar aún más una conexión proxy. ### Proxy FastCGI Angie puede usarse para enrutar solicitudes a servidores FastCGI que ejecutan aplicaciones desarrolladas con varios marcos y lenguajes de programación, como PHP. La configuración más básica de Angie para trabajar con un servidor FastCGI involucra usar la directiva [fastcgi_pass](https://es.angie.software//angie/docs/configuration/modules/http/http_fastcgi.md#fastcgi-pass) en lugar de la directiva [proxy_pass](https://es.angie.software//angie/docs/configuration/modules/http/http_proxy.md#proxy-pass), junto con directivas [fastcgi_param](https://es.angie.software//angie/docs/configuration/modules/http/http_fastcgi.md#fastcgi-param) para establecer parámetros pasados al servidor FastCGI. Supongamos que el servidor FastCGI es accesible en `localhost:9000`. En PHP, el parámetro `SCRIPT_FILENAME` se utiliza para determinar el nombre del script, y el parámetro `QUERY_STRING` se utiliza para pasar los parámetros de la solicitud. La configuración resultante sería: ```nginx server { location / { fastcgi_pass localhost:9000; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_param QUERY_STRING $query_string; } location ~ \.(gif|jpg|png)$ { root /data/images; } } ``` Esta configuración establece un servidor que enruta todas las solicitudes, excepto aquellas para imágenes estáticas, al servidor proxied que opera en `localhost:9000` a través del protocolo FastCGI. ### Proxy de WebSocket Para actualizar una conexión de HTTP/1.1 a WebSocket, se utiliza el mecanismo de [cambio de protocolo](https://datatracker.ietf.org/doc/html/rfc2616#section-14.42) disponible en HTTP/1.1. Sin embargo, existe una sutileza: dado que la cabecera `Upgrade` es una [cabecera salto a salto](https://datatracker.ietf.org/doc/html/rfc2616#section-13.5.1), no se pasa del cliente al servidor proxy. Con el proxy directo, los clientes pueden usar el método CONNECT para evitar este problema. Este enfoque no funciona con el proxy inverso, ya que los clientes no son conscientes de ningún servidor proxy, y se requiere un procesamiento especial en el servidor proxy. Angie implementa un modo especial de operación que permite establecer un túnel entre un cliente y un servidor proxy si el servidor proxy devuelve una respuesta con código 101 (Switching Protocols), y el cliente solicita un cambio de protocolo mediante la cabecera `Upgrade` en la petición. Como se mencionó, las cabeceras salto a salto, incluyendo `Upgrade` y `Connection`, no se pasan del cliente al servidor proxy. Por lo tanto, para que el servidor proxy sea consciente de la intención del cliente de cambiar al protocolo WebSocket, estas cabeceras deben pasarse explícitamente: ```nginx location /chat/ { proxy_pass http://backend; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; } ``` Un ejemplo más sofisticado demuestra cómo el valor del campo de cabecera `Connection` en una petición al servidor proxy depende de la presencia del campo `Upgrade` en la cabecera de petición del cliente: ```nginx http { map $http_upgrade $connection_upgrade { default upgrade; '' close; } server { ... location /chat/ { proxy_pass http://backend; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection $connection_upgrade; } } } ``` Por defecto, la conexión se cerrará si el servidor proxy no transmite ningún dato en 60 segundos. Este tiempo de espera puede aumentarse usando la directiva [proxy_read_timeout](https://es.angie.software//angie/docs/configuration/modules/http/http_proxy.md#proxy-read-timeout). Alternativamente, el servidor proxy puede configurarse para enviar periódicamente tramas de ping de WebSocket para restablecer el tiempo de espera y comprobar si la conexión sigue activa. ### Balanceo de Carga El balanceo de carga entre múltiples instancias de la aplicación es una técnica ampliamente utilizada para optimizar la utilización de recursos, maximizar el rendimiento, reducir la latencia y garantizar configuraciones tolerantes a fallos. Angie puede emplearse como un balanceador de carga HTTP altamente eficiente para distribuir el tráfico entre varios servidores de aplicaciones, mejorando así el rendimiento, la escalabilidad y la fiabilidad de las aplicaciones web. La configuración más simple para el balanceo de carga con Angie podría verse así: ```nginx http { upstream myapp1 { server srv1.example.com; server srv2.example.com; server srv3.example.com; } server { listen 80; location / { proxy_pass http://myapp1; } } } ``` En el ejemplo anterior, tres instancias de la misma aplicación se ejecutan en `srv1` a `srv3`. Cuando no se configura explícitamente un método de balanceo de carga, el método predeterminado es round-robin. Otros mecanismos de balanceo de carga compatibles incluyen: [weight](https://es.angie.software//angie/docs/configuration/modules/http/http_upstream.md#u-server), [least_conn](https://es.angie.software//angie/docs/configuration/modules/http/http_upstream.md#u-least-conn) y [ip_hash](https://es.angie.software//angie/docs/configuration/modules/http/http_upstream.md#u-ip-hash). La implementación del proxy inverso en Angie también admite sondeos de estado del servidor en banda (o pasivos). Estos se configuran mediante las directivas [max_fails](https://es.angie.software//angie/docs/configuration/modules/http/http_upstream.md#max-fails) y [fail_timeout](https://es.angie.software//angie/docs/configuration/modules/http/http_upstream.md#fail-timeout) dentro del bloque [server](https://es.angie.software//angie/docs/configuration/modules/http/http_upstream.md#u-server) en el contexto [upstream](https://es.angie.software//angie/docs/configuration/modules/http/http_upstream.md#u-upstream). ## Registro #### NOTE Además de las opciones enumeradas aquí, también puede habilitar el [registro de depuración](https://es.angie.software//angie/docs/troubleshooting.md#debug-logging). ### Syslog Las directivas [error_log](https://es.angie.software//angie/docs/configuration/modules/core.md#error-log) y [access_log](https://es.angie.software//angie/docs/configuration/modules/http/http_log.md#access-log) admiten el registro en `syslog`. Los siguientes parámetros se utilizan para configurar el registro en `syslog`: | `server=`address | Especifica la dirección de un servidor `syslog`. La dirección puede ser un
nombre de dominio o una dirección IP, con un puerto opcional, o una ruta de socket de dominio UNIX
especificada después del prefijo `"unix:"`. Si no se especifica el puerto, se utiliza
el puerto UDP 514. Si un nombre de dominio se resuelve a
múltiples direcciones IP, se utiliza la primera dirección resuelta. | |--------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | `facility=`string | Establece la facilidad para los mensajes de `syslog`, como se define en [RFC 3164](https://datatracker.ietf.org/doc/html/rfc3164.html). Las posibles
facilidades incluyen: `"kern"`, `"user"`, `"mail"`,
`"daemon"`, `"auth"`, `"intern"`, `"lpr"`,
`"news"`, `"uucp"`, `"clock"`, `"authpriv"`,
`"ftp"`, `"ntp"`, `"audit"`, `"alert"`,
`"cron"`, `"local0".."local7"`. El valor predeterminado es
`"local7"`. | | `severity=`string | Define el nivel de severidad de los mensajes de `syslog` para
[access_log](https://es.angie.software//angie/docs/configuration/modules/http/http_log.md#access-log), como se especifica en [RFC 3164](https://datatracker.ietf.org/doc/html/rfc3164.html). Los valores posibles
son los mismos que los del segundo parámetro (nivel) de la
directiva [error_log](https://es.angie.software//angie/docs/configuration/modules/core.md#error-log). El valor predeterminado es `"info"`. La severidad
de los mensajes de error es determinada por Angie, por lo que este parámetro se
ignora en la directiva [error_log](https://es.angie.software//angie/docs/configuration/modules/core.md#error-log). | | `tag=`string | Establece la etiqueta para los mensajes de `syslog`. La etiqueta predeterminada es
`"angie"`. | | `nohostname` | Desactiva la adición del campo `hostname` en la cabecera
del mensaje `syslog`. | Ejemplo de configuración syslog: ```nginx error_log syslog:server=192.168.1.1 debug; access_log syslog:server=unix:/var/log/angie.sock,nohostname; access_log syslog:server=[2001:db8::1]:12345,facility=local7,tag=angie,severity=info combined; ```