# Conexões, Sessões, Requisições, Logs ## Mecanismos de processamento de conexão O Angie suporta vários métodos de processamento de conexão. A disponibilidade de um método específico depende da plataforma sendo utilizada. Em plataformas que suportam múltiplos métodos, o Angie normalmente seleciona o método mais eficiente automaticamente. No entanto, se necessário, um método de processamento de conexão pode ser explicitamente escolhido usando a diretiva [use](https://pt.angie.software//angie/docs/configuration/modules/core.md#use). Os seguintes métodos de processamento de conexão estão disponíveis: | Método | Descrição | |-------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | `select` | Um método padrão. O módulo de suporte é construído automaticamente em
plataformas que não possuem métodos mais eficientes. As opções de
construção `--with-select_module` e `--without-select_module`
podem ser usadas para forçar a habilitação ou desabilitação da construção
deste módulo. | | `poll` | Um método padrão. O módulo de suporte é construído automaticamente em
plataformas que não possuem métodos mais eficientes. As opções de
construção `--with-poll_module` e `--without-poll_module`
podem ser usadas para forçar a habilitação ou desabilitação da construção
deste módulo. | | `kqueue` | Um método eficiente disponível no FreeBSD 4.1+, OpenBSD 2.9+, NetBSD 2.0,
e macOS. | | `epoll` | Um método eficiente disponível no Linux 2.6+. | | `/dev/poll` | Um método eficiente disponível no Solaris 7 11/99+, HP/UX 11.22+
(eventport), IRIX 6.5.15+, e Tru64 UNIX 5.1A+. | | `eventport` | O método `event ports` está disponível no Solaris 10+. (Devido a
problemas conhecidos, é recomendado usar o método `/dev/poll` em
seu lugar.) | ## Processamento de requisições HTTP Uma requisição HTTP passa por uma série de fases, onde um tipo específico de processamento é realizado em cada fase. | `Post-read` | A fase inicial. O módulo [RealIP](https://pt.angie.software//angie/docs/configuration/modules/http/http_realip.md#http-realip) é
invocado durante esta fase. | |------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | `Server-rewrite` | A fase onde as diretivas do módulo [Rewrite](https://pt.angie.software//angie/docs/configuration/modules/http/http_rewrite.md#http-rewrite),
definidas em um bloco `server` (mas fora de um bloco `location`),
são processadas. | | `Find-config` | Uma fase especial onde um [location](https://pt.angie.software//angie/docs/configuration/modules/http/index.md#location) é selecionado baseado na URI
da requisição. | | `Rewrite` | Similar à fase `Server-rewrite`, mas se aplica às regras
[rewrite](https://pt.angie.software//angie/docs/configuration/modules/http/http_rewrite.md#id4) definidas dentro do bloco location selecionado na
fase anterior. | | `Post-rewrite` | Uma fase especial onde a requisição é redirecionada para um novo location,
como na fase `Find-config`, se sua URI foi modificada durante a
fase `Rewrite`. | | `Preaccess` | Durante esta fase, módulos padrão do Angie como [Limit Req](https://pt.angie.software//angie/docs/configuration/modules/http/http_limit_req.md#http-limit-req) registram seus manipuladores. | | `Access` | A fase onde a autorização do cliente para fazer a requisição é
verificada, normalmente invocando módulos padrão do Angie como
[Auth Basic](https://pt.angie.software//angie/docs/configuration/modules/http/http_auth_basic.md#http-auth-basic). | | `Post-access` | Uma fase especial onde a diretiva [satisfy any](https://pt.angie.software//angie/docs/configuration/modules/http/index.md#satisfy) é
processada. | | `Precontent` | Diretivas de módulos padrão, como [try_files](https://pt.angie.software//angie/docs/configuration/modules/http/index.md#try-files) e
[mirror](https://pt.angie.software//angie/docs/configuration/modules/http/http_mirror.md#id1), registram seus manipuladores durante esta fase. | | `Content` | A fase onde a resposta é normalmente gerada.
Múltiplos módulos padrão do Angie registram seus manipuladores neste estágio,
incluindo [Index](https://pt.angie.software//angie/docs/configuration/modules/http/http_index.md#http-index).
As diretivas [proxy_pass](https://pt.angie.software//angie/docs/configuration/modules/http/http_proxy.md#proxy-pass), [fastcgi_pass](https://pt.angie.software//angie/docs/configuration/modules/http/http_fastcgi.md#fastcgi-pass),
[uwsgi_pass](https://pt.angie.software//angie/docs/configuration/modules/http/http_uwsgi.md#uwsgi-pass), [scgi_pass](https://pt.angie.software//angie/docs/configuration/modules/http/http_scgi.md#scgi-pass) e [grpc_pass](https://pt.angie.software//angie/docs/configuration/modules/http/http_grpc.md#grpc-pass)
também são tratadas aqui.

Os manipuladores são chamados sequencialmente
até que um deles produza a saída. | | `Log` | A fase final, onde o registro da requisição é realizado. Atualmente, apenas o
módulo [Log](https://pt.angie.software//angie/docs/configuration/modules/http/http_log.md#http-log) registra seu manipulador neste estágio
para registro de acesso. | ## Processamento de sessões TCP/UDP Uma sessão TCP/UDP de um cliente passa por uma série de fases, onde um tipo específico de processamento é realizado em cada fase: | `Post-accept` | A fase inicial após aceitar uma conexão do cliente. O módulo [RealIP](https://pt.angie.software//angie/docs/configuration/modules/stream/stream_realip.md#stream-realip) é invocado nesta fase. | |-----------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | `Pre-access` | Uma fase preliminar para verificar o acesso. Os módulos [Set](https://pt.angie.software//angie/docs/configuration/modules/stream/stream_set.md#stream-set) são invocados durante esta fase. | | `Access` | A fase para limitar o acesso do cliente antes do processamento real dos dados.
O módulo [Access](https://pt.angie.software//angie/docs/configuration/modules/stream/stream_access.md#stream-access) é invocado neste estágio. | | `SSL` | A fase onde ocorre a terminação TLS/SSL. O módulo [SSL](https://pt.angie.software//angie/docs/configuration/modules/stream/stream_ssl.md#stream-ssl) é invocado durante esta fase. | | `Preread` | A fase para ler os bytes iniciais de dados no [buffer de preread](https://pt.angie.software//angie/docs/configuration/modules/stream/index.md#s-preread-buffer-size) para permitir que módulos como [SSL Preread](https://pt.angie.software//angie/docs/configuration/modules/stream/stream_ssl_preread.md#stream-ssl-preread) analisem os dados antes do processamento. | | `Content` | Uma fase obrigatória onde os dados são realmente processados, normalmente
envolvendo o módulo [Return](https://pt.angie.software//angie/docs/configuration/modules/stream/stream_return.md#stream-return) para enviar uma
resposta ao cliente.
A diretiva [proxy_pass](https://pt.angie.software//angie/docs/configuration/modules/stream/stream_proxy.md#s-proxy-pass) também é tratada aqui. | | `Log` | A fase final onde o resultado do processamento da sessão do cliente é
registrado. O módulo [Log](https://pt.angie.software//angie/docs/configuration/modules/stream/stream_log.md#stream-log) é invocado nesta
fase. | ## Processamento de requisições ### Seleção de servidor virtual Inicialmente, uma conexão é criada dentro do contexto de um servidor padrão. O nome do servidor pode então ser determinado nas seguintes etapas do processamento da requisição, cada uma das quais está envolvida na seleção da configuração do servidor: - Durante o handshake SSL, antecipadamente, de acordo com o SNI. - Após processar a linha de requisição. - Após processar o campo de cabeçalho `Host`. Se o nome do servidor não for determinado após processar a linha de requisição ou o campo de cabeçalho `Host`, o Angie usará um nome vazio como nome do servidor. Em cada uma dessas etapas, diferentes configurações de servidor podem ser aplicadas. Portanto, certas diretivas devem ser especificadas com cuidado: - No caso da diretiva [ssl_protocols](https://pt.angie.software//angie/docs/configuration/modules/http/http_ssl.md#ssl-protocols), a lista de protocolos é definida pela biblioteca OpenSSL antes que a configuração do servidor seja aplicada de acordo com o nome solicitado através do SNI. Como resultado, os protocolos devem ser especificados apenas para o servidor padrão. - As diretivas [client_header_buffer_size](https://pt.angie.software//angie/docs/configuration/modules/http/index.md#client-header-buffer-size) e [merge_slashes](https://pt.angie.software//angie/docs/configuration/modules/http/index.md#merge-slashes) são aplicadas antes de ler a linha de requisição. Portanto, essas diretivas usam a configuração do servidor padrão ou a configuração do servidor escolhida por SNI. - No caso das diretivas [ignore_invalid_headers](https://pt.angie.software//angie/docs/configuration/modules/http/index.md#ignore-invalid-headers), [large_client_header_buffers](https://pt.angie.software//angie/docs/configuration/modules/http/index.md#large-client-header-buffers) e [underscores_in_headers](https://pt.angie.software//angie/docs/configuration/modules/http/index.md#underscores-in-headers), que estão envolvidas no processamento de campos de cabeçalho de requisição, a configuração do servidor depende adicionalmente de ter sido atualizada de acordo com a linha de requisição ou o campo de cabeçalho `Host`. - Uma resposta de erro é tratada usando a diretiva [error_page](https://pt.angie.software//angie/docs/configuration/modules/http/index.md#error-page) no servidor que está processando a requisição no momento. ### Servidores virtuais baseados em nome O Angie primeiro determina qual servidor deve tratar a requisição. Considere uma configuração simples onde todos os três servidores virtuais escutam na porta 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; # ... } ``` Nesta configuração, o Angie determina qual servidor deve tratar a requisição baseando-se apenas no campo de cabeçalho `Host`. Se o valor deste cabeçalho não corresponder a nenhum nome de servidor ou se a requisição não contiver este campo de cabeçalho, o Angie roteará a requisição para o servidor padrão desta porta. Na configuração acima, o servidor padrão é o primeiro — que é o comportamento padrão do Angie. Também pode ser explicitamente especificado qual servidor deve ser o padrão usando o parâmetro `default_server` na diretiva [listen](https://pt.angie.software//angie/docs/configuration/modules/http/index.md#listen): ```nginx server { listen 80 default_server; server_name example.net www.example.net; # ... } ``` #### NOTE Note que o servidor padrão é uma propriedade do socket de escuta, não do nome do servidor. ### Nomes internacionalizados Nomes de domínio internacionalizados ([IDNs](https://en.wikipedia.org/wiki/Internationalized_domain_name)) devem ser especificados usando uma representação ASCII (Punycode) na diretiva [server_name](https://pt.angie.software//angie/docs/configuration/modules/http/index.md#server-name): ```nginx server { listen 80; server_name xn--e1afmkfd.xn--80akhbyknj4f; # пример.испытание # ... } ``` ### Prevenindo requisições com nomes de servidor indefinidos Se requisições sem o campo de cabeçalho `Host` não devem ser permitidas, um servidor que simplesmente descarta tais requisições pode ser definido: ```nginx server { listen 80; server_name ""; return 444; } ``` Nesta configuração, o nome do servidor é definido como uma string vazia, que corresponde a requisições sem o campo de cabeçalho `Host`. Um código especial não-padrão 444 é então retornado, que fecha a conexão. ### Combinando servidores virtuais baseados em nome e baseados em IP Vamos examinar uma configuração mais complexa onde alguns servidores virtuais escutam em endereços diferentes: ```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; # ... } ``` Nesta configuração, o Angie primeiro testa o endereço IP e a porta da requisição contra as diretivas [listen](https://pt.angie.software//angie/docs/configuration/modules/http/index.md#listen) dos blocos [server](https://pt.angie.software//angie/docs/configuration/modules/http/index.md#server). Em seguida, testa o campo de cabeçalho `Host` da requisição contra as entradas [server_name](https://pt.angie.software//angie/docs/configuration/modules/http/index.md#server-name) dos blocos [server](https://pt.angie.software//angie/docs/configuration/modules/http/index.md#server) que corresponderam ao endereço IP e porta. Se o nome do servidor não for encontrado, a requisição será processada pelo servidor padrão. Por exemplo, uma requisição para `www.example.com` recebida na porta 192.168.1.1:80 será tratada pelo servidor padrão para essa porta — ou seja, pelo primeiro servidor — já que `www.example.com` não está definido para esta porta. Como mencionado anteriormente, um servidor padrão é uma propriedade da porta de escuta, e diferentes servidores padrão podem ser definidos para diferentes portas: ```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; # ... } ``` ### Escolhendo localizações Considere uma configuração simples de site 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; } } ``` O Angie primeiro busca pela `location` de prefixo mais específica dada por strings literais, independentemente da ordem listada. Na configuração acima, a única localização de prefixo é `location /`, que corresponde a qualquer requisição e será usada como último recurso. O Angie então verifica localizações definidas por expressões regulares na ordem em que aparecem no arquivo de configuração. A primeira expressão correspondente para a busca, e o Angie usará essa `location`. Se nenhuma expressão regular corresponder a uma requisição, o Angie usará a `location` de prefixo mais específica encontrada anteriormente. #### NOTE Localizações de todos os tipos testam apenas a parte URI da linha de requisição, excluindo argumentos. Isso ocorre porque argumentos na string de consulta podem ser especificados de várias maneiras, por exemplo: - `/index.php?user=john&page=1` - `/index.php?page=1&user=john` Além disso, strings de consulta podem conter qualquer número de parâmetros: - `/index.php?page=1&something+else&user=john` Agora vamos ver como as requisições seriam processadas na configuração acima: - A requisição `/logo.gif` é primeiro correspondida pelo prefixo `location /` e depois pela expressão regular `.(gif|jpg|png)$`. Portanto, é tratada pela última localização. Usando a diretiva `root /data/www`, a requisição é mapeada para o arquivo `/data/www/logo.gif`, e o arquivo é enviado para o cliente. - A requisição `/index.php` também é inicialmente correspondida pelo prefixo `location /` e depois pela expressão regular `.(php)$`. Consequentemente, é tratada pela última localização, e a requisição é passada para um servidor FastCGI escutando em `localhost:9000`. A diretiva [fastcgi_param](https://pt.angie.software//angie/docs/configuration/modules/http/http_fastcgi.md#fastcgi-param) define o parâmetro FastCGI `SCRIPT_FILENAME` como `/data/www/index.php`, e o servidor FastCGI executa o arquivo. A variável [$document_root](https://pt.angie.software//angie/docs/configuration/modules/http/index.md#v-document-root) é definida com o valor da diretiva `root`, e a variável [$fastcgi_script_name](https://pt.angie.software//angie/docs/configuration/modules/http/http_fastcgi.md#v-fastcgi-script-name) é definida com o URI da requisição, ou seja, `/index.php`. - A requisição `/about.html` é correspondida apenas pelo prefixo `location /`, então é tratada nesta localização. Usando a diretiva `root /data/www`, a requisição é mapeada para o arquivo `/data/www/about.html`, e o arquivo é enviado para o cliente. Tratar a requisição `/` é mais complexo. Ela é correspondida apenas pelo prefixo `location /`, então é tratada por esta localização. A diretiva [index](https://pt.angie.software//angie/docs/configuration/modules/http/http_index.md#id1) então testa a existência de arquivos de índice de acordo com seus parâmetros e a diretiva `root /data/www`. Se o arquivo `/data/www/index.html` não existir mas o arquivo `/data/www/index.php` existir, a diretiva executa um redirecionamento interno para `/index.php`, e o Angie busca as localizações novamente como se a requisição tivesse sido enviada por um cliente. Como mencionado anteriormente, a requisição redirecionada será eventualmente tratada pelo servidor FastCGI. ## Proxy e Balanceamento de Carga Um uso comum do Angie é configurá-lo como um servidor proxy. Nesta função, o Angie recebe requisições, encaminha-as para os servidores proxy, recupera respostas desses servidores e envia as respostas de volta aos clientes. Um servidor proxy simples: ```nginx server { location / { proxy_pass http://backend:8080; } ``` A diretiva [proxy_pass](https://pt.angie.software//angie/docs/configuration/modules/http/http_proxy.md#proxy-pass) instrui o Angie a passar requisições de clientes para o backend `backend:8080` (o servidor proxy). Existem muitas [diretivas](https://pt.angie.software//angie/docs/configuration/modules/http/http_proxy.md#http-proxy) adicionais disponíveis para configurar ainda mais uma conexão proxy. ### Proxy FastCGI O Angie pode ser usado para rotear requisições para servidores FastCGI que executam aplicações construídas com vários frameworks e linguagens de programação, como PHP. A configuração mais básica do Angie para trabalhar com um servidor FastCGI envolve usar a diretiva [fastcgi_pass](https://pt.angie.software//angie/docs/configuration/modules/http/http_fastcgi.md#fastcgi-pass) em vez da diretiva [proxy_pass](https://pt.angie.software//angie/docs/configuration/modules/http/http_proxy.md#proxy-pass), juntamente com diretivas [fastcgi_param](https://pt.angie.software//angie/docs/configuration/modules/http/http_fastcgi.md#fastcgi-param) para definir parâmetros passados para o servidor FastCGI. Suponha que o servidor FastCGI esteja acessível em `localhost:9000`. Em PHP, o parâmetro `SCRIPT_FILENAME` é usado para determinar o nome do script, e o parâmetro `QUERY_STRING` é usado para passar parâmetros de requisição. A configuração resultante seria: ```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 configuração define um servidor que roteia todas as requisições, exceto aquelas para imagens estáticas, para o servidor proxy operando em `localhost:9000` via o protocolo FastCGI. ### Proxy WebSocket Para atualizar uma conexão de HTTP/1.1 para WebSocket, é usado o mecanismo de [troca de protocolo](https://datatracker.ietf.org/doc/html/rfc2616#section-14.42) disponível no HTTP/1.1. No entanto, há uma sutileza: como o cabeçalho `Upgrade` é um [cabeçalho hop-by-hop](https://datatracker.ietf.org/doc/html/rfc2616#section-13.5.1), ele não é passado do cliente para o servidor com proxy. Com proxy direto, os clientes podem usar o método CONNECT para contornar esse problema. Essa abordagem não funciona com proxy reverso, pois os clientes não têm conhecimento de nenhum servidor proxy, e é necessário processamento especial no servidor proxy. O Angie implementa um modo especial de operação que permite configurar um túnel entre um cliente e um servidor com proxy se o servidor com proxy retornar uma resposta com código 101 (Switching Protocols), e o cliente solicitar uma troca de protocolo através do cabeçalho `Upgrade` na requisição. Como mencionado, cabeçalhos hop-by-hop, incluindo `Upgrade` e `Connection`, não são passados do cliente para o servidor com proxy. Portanto, para que o servidor com proxy tenha conhecimento da intenção do cliente de trocar para o protocolo WebSocket, esses cabeçalhos devem ser passados explicitamente: ```nginx location /chat/ { proxy_pass http://backend; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; } ``` Um exemplo mais sofisticado demonstra como o valor do campo de cabeçalho `Connection` em uma requisição para o servidor com proxy depende da presença do campo `Upgrade` no cabeçalho da requisição do 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 padrão, a conexão será fechada se o servidor com proxy não transmitir nenhum dado dentro de 60 segundos. Esse timeout pode ser aumentado usando a diretiva [proxy_read_timeout](https://pt.angie.software//angie/docs/configuration/modules/http/http_proxy.md#proxy-read-timeout). Alternativamente, o servidor com proxy pode ser configurado para enviar periodicamente frames de ping WebSocket para redefinir o timeout e verificar se a conexão ainda está ativa. ### Balanceamento de Carga O balanceamento de carga entre múltiplas instâncias de aplicação é uma técnica amplamente usada para otimizar a utilização de recursos, maximizar o throughput, reduzir a latência e garantir configurações tolerantes a falhas. O Angie pode ser usado como um balanceador de carga HTTP altamente eficiente para distribuir tráfego para múltiplos servidores de aplicação, melhorando assim o desempenho, escalabilidade e confiabilidade de aplicações web. A configuração mais simples para balanceamento de carga com Angie pode parecer assim: ```nginx http { upstream myapp1 { server srv1.example.com; server srv2.example.com; server srv3.example.com; } server { listen 80; location / { proxy_pass http://myapp1; } } } ``` No exemplo acima, três instâncias da mesma aplicação estão executando em `srv1` até `srv3`. Quando um método de balanceamento de carga não é explicitamente configurado, o padrão é round-robin. Outros mecanismos de balanceamento de carga suportados incluem: [weight](https://pt.angie.software//angie/docs/configuration/modules/http/http_upstream.md#u-server), [least_conn](https://pt.angie.software//angie/docs/configuration/modules/http/http_upstream.md#u-least-conn) e [ip_hash](https://pt.angie.software//angie/docs/configuration/modules/http/http_upstream.md#u-ip-hash). A implementação de proxy reverso no Angie também suporta verificações de saúde do servidor in-band (ou passivas). Essas são configuradas usando as diretivas [max_fails](https://pt.angie.software//angie/docs/configuration/modules/http/http_upstream.md#max-fails) e [fail_timeout](https://pt.angie.software//angie/docs/configuration/modules/http/http_upstream.md#fail-timeout) dentro do bloco [server](https://pt.angie.software//angie/docs/configuration/modules/http/http_upstream.md#u-server) no contexto [upstream](https://pt.angie.software//angie/docs/configuration/modules/http/http_upstream.md#u-upstream). ## Logging #### NOTE Além das opções listadas aqui, você também pode habilitar o [log de depuração](https://pt.angie.software//angie/docs/troubleshooting.md#debug-logging). ### Syslog As diretivas [error_log](https://pt.angie.software//angie/docs/configuration/modules/core.md#error-log) e [access_log](https://pt.angie.software//angie/docs/configuration/modules/http/http_log.md#access-log) suportam logging para `syslog`. Os seguintes parâmetros são usados para configurar logging para `syslog`: | `server=`address | Especifica o endereço de um servidor `syslog`. O endereço pode ser um nome de domínio ou um endereço IP, com uma porta opcional, ou um caminho de socket de domínio UNIX especificado após o prefixo `"unix:"`. Se a porta não for especificada, a porta UDP 514 é usada. Se um nome de domínio resolver para múltiplos endereços IP, o primeiro endereço resolvido é usado. | |--------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | `facility=`string | Define a facility para mensagens `syslog`, conforme definido na [RFC 3164](https://datatracker.ietf.org/doc/html/rfc3164.html). As facilities possíveis incluem: `"kern"`, `"user"`, `"mail"`,
`"daemon"`, `"auth"`, `"intern"`, `"lpr"`,
`"news"`, `"uucp"`, `"clock"`, `"authpriv"`,
`"ftp"`, `"ntp"`, `"audit"`, `"alert"`,
`"cron"`, `"local0".."local7"`. O padrão é
`"local7"`. | | `severity=`string | Define o nível de severidade das mensagens `syslog` para
[access_log](https://pt.angie.software//angie/docs/configuration/modules/http/http_log.md#access-log), conforme especificado na [RFC 3164](https://datatracker.ietf.org/doc/html/rfc3164.html). Os valores possíveis
são os mesmos do segundo parâmetro (level) da diretiva
[error_log](https://pt.angie.software//angie/docs/configuration/modules/core.md#error-log). O padrão é `"info"`. A severidade
das mensagens de erro é determinada pelo Angie, então este parâmetro é
ignorado na diretiva [error_log](https://pt.angie.software//angie/docs/configuration/modules/core.md#error-log). | | `tag=`string | Define a tag para mensagens `syslog`. A tag padrão é
`"angie"`. | | `nohostname` | Desabilita a adição do campo `hostname` no cabeçalho da mensagem `syslog`. | Exemplo de configuração 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; ```