Nginx: Guia de Configuração, Segurança e Performance

O que é Nginx e para que ele serve?

O Nginx é um software de código aberto capaz de servir páginas e arquivos, intermediar conexões e distribuir tráfego. A própria documentação oficial para iniciantes mostra os papéis mais comuns: conteúdo estático, proxy, FastCGI e gerenciamento do processo.

Isso não significa que todos os projetos precisam ativar todas as funções. Um site institucional pode usá-lo apenas para entregar HTML, CSS e imagens. Uma aplicação Node.js, Java ou Python pode deixá-lo na frente do processo da aplicação. Uma infraestrutura maior pode distribuir solicitações entre várias instâncias.

Como o Nginx processa conexões

O processo principal lê e valida a configuração, enquanto processos workers atendem as conexões. O modelo orientado a eventos permite que um worker lide com várias conexões sem criar um processo separado para cada visitante. É uma arquitetura eficiente, mas o resultado ainda depende do sistema operacional, da aplicação, do banco e da rede.

Quando escolher Nginx

• para publicar um site estático com configuração enxuta;
• para receber HTTPS antes de encaminhar a solicitação à aplicação;
• para aplicar cache, compressão, limites e cabeçalhos em um ponto central;
• para distribuir tráfego entre instâncias de um serviço;
• para hospedar múltiplos domínios na mesma máquina com blocos separados.

Antes de escolher a arquitetura, compare os recursos de uma VPS e de uma hospedagem compartilhada. Em uma hospedagem gerenciada, o provedor pode controlar o servidor web; em uma VPS, a responsabilidade de atualizar, proteger e observar o serviço é sua.

Antes de instalar: prepare o servidor

Comece por uma distribuição suportada, usuário administrativo com sudo, DNS apontado corretamente e portas de rede definidas. Se ainda está escolhendo o sistema, veja as distribuições Linux indicadas para iniciantes. Para uma máquina nova na nuvem, nosso passo a passo de configuração de VPS na AWS ajuda a preparar a base.

Atualize os pacotes, confirme o firewall e mantenha uma sessão SSH aberta enquanto muda regras de rede. Libere somente o necessário: normalmente SSH para administração e HTTP/HTTPS para o site. Não exponha a porta interna da aplicação à internet quando ela só precisa receber tráfego local do Nginx.

Instalação no Ubuntu ou Debian

Para uma instalação estável, você pode usar o repositório da distribuição ou seguir as instruções dos pacotes oficiais do Nginx. O repositório do sistema costuma privilegiar integração e estabilidade; o repositório oficial pode oferecer versões mais recentes. Não misture origens sem entender como as atualizações serão realizadas.

sudo apt update
sudo apt install nginx
sudo systemctl enable --now nginx

Comandos de verificação inicial

nginx -v
sudo nginx -t
systemctl status nginx
curl -I http://127.0.0.1

O teste de sintaxe deve terminar sem erro. O `curl` local separa dois problemas: se a resposta funciona no servidor, mas não de fora, investigue DNS, firewall, grupo de segurança ou roteamento. Se nem localmente funciona, examine o serviço e os logs antes de abrir mais portas.

Como a configuração do Nginx é organizada

O arquivo principal costuma estar em /etc/nginx/nginx.conf. Em Ubuntu e Debian, é comum manter arquivos de sites em sites-available e ativá-los por links em sites-enabled. Outras distribuições preferem um diretório como conf.d. Sempre confirme os caminhos da sua instalação.

Contextos main, events e http

Diretivas fora de um bloco ficam no contexto principal. O bloco events controla aspectos do processamento de conexões. O bloco http reúne configurações do tráfego HTTP, formatos de log, compressão e inclusões de sites. Colocar uma diretiva no contexto errado é uma causa frequente de falha no teste.

Blocos server e location

Cada bloco server descreve um servidor virtual: portas, domínio, certificado e regras. Dentro dele, blocos location selecionam como tratar caminhos da URL. A escolha não é simplesmente “a primeira regra”; prefixos, correspondências exatas e expressões regulares possuem uma ordem própria. Mantenha regras simples e teste URIs reais.

Configure um site estático

server {
    listen 80;
    listen [::]:80;
    server_name exemplo.com www.exemplo.com;

    root /var/www/exemplo/public;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}

O server_name identifica os hosts aceitos, root aponta para o diretório público e try_files procura o recurso solicitado. Evite usar como raiz uma pasta que contenha arquivos de ambiente, backups, chaves ou código que não deve ser baixado.

Ative o site e teste a sintaxe

sudo ln -s /etc/nginx/sites-available/exemplo /etc/nginx/sites-enabled/exemplo
sudo nginx -t
sudo systemctl reload nginx

Se o link já existir, não o recrie. Antes da recarga, revise também permissões e propriedade da pasta. O worker precisa ler arquivos públicos, mas não deve receber permissões de escrita amplas sem necessidade. Depois, confira o domínio, o acesso por IP e um host inexistente para saber qual bloco padrão responde.

Nginx como proxy reverso

Como proxy, o Nginx recebe a solicitação pública e a encaminha a uma aplicação interna. A aplicação pode escutar apenas em 127.0.0.1:3000, enquanto o Nginx atende nas portas 80 e 443. Isso centraliza TLS e políticas de borda, mas não substitui autenticação, validação e segurança dentro da aplicação.

Para um exemplo completo, com detalhes sobre proxy_pass, WebSocket, timeouts e upstreams, consulte nosso guia de proxy reverso com Nginx. Assim, este artigo mantém a visão geral sem competir com o conteúdo especializado.

Cabeçalhos encaminhados à aplicação

location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
}

A aplicação precisa confiar nesses cabeçalhos somente quando vierem de proxies conhecidos. Caso contrário, um cliente pode enviar valores falsos. Também ajuste timeouts de acordo com o comportamento real: valores enormes escondem travamentos; valores curtos demais interrompem operações legítimas.

HTTPS e certificados TLS

HTTPS protege os dados em trânsito e permite que o navegador confirme a identidade do domínio. O módulo SSL do Nginx suporta certificados e protocolos atuais; a documentação oficial de TLS indica TLS 1.2 e TLS 1.3 como protocolos padrão nas versões atuais.

Redirecione HTTP para HTTPS

server {
    listen 80;
    listen [::]:80;
    server_name exemplo.com www.exemplo.com;
    return 301 https://$host$request_uri;
}

O bloco HTTPS deve apontar para os arquivos de certificado e chave fornecidos pela autoridade certificadora. Nunca copie uma chave privada para o diretório público. Garanta que a renovação automática funciona e monitore a validade do certificado, pois uma automação esquecida pode falhar silenciosamente.

Automação com Certbot

O Certbot pode obter e instalar certificados da Let’s Encrypt por meio do plugin do Nginx. Use o método de instalação recomendado para sua distribuição, execute primeiro com um domínio já apontado e valide a renovação. Ferramentas automáticas ajudam, mas você continua responsável por conferir o arquivo resultante e manter cópias seguras da configuração.

Segurança essencial no Nginx

A segurança não vem de uma diretiva isolada. Ela combina atualizações, exposição mínima, privilégios restritos, TLS, limites, logs e uma aplicação segura. Nosso guia de segurança em infraestrutura aprofunda a proteção do sistema, das credenciais e dos dados além do Nginx.

Exposição mínima e permissões

• mantenha o Nginx e o sistema atualizados por um processo previsível;
• não execute workers como root;
• desative listagem de diretórios quando ela não for intencional;
• não publique arquivos ocultos, backups ou diretórios de controle de versão;
• restrinja interfaces administrativas por rede, autenticação e autorização;
• remova sites padrão que não tenham função no ambiente.

Cabeçalhos e limites de requisição

O Nginx pode adicionar cabeçalhos como HSTS, X-Content-Type-Options e políticas de referência. Porém, Content Security Policy e permissões precisam refletir os recursos reais da aplicação. A documentação do módulo de headers também alerta para as regras de herança: declarar um cabeçalho em um nível inferior pode alterar o conjunto herdado.

Limites de tamanho de corpo, conexões ou taxa reduzem abuso e protegem recursos, mas não são uma solução universal contra ataques distribuídos. Defina limites por endpoint, observe falsos positivos e combine-os com controles da aplicação e, quando necessário, proteção na borda.

Performance: cache, compressão e conexões

Antes de ajustar valores, meça. Tempo de resposta alto pode estar no banco, na aplicação ou em uma API externa. O Nginx melhora entrega de estáticos e reduz trabalho repetido, mas não corrige consultas lentas nem algoritmos ineficientes.

Cache de arquivos estáticos

location ~* \.(css|js|png|jpg|jpeg|gif|svg|webp|woff2)$ {
    expires 7d;
    add_header Cache-Control "public";
    try_files $uri =404;
}

Arquivos com nome versionado por hash podem receber cache longo; arquivos substituídos mantendo o mesmo nome precisam de prazo mais conservador ou invalidação. Não aplique cache público a respostas personalizadas, páginas autenticadas ou dados sensíveis.

Compressão Gzip com critério

gzip on;
gzip_vary on;
gzip_min_length 1024;
gzip_types text/plain text/css application/javascript application/json application/xml image/svg+xml;

A compressão reduz a transferência de formatos textuais. Imagens JPEG, PNG e WebP já são comprimidas e normalmente não se beneficiam. A documentação do módulo Gzip também chama atenção para riscos de compressão em respostas protegidas por TLS; por isso, evite configurações indiscriminadas com segredos refletidos.

Não copie ajustes de performance às cegas

Valores de workers, conexões, buffers e timeouts dependem de CPU, memória, limites de arquivos, tamanho das respostas e comportamento do upstream. Aumentar tudo pode consumir memória e ampliar o impacto de clientes lentos. Mude uma variável, meça picos e percentis de latência e mantenha uma forma simples de reverter.

Logs e observabilidade

Access log e error log

O access log mostra solicitações atendidas, status, bytes e tempo, conforme o formato configurado. O error log registra problemas de configuração, conexão com upstream, permissões e recursos. Defina rotação e retenção: logs ilimitados podem preencher o disco, enquanto retenção curta demais elimina evidências necessárias para investigar incidentes.

O que monitorar

• taxa de respostas 4xx e 5xx;
• latência total e tempo de resposta do upstream;
• conexões ativas e recusadas;
• uso de CPU, memória, disco e descritores de arquivo;
• expiração de certificados;
• volume de logs e espaço disponível;
• falhas de recarga e reinícios inesperados.

Deploy e recarga sem indisponibilidade

Uma recarga graciosa faz o processo principal validar a nova configuração e iniciar workers novos, enquanto os antigos terminam conexões em andamento. Isso é diferente de interromper o serviço abruptamente. Ainda assim, uma sintaxe válida não garante comportamento correto: domínio, rota ou cabeçalho podem estar logicamente errados.

Fluxo seguro de alteração

1. salve a configuração em controle de versão sem incluir chaves;
2. revise o diff e confirme o arquivo que será incluído;
3. execute sudo nginx -t;
4. recarregue com sudo systemctl reload nginx;
5. teste a URL pública, o certificado e uma rota inexistente;
6. acompanhe logs, erros e latência;
7. reverta se os indicadores piorarem.

Para entender o caminho completo entre domínio, servidor, build e publicação, consulte também o guia sobre como colocar um site no ar.

Erros comuns ao configurar Nginx

• Recarregar sem testar: uma chave fora de contexto ou ponto e vírgula ausente impede a aplicação.
• Alterar o arquivo errado: o arquivo existe, mas não está incluído ou ativado.
• Criar blocos conflitantes: domínios e portas duplicados levam a respostas inesperadas.
• Usar permissões amplas: resolver um erro com acesso excessivo aumenta o risco.
• Ocultar a aplicação com timeouts enormes: o visitante espera mais, mas a causa continua.
• Ativar cache indiscriminado: conteúdo privado ou desatualizado pode ser entregue ao usuário errado.
• Ignorar logs: tentativas aleatórias substituem o diagnóstico.
• Copiar receitas antigas: diretivas removidas, padrões TLS e pacotes mudam ao longo do tempo.

Checklist para colocar em produção

• DNS aponta para o endereço correto;
• somente portas necessárias estão expostas;
• site padrão foi removido ou configurado de forma intencional;
• raiz pública não contém segredos nem backups;
• HTTPS funciona e a renovação foi testada;
• aplicação interna não está exposta sem necessidade;
• cache e compressão foram medidos;
• logs possuem rotação, retenção e monitoramento;
• nginx -t faz parte do processo de mudança;
• existe backup e procedimento de reversão;
• respostas 404, 413, 429, 500, 502 e 504 foram consideradas;
• o site foi testado em IPv4, IPv6 quando usado, desktop e celular.

Perguntas frequentes

Nginx substitui a aplicação?

Não. Ele pode entregar arquivos e executar funções de borda, mas regras de negócio, autenticação e acesso a dados continuam na aplicação. Pense no Nginx como a recepção e o sistema de encaminhamento, não como o serviço inteiro.

Nginx e Apache podem trabalhar juntos?

Sim. O Nginx pode ficar na frente e encaminhar solicitações para o Apache, embora isso adicione uma camada operacional. Use os dois quando houver uma necessidade concreta de compatibilidade ou migração; não apenas porque a combinação aparece em uma receita.

É preciso reiniciar após cada mudança?

Normalmente, uma recarga graciosa é suficiente para configurações. Sempre execute o teste antes. Reinício completo pode ser necessário em situações específicas, como atualização do binário ou falha do serviço, mas causa mais impacto que uma recarga.

Qual configuração melhora mais a velocidade?

Não existe uma diretiva universal. Para estáticos, cache e compressão costumam ajudar. Para aplicações, reduzir a latência do upstream e do banco pode ser mais importante. Colete uma linha de base, identifique o gargalo e compare o resultado após cada mudança.

Conclusão

Uma boa configuração de Nginx não é a mais longa: é a que atende ao objetivo com poucas regras, limites compreensíveis, HTTPS válido, logs úteis e um processo seguro de mudança.

Comece com um bloco simples, valide cada camada e só adicione cache, proxy ou rate limiting quando houver uma necessidade mensurável.

Em produção, trate o arquivo de configuração como código. Revise alterações, teste a sintaxe, recarregue de modo gracioso, observe o resultado e mantenha uma reversão pronta.

Esse hábito reduz muito mais incidentes do que copiar dezenas de ajustes “otimizados” sem contexto.