Explorar as nuances da configuração do Nginx é essencial para qualquer administrador de sistemas ou desenvolvedor web. Este guia aborda desde a resolução de problemas comuns e a gestão de prioridades em configurações complexas, até a implementação de otimizações de desempenho e medidas de segurança robustas. Serão detalhadas as estratégias para ajustar o Nginx em cenários de alta demanda e para mitigar ameaças comuns no ambiente web.

Questões Frequentes

Prioridade de Hosts Virtuais com Múltiplos server_name

Quando múltiplos blocos server possuem o mesmo server_name e a mesma porta, o Nginx processa os arquivos de configuração na ordem em que são carregados. Geralmente, isso segue a ordem alfabética dos nomes dos arquivos. Por exemplo, se houver site1.conf e site2.conf com configurações idênticas para o mesmo domínio, site1.conf será priorizado. O Nginx emitirá um aviso durante a inicialização sobre entradas duplicadas.

Precedência de Correspondência de location

A diretiva location no Nginx define como as requisições são tratadas e sua precedência é crucial para o roteamento correto:

• =: Coincidência exata de URI. Tem a maior prioridade. Se uma correspondência for encontrada, o processamento para.
• ^~: Coincidência de prefixo. Se o URI começar com o prefixo dado e este prefixo for o mais longo, a correspondência é considerada não-regex e priorizada sobre regex.
• ~ e ~*: Correspondência de expressão regular. ~ é case-sensitive, enquanto ~* é case-insensitive. Possuem menor prioridade que as correspondências de prefixo não-regex.
• Nenhuma das anteriores (apenas um prefixo): Correspondência de prefixo simples. Se várias coincidências de prefixo existirem, a mais longa é usada.

Utilização da Diretiva try_files

A diretiva try_files permite ao Nginx verificar a existência de arquivos ou diretórios em uma ordem específica e, se nenhum for encontrado, redirecionar internamente a requisição. Um exemplo comum é servir arquivos estáticos e, se não existirem, rotear para um arquivo de índice de fallback:

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

Aqui, $uri represetna o caminho da requisição do usuário (e.g., /pagina.html). $uri/ testa se um diretório com esse nome existe (e.g., /meu-diretorio/). Se nem o arquivo nem o diretório existirem, a requisição é internamente redirecionada para /index.html.

Diferenças entre alias e root

Embora ambas as diretivas definam o caminho do sistema de arquivos para onde o Nginx buscará recursos, elas funcionam de maneiras distintas:

• root: O caminho especificado pela diretiva root é prefixado ao URI da requisição para formar o caminho completo do arquivo. Se a diretiva location for /assets/ e root for /var/www/static/, uma requisição para /assets/images/logo.png resultará no Nginx buscando por /var/www/static/assets/images/logo.png.

  
  location /assets/ {
      root /var/www/static/;
  }
  
  

• alias: A diretiva alias substitui o caminho da requisição pelo caminho especificado no alias. Se a diretiva location for /data/ e alias for /mnt/storage/, uma requisição para /data/documents/report.pdf fará com que o Nginx procure por /mnt/storage/documents/report.pdf.

  
  location /data/ {
      alias /mnt/storage/;
  }
  
  

Obtendo o Endereço IP Real do Cliente

Para obter o IP real do cliente, especialmente em cenários com proxies reversos ou balanceadores de carga, as seguintes variáveis podem ser utilizadas:

• $remote_addr: Endereço IP do cliente direto ou do último proxy conectado ao Nginx.
• $http_x_forwarded_for: Contém o IP original do cliente e, potencialmente, IPs de proxies intermediários.
• $http_x_real_ip: Um cabeçalho personalizado frequentemente configurado por um proxy para passar o IP real do cliente.

É fundamental configurar o Nginx com a diretiva real_ip_header para confiar em cabeçalhos como X-Forwarded-For ou X-Real-IP e definir set_real_ip_from para as faixas de IP dos proxies confiáveis.

Códigos de Erro Comuns do Nginx

• 413 Request Entity Too Large: Indica que o tamanho do corpo da requisição excede o limite configurado (client_max_body_size). Ajuste este valor no Nginx para permitir uploads maiores.
• 502 Bad Gateway: O Nginx atuou como gateway ou proxy reverso e recebeu uma resposta inválida ou nenhuma resposta do servidor upstream. Geralmente indica um problema com o servidor de backend.
• 504 Gateway Time-out: O Nginx, atuando como proxy, não recebeu uma resposta do servidor upstream dentro do tempo limite especificado. Isso pode ser ajustado com diretivas como proxy_read_timeout.
• 403 Forbidden: Acesso negado a um recurso. Pode ser devido a permissões de arquivo, restrições de IP ou configurações de segurança do Nginx.
• 404 Not Found: O recurso solicitado não foi encontrado no servidor.
• 400 Bad Request: A requisição HTTP enviada pelo cliente é inválida ou malformada.

Otimização de Desempenho

Ferramenta de Teste de Carga ab (ApacheBench)

O ab é uma ferramenta de linha de comando para realizar testes de carga em servidores web. Ele permite medir o desempenho de um servidor HTTP simulando um número configurável de requisições simultâneas ou totais, fornecendo métricas como tempo médio de resposta e taxa de transferência.

Fatores Críticos para Otimização de Desempenho

A performance de um servidor web é multifacetada, dependendo de uma série de componentes:

• Rede: Largura de banda, latência e configurações de rede.
• Sistema Operacional: Otimizações de kernel, configurações de rede (buffers TCP), limites de recursos.
• Servidor Web (Nginx): Configuração de workers, cache, gzip, etc.
• Aplicação: Eficiência do código, otimização de consultas a banco de dados.
• Serviços de Base de Dados e Armazenamento: Desempenho do disco, otimização de consultas e índices.

Ajuste dos Descritores de Arquivo (File Handles)

Em sistemas Linux, "tudo é um arquivo", e cada conexão, arquivo aberto ou recurso de rede consome um descritor de arquivo. O sistema operacional impõe limites para descritores de arquivo por processo e por sistema para evitar esgotamento de recursos. Para aplicações de alta concorrência como o Nginx, é crucial aumentar esses limites:

• Configuração Global do Sistema: Modificando /etc/sysctl.conf e /etc/security/limits.conf.
• Configuração Específica do Nginx: A diretiva worker_rlimit_nofile no nginx.conf ajusta o limite de descritores de arquivo para os processos worker do Nginx. Um valor adequado é essencial para lidar com muitas conexões simultâneas.

# Dentro do bloco principal ou event_context do nginx.conf
worker_rlimit_nofile 65535; # Exemplo: Permite até 65535 descritores por worker

Configuração de Afinidade de CPU

A afinidade de CPU permite vincular processos Nginx worker a CPUs ou núcleos específicos, o que pode reduzir o overhead de troca de contexto e otimizar o uso do cache da CPU. Isso melhora a eficiência em servidores com múltiplos núcleos.

Para configurar, você pode definir manualmente as máscaras de bits para cada worker ou usar a opção auto para que o Nginx gerencie isso automaticamente:

# Para atribuir manualmente workers a núcleos específicos (ex: 2 workers para 2 núcleos)
worker_processes 2;
worker_cpu_affinity 01 10; # Worker 1 usa core 0, Worker 2 usa core 1

# Método recomendado para a maioria dos casos, Nginx detecta e atribui automaticamente
worker_processes auto;
worker_cpu_affinity auto;

Para verificar a afinidade dos processos worker do Nginx com as CPUs, use comandos como ps -eo pid,args,psr | grep [n]ginx. A coluna psr mostra o processador (core) onde o processo está atualmente em execução.

Otimização da Configuração Geral do Nginx

Uma configuração otimizada do Nginx é fundamental para alto desempehno e estabilidade. Abaixo, um exemplo de ajustes comuns:

user  nginx; # Usuário sob o qual os processos worker do Nginx serão executados
worker_processes  auto; # Define o número de processos worker automaticamente (geralmente igual ao número de núcleos da CPU)
worker_cpu_affinity auto; # Ativa a afinidade de CPU automática

error_log  /var/log/nginx/error.log warn; # Define o log de erros e o nível de severidade
pid        /var/run/nginx.pid; # Define o arquivo PID do Nginx

worker_rlimit_nofile 65535; # Aumenta o limite de descritores de arquivo para os workers

events {
    use epoll;  # Usa o método de E/S epoll para lidar com conexões (Linux)
    worker_connections  20480; # Número máximo de conexões simultâneas que um worker pode lidar
}

http {
    include       /etc/nginx/mime.types; # Inclui tipos MIME padrão
    default_type  application/octet-stream; # Tipo MIME padrão para arquivos desconhecidos
    charset utf-8; # Define o conjunto de caracteres padrão

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"'; # Formato do log de acesso

    access_log  /var/log/nginx/access.log  main; # Ativa o log de acesso com o formato 'main'

    sendfile        on; # Permite que o Nginx envie arquivos diretamente do kernel (otimização de E/S)
    tcp_nopush     on; # Recomenda-se para servidores de arquivos estáticos. Envia cabeçalhos e início do arquivo de uma vez.
    #tcp_nodelay on; # Permite o envio de pacotes pequenos imediatamente. Útil para aplicações interativas.
    keepalive_timeout  75; # Tempo limite para conexões keep-alive (em segundos)

    gzip  on; # Ativa a compressão Gzip
    gzip_disable "MSIE [1-6]\."; # Desativa Gzip para versões antigas do IE que não o suportam bem
    gzip_http_version 1.1; # Define a versão HTTP mínima para ativar o Gzip
    gzip_proxied any; # Ativa Gzip mesmo para requisições que passaram por proxy
    gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript; # Tipos MIME a serem comprimidos
    gzip_comp_level 6; # Nível de compressão (1-9, 6 é um bom equilíbrio)
    gzip_vary on; # Adiciona o cabeçalho "Vary: Accept-Encoding"

    include /etc/nginx/conf.d/*.conf; # Inclui arquivos de configuração adicionais do diretório conf.d
}

Segurança do Nginx

Mitigação de Atividades Maliciosas

O Nginx pode ser configurado para proteger contra bots maliciosos, crawlers indesejados e roubo de recursos (hotlinking):

• Proteção Básica contra Hotlinking: Usando o módulo ngx_http_referer_module para permitir acesso a recursos estáticos apenas de domínios específicos.
• Controle de Acesso por IP: O módulo ngx_http_access_module permite bloquear ou permitir IPs específicos ou faixas de IP.
• Módulo ngx_http_secure_link_module: Para proteger recursos com URLs assinadas e tempo de vida limitado, impedindo acesso não autorizado.

Prevenção contra Ataques de Força Bruta

Ataques de força bruta e "crdeential stuffing" são uma ameaça. Embora o Nginx não substitua a segurança da aplicação, ele pode atuar como uma primeira linha de defesa:

• Limitação de Requisições: Utilizar limit_req_zone e limit_req para restringir o número de requisições por IP ou por URL, dificultando tentativas de login repetidas.
• Listas Negras de IP: Bloquear IPs conhecidos por ataques.
• Aumento da Complexidade de Senhas: Uma medida de aplicação que complementa as proteções do Nginx.
• Sistemas de Alerta: Integrar o Nginx com sistemas de monitoramento (e.g., Fail2Ban, Prometheus/Grafana) para detectar e responder a padrões de ataques.

Vulnerabilidades de Upload de Arquivos

É crucial configurar o Nginx para evitar que arquivos maliciosos sejam carregados e executados no servidor. Isso envolve restrições de tipo de arquivo, validação de nomes de arquivo e isolamento do diretório de upload, além de garantir que o Nginx não execute scripts em diretórios de upload.

Estratégias de Segurança contra Injeção SQL

Embora a injeção SQL seja primariamente uma vulnerabilidade da aplicação, o Nginx pode adicionar uma camada extra de proteção. Utilizar módulos de segurança, como o Nginx com o módulo Lua e um Web Application Firewall (WAF) baseado em regras, pode ajudar a detectar e bloquear padrões de requisições que indicam tentativas de injeção SQL.

Atualizações do Nginx e Vulnerabilidades Conhecidas

Manter o Nginx sempre atualizado é uma das práticas de segurança mais importantes. Novas versões frequentemente incluem correções para vulnerabilidades de segurança descobertas, garantindo que o servidor esteja protegido contra explorações conhecidas.