Configuração do Nginx que mantém os sites rápidos

Publicado em 19 de setembro de 2026

Um site pode parecer perfeitamente saudável até que um pequeno erro na configuração do Nginx transforme uma implantação rotineira em um erro 502, um aviso de SSL ou um loop de redirecionamento que não leva os visitantes a lugar nenhum útil. O Nginx é rápido e confiável, mas também é rigoroso: uma diretiva no lugar errado pode mudar o comportamento de um site inteiro. A boa notícia é que uma abordagem limpa torna a configuração do Nginx muito menos misteriosa.

Este guia se concentra nas configurações mais importantes ao hospedar sites: blocos de servidor, tratamento de PHP, HTTPS, redirecionamentos, arquivos estáticos, cache e testes seguros. Você não precisa memorizar todas as diretivas do Nginx. Você precisa entender quais decisões afetam seu site e como verificá-las antes que afetem seus visitantes.

Comece com um layout de configuração do Nginx claro

A maioria das instalações Linux separa as configurações globais das configurações de sites individuais. O arquivo principal de configuração, geralmente encontrado em /etc/nginx/nginx.conf, controla processos de trabalho, registro em log, compressão e diretórios de configuração incluídos. Os sites individuais geralmente ficam em um diretório como sites-available, sites-enabled ou conf.d.

Essa separação é útil por um motivo prático: as configurações globais devem ser alteradas com cuidado e raramente, enquanto as configurações no nível do site precisam de atenção regular. Um novo domínio, um site de staging ou uma regra de redirecionamento pertencem ao bloco de servidor desse site, não ao arquivo principal.

Antes de alterar qualquer coisa, identifique a configuração ativa e teste-a:

bash nginx -t

Se o teste for bem-sucedido, recarregue o Nginx sem derrubar conexões ativas:

bash systemctl reload nginx

Use reload para alterações normais de configuração. Às vezes, uma reinicialização completa é necessária, mas ela não deve ser a primeira opção quando você estiver atualizando um host virtual. Pequenos hábitos como esse evitam que uma tarefa de cinco minutos se transforme em um trabalho de recuperação tarde da noite.

Crie um bloco de servidor por site

Um bloco de servidor informa ao Nginx qual domínio ele atende, onde os arquivos do site estão armazenados e como as solicitações devem ser tratadas. Pense nele como a recepção de um site. Quando vários domínios compartilham um servidor, um bloco de servidor organizado é o que mantém o tráfego indo para o lugar certo.

Um site HTTP básico pode ser assim:

server {
    listen 80;
    server_name example.com www.example.com;

    root /var/www/example.com/public;
    index index.php index.html;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }
}

O server_name deve listar todos os nomes de host que você pretende atender. Se os visitantes puderem acessar tanto o domínio raiz quanto www, inclua ambos e depois decida qual deles deve se tornar o canônico por meio de um redirecionamento.

O caminho root deve apontar para o diretório que contém os arquivos web públicos, não necessariamente para a pasta de nível superior do projeto. No WordPress, essa costuma ser a pasta onde existem wp-admin, wp-content e wp-includes. No Laravel e em frameworks semelhantes, normalmente é o diretório public. Apontar o Nginx para a pasta errada pode expor arquivos que nunca deveriam estar disponíveis publicamente.

A regra try_files merece atenção. Ela verifica se um arquivo ou diretório solicitado existe antes de encaminhar solicitações não correspondentes para a aplicação. Isso é essencial para os links permanentes do WordPress e muitas aplicações PHP modernas. Sem isso, as páginas podem funcionar somente quando os visitantes usam a URL completa com index.php anexado. Não é o ideal, e também não é um problema que você queira que os clientes relatem primeiro.

Evite a armadilha do servidor padrão

O Nginx precisa de um servidor padrão para solicitações que não correspondem a um nome de host configurado. Se o site errado estiver definido como padrão, um domínio desconhecido ou uma solicitação direta ao IP poderá exibir o site de outra pessoa. Isso é confuso na melhor das hipóteses e arriscado na pior.

Para servidores com vários sites, use um servidor padrão simples que não retorne conteúdo útil, como uma resposta 404. Mantenha os sites reais em blocos de servidor explícitos com seus próprios valores de server\_name. É um pequeno limite que torna um servidor compartilhado mais fácil de gerenciar.

Configure o PHP sem adivinhações

O Nginx não processa PHP por conta própria. Ele encaminha as solicitações PHP para o PHP-FPM, que executa o código. A conexão normalmente é um socket Unix ou uma porta TCP local.

Um bloco de localização PHP comum é assim:

location ~ \.php$ {
    try_files $uri =404;

    include fastcgi_params;
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;

    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}

A versão do PHP e o caminho do socket variam de servidor para servidor. Se o Nginx retornar um erro 502 Bad Gateway após uma atualização do PHP, o caminho do socket é um dos primeiros lugares a verificar. O PHP-FPM pode estar parado, executando uma versão diferente ou escutando em algum lugar diferente do caminho definido no Nginx.

A linha try_files $uri =404; também vale a pena manter. Ela impede que o Nginx envie solicitações para arquivos PHP inexistentes ao processador PHP. Isso melhora tanto a segurança quanto o tratamento de erros.

No WordPress, evite adicionar regras amplas copiadas de postagens aleatórias em fóruns, a menos que você saiba por que elas são necessárias. O WordPress já funciona bem com uma configuração limpa de try_files, tratamento adequado de PHP e permissões de gravação apenas onde o WordPress precisa delas. Mais regras não significam automaticamente uma configuração melhor.

Faça do HTTPS o caminho padrão

Todo site público deve servir HTTPS e redirecionar o tráfego HTTP para a versão segura. O padrão usual é um bloco de servidor HTTP que executa apenas o redirecionamento, além de um bloco HTTPS separado que serve o site.

server {
    listen 80;
    server_name example.com www.example.com;

    return 301 https://example.com$request_uri;
}

O bloco de servidor HTTPS então escuta na porta 443 e inclui os caminhos do certificado e da chave privada. Os arquivos de certificado dependem de como o SSL é provisionado, mas o princípio permanece o mesmo: mantenha a configuração do certificado dentro do site que o utiliza.

Um redirecionamento 301 permanente é apropriado quando você estiver confiante sobre o destino. Durante uma migração ativa ou um teste de curto prazo, um redirecionamento 302 pode ser mais seguro porque os navegadores não o armazenam em cache de forma tão agressiva. Este é um daqueles casos em que a opção com aparência tecnicamente mais forte nem sempre é a escolha operacional correta.

Escolha também um nome de host preferido. Redirecione www para o domínio raiz ou o domínio raiz para www. Servir ambos sem um redirecionamento consistente pode dividir a análise, criar páginas duplicadas para mecanismos de busca e tornar o comportamento de cookies mais difícil de diagnosticar.

Sirva arquivos estáticos de forma eficiente e segura

Imagens, CSS, JavaScript, fontes e arquivos para download não devem consumir recursos de PHP quando o Nginx pode entregá-los diretamente. Defina um cache de navegador razoável para arquivos que raramente mudam:

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

Trinta dias é um ponto de partida sensato, não uma lei. Se os nomes dos seus arquivos incluírem números de versão ou nomes de arquivo com hash, um cache mais longo pode funcionar muito bem. Se o mesmo nome de arquivo for substituído com frequência, um cache longo pode fazer com que os visitantes vejam um design ou script mais antigo. O cache é sempre um acordo entre velocidade e a rapidez com que as mudanças precisam aparecer.

Não exponha arquivos ocultos por acidente. Uma regra simples pode bloquear solicitações para arquivos ocultos, permitindo ao mesmo tempo o diretório .well-known usado pela validação de certificados:

location ~ /\.(?!well-known(?:/|$)) {
    deny all;
}

Dependendo da configuração do seu certificado, você pode precisar de uma exceção específica para .well-known. Teste o comportamento de renovação depois de tornar as regras de acesso mais rígidas. As regras de segurança devem reduzir a exposição, não interromper silenciosamente serviços dos quais você depende.

Use cabeçalhos de segurança com contexto

Os cabeçalhos de resposta podem melhorar a proteção no lado do navegador, mas precisam de testes. Exemplos comuns incluem X-Content-Type-Options nosniff, Referrer-Policy e Content-Security-Policy. O último é poderoso e fácil de configurar incorretamente. Uma política rígida pode bloquear scripts, fontes, widgets de pagamento, análise ou conteúdo incorporado se for introduzida sem entender as dependências do site.

Comece com cabeçalhos que tenham um propósito claro e baixo risco, depois adicione uma política de segurança de conteúdo no modo somente relatório se sua aplicação oferecer suporte a isso. O objetivo não é reunir uma pilha impressionante de diretivas. O objetivo é reduzir o risco real sem quebrar as páginas que as pessoas precisam usar.

A limitação de taxa também pode ajudar com tráfego abusivo e ataques de login, especialmente para endpoints de login do WordPress. Mas limites agressivos podem bloquear usuários legítimos atrás de redes de escritório compartilhadas ou operadoras móveis. Revise os logs e ajuste com base nos padrões reais de tráfego, em vez de escolher números que apenas pareçam rígidos.

Teste as mudanças como se fossem importantes

Toda mudança no Nginx deve seguir a mesma rotina curta: faça backup ou copie o arquivo atual, faça uma alteração focada, execute nginx -t, recarregue o Nginx e teste o site a partir de um navegador e da linha de comando. Verifique o domínio pretendido, o domínio não canônico, HTTP, HTTPS e uma página tratada por PHP.

Quando algo falhar, leia os logs de erro antes de reescrever a configuração. Os logs de acesso e erro do Nginx frequentemente revelam se o problema é um arquivo ausente, uma permissão incorreta, uma conexão upstream com falha ou um redirecionamento incorreto. Adivinhar pode criar três novos problemas sem corrigir nenhum.

Um painel de controle pode eliminar grande parte desse trabalho manual ao criar e organizar configurações no nível do site, certificados, versões de PHP e logs em um só lugar. O FASTPANEL foi projetado para esse meio-termo prático: você mantém o controle do seu ambiente de hospedagem sem transformar cada mudança de domínio em um projeto de arqueologia de configuração.

Uma boa configuração do Nginx não tem a ver com criar o arquivo mais longo ou usar todas as diretivas disponíveis. Trata-se de tornar cada site previsível: o domínio certo chega aos arquivos certos, o PHP tem um upstream saudável, o HTTPS é imposto, o conteúdo estático é eficiente e as alterações são testadas antes que os visitantes as encontrem. Quando essa base está pronta, gerenciar um servidor em crescimento se torna muito menos dramático - exatamente como deve ser.