Hospedagem de Vários Sites com Blocos de Servidor Nginx

Os blocos de servidor Nginx são uma abordagem que permite publicar vários domínios ou sites em uma única instalação do Nginx com configurações separadas. Por exemplo, você pode definir diferentes diretórios raiz, arquivos de log, certificados SSL e configurações PHP para example.com, blog.example.com e segundo-site.com na mesma VPS. Em resumo, a solução consiste em criar diretórios separados para cada site, redirecionar os registros DNS do domínio para o endereço IP do servidor, escrever um bloco de servidor separado sob /etc/nginx/sites-available, vincular isso ao diretório sites-enabled, testar a configuração e recarregar o serviço Nginx.

Neste guia, abordaremos o processo de hospedagem de múltiplos sites com blocos de servidor Nginx de maneira adequada para ambientes de produção. O objetivo não é apenas montar uma estrutura funcional; mas, sim, criar um arranjo gerenciável, seguro, rápido, com capacidade de backup e escalável. Compartilharemos etapas práticas especialmente para agências, desenvolvedores, proprietários de e-commerce, empresas que gerenciam várias marcas e administradores de sistemas que operam vários projetos em um único servidor. Se você ainda não possui um servidor, pode conferir as páginas de servidor VPS para seleção de recursos e Registro de Domínio para gerenciamento de domínio.

O que são Blocos de Servidor Nginx?

Os blocos de servidor Nginx são partes de configuração que determinam qual site será direcionado para uma solicitação HTTP ou HTTPS recebida, definidas dentro da configuração do Nginx como um bloco de servidor. Isso é semelhante ao conceito de VirtualHost no Apache. Quando um visitante digita um domínio no navegador, o DNS resolve esse domínio para o endereço IP do servidor. Em seguida, o Nginx verifica o cabeçalho Host da solicitação e executa o bloco de servidor correspondente ao valor de server_name que combina.

Dessa forma, é possível publicar dezenas de sites diferentes no mesmo endereço IP e no mesmo servidor físico ou virtual. Para cada site, é possível definir um diretório raiz separado, logs de acesso, logs de erro, regras de redirecionamento, certificado SSL, política de cache e regras de segurança. Por exemplo, você pode armazenar seu site corporativo em /var/www/corporativo/public, seu blog em /var/www/blog/public e seu ambiente de teste em /var/www/staging/public.

O Nginx é bastante eficiente nesta estrutura, pois sua arquitetura orientada a eventos permite gerenciar altas conexões simultâneas com baixo consumo de recursos. Por essa razão, é frequentemente preferido em ambientes de hospedagem compartilhada, VPS, servidores em nuvem e infraestrutura de aplicativos de alto tráfego. Para que a hospedagem de múltiplos sites funcione de maneira saudável, é fundamental planejar corretamente cada detalhe, desde permissões de arquivo até redirecionamentos de DNS, instalação de SSL e separação de logs.

Quando usar Blocos de Servidor Nginx?

Os blocos de servidor Nginx são usados especialmente quando você precisa gerenciar várias presenças web em um único servidor. Isso pode envolver desde dois pequenos sites corporativos até dezenas de projetos de clientes, subdomínios ou microsserviços. O ponto crítico aqui é a separação lógica de cada projeto.

• Se você deseja publicar vários domínios na mesma VPS.
• Se você deseja redirecionar domínios com e sem www para um único endereço canônico.
• Se você quer associar subdomínios a diferentes pastas ou aplicativos.
• Se você deseja definir um certificado SSL e uma política de segurança separados para cada site.
• Se você deseja acompanhar projetos de clientes com logs separados.
• Se você deseja executar diferentes aplicativos como Laravel, WordPress, HTML estático e Node.js no mesmo servidor.

Por exemplo, é tecnicamente possível que uma agência digital publique 8 sites corporativos de baixo tráfego em uma única VPS de 4 GB de RAM. No entanto, é necessário calcular o tráfego, uso de disco, número de processos PHP, carga do banco de dados e frequência de backup para cada site. Se os projetos recebem tráfego intenso ou se o isolamento de recursos é crítico, deve-se optar por VPS mais robustos, servidores em nuvem ou soluções de hospedagem gerenciadas. Nesse ponto, as opções de Hospedagem Web e Hosting Corporativo podem ser comparadas.

Requisitos Antes de Começar

Neste guia, presumiremos um servidor Linux baseado em Ubuntu ou Debian. Os comandos podem variar ligeiramente dependendo da distribuição; no entanto, a lógica continua a mesma. Antes de realizar qualquer operação em um ambiente de produção, sempre faça um backup. Uma configuração Nginx incorreta pode causar a inacessibilidade temporária de todos os sites.

Preparações técnicas necessárias

• Conta de usuário Linux com privilégios de root ou sudo.
• Serviço Nginx instalado e em execução.
• Pelo menos um domínio apontado para o endereço IP do servidor.
• Portas 80 e 443 abertas no firewall.
• Uma estrutura de diretórios organizada para os arquivos do site.
• Um certificado válido para SSL ou o uso gratuito do Let’s Encrypt.
• Instalação do PHP-FPM para aplicativos baseados em PHP.

No lado do DNS, o registro A direciona o domínio principal para o endereço IPv4, enquanto o registro AAAA, se existir, aponta para o endereço IPv6. Registros CNAME ou A podem ser usados para subdomínios como www. A propagação do DNS geralmente leva de alguns minutos a 24 horas. Ao fazer uma nova instalação, preparar os registros DNS primeiro e, em seguida, passar para a configuração dos blocos de servidor Nginx acelera o processo.

Estrutura de Diretórios Recomendada

Um dos erros mais comuns na hospedagem de múltiplos sites é manter todos os arquivos de forma desorganizada em um único diretório. Embora essa abordagem possa parecer fácil a curto prazo, ela causa uma perda significativa de tempo durante os processos de manutenção, backup e depuração. Uma abordagem melhor é usar um diretório superior separado para cada domínio, e dentro dele, subdiretórios como public, logs, backups.

Uma estrutura de exemplo pode ser planejada assim: /var/www/site1.com/public, /var/www/site1.com/logs, /var/www/site2.com/public e /var/www/site2.com/logs. O valor root do Nginx deve apontar diretamente para o diretório public. Assim, arquivos de aplicação, arquivos sensíveis como .env e backups não ficam acessíveis diretamente pela web.

Você pode colocar um arquivo index.html simples em cada pasta do site como uma página de teste estática. Escrevendo o nome do site dentro, você pode rapidamente verificar qual bloco de servidor está ativo. Em ambientes de produção, a propriedade dessas pastas geralmente é gerida pelo usuário www-data ou por um usuário específico que faz o deployment. Nas permissões de arquivo, 755 para diretórios e 644 para arquivos são suficientes na maioria dos cenários estáticos. Em aplicações que exigem escrita, como o WordPress, áreas como o diretório uploads devem ser avaliadas separadamente.

Passo a Passo para Criar um Bloco de Servidor Nginx

Os passos a seguir são descritos usando o domínio site1.com como exemplo. Você pode repetir o mesmo método para um segundo, terceiro ou mais sites. O ponto crítico é usar valores exclusivos de server_name, root e arquivo de log para cada site.

1. Crie a pasta do site

O primeiro passo é criar o diretório onde os arquivos web estarão. Exemplo: sudo mkdir -p /var/www/site1.com/public. Em seguida, para teste, você pode criar o arquivo /var/www/site1.com/public/index.html e colocar um texto identificável como Esta é a página de teste do site1.com.

Para definir corretamente a propriedade do arquivo, você pode usar o comando sudo chown -R www-data:www-data /var/www/site1.com. Se você estiver realizando implantações com um usuário diferente, ajuste as permissões de grupo de acordo. Em um ambiente de produção, evite permissões 777, onde todos têm permissão de escrita, pois isso pode permitir que invasores abusem dos diretórios de upload.

2. Crie o arquivo do bloco de servidor

A prática comum no Nginx é manter as configurações inativas em /etc/nginx/sites-available e ativá-las com um link simbólico em /etc/nginx/sites-enabled. Exemplo de arquivo: /etc/nginx/sites-available/site1.com.

Um bloco de servidor HTTP simples é escrito assim: server { listen 80; server_name site1.com www.site1.com; root /var/www/site1.com/public; index index.html index.htm; access_log /var/log/nginx/site1.com.access.log; error_log /var/log/nginx/site1.com.error.log; location / { try_files $uri $uri/ =404; } }

Nessa configuração, listen 80 escuta o tráfego HTTP, server_name especifica quais domínios pertencem a esse bloco, root indica onde os arquivos web estão localizados, index define o arquivo padrão. O try_files retorna 404 se não encontrar o arquivo ou diretório solicitado. Para sites estáticos, essa configuração é bastante suficiente.

3. Ative o site

Para ativar a configuração, um link simbólico é criado: sudo ln -s /etc/nginx/sites-available/site1.com /etc/nginx/sites-enabled/site1.com. Esse método é mais saudável do que copiar arquivos, pois você trabalha em um único arquivo de configuração principal. Quando você faz alterações, o arquivo vinculado também é mantido atualizado.

Se você não quiser que a página padrão do Nginx apareça antes do seu site, pode desativar a configuração default. Para isso, o link /etc/nginx/sites-enabled/default pode ser removido. Contudo, certifique-se de que seu próprio bloco de servidor esteja funcionando corretamente antes de fazer isso.

4. Teste a configuração e recarregue o Nginx

Após cada alteração, o comando sudo nginx -t deve ser utilizado para testar a sintaxe. Se o teste for bem-sucedido, o comando sudo systemctl reload nginx recarrega o serviço sem interrupções. O comando reload é geralmente mais seguro que o restart, pois gerencia melhor as conexões ativas.

Se o teste falhar, a mensagem de erro geralmente mostrará o nome do arquivo e o número da linha. Pontos e vírgulas ausentes, chaves incorretas, caminhos de diretório errados ou valores de server_name conflitantes são os problemas mais comuns. O Nginx não deve ser recarregado até que o erro seja resolvido.

Adicionando o Segundo e o Terceiro Site

A beleza de hospedar vários sites é que, após a configuração correta inicial, o processo se torna repetível. Você cria o diretório /var/www/site2.com/public, escreve o arquivo /etc/nginx/sites-available/site2.com, altera os valores de root e log para site2.com, cria um link simbólico e executa o teste do Nginx.

A estrutura simples para o segundo site é assim: server { listen 80; server_name site2.com www.site2.com; root /var/www/site2.com/public; index index.html; access_log /var/log/nginx/site2.com.access.log; error_log /var/log/nginx/site2.com.error.log; location / { try_files $uri $uri/ =404; } }

Usar logs separados para cada site é extremamente valioso na prática. Por exemplo, enquanto um site pode estar recebendo muitos erros 404, o outro pode não ter problemas. Com a estrutura de logs separada, você pode identificar a origem do erro em segundos. Da mesma forma, a análise de tráfego, ataques de bots, links quebrados e problemas de desempenho podem ser monitorados por site.

Configuração de SSL e HTTPS

Nos padrões de SEO de 2026, HTTPS não é apenas um recurso de segurança, mas também um indicador de confiança do usuário e qualidade técnica. Os navegadores marcam sites HTTP como inseguros; em projetos que incluem pagamentos, assinaturas, formulários ou painéis de administração, SSL é obrigatório. Ao hospedar múltiplos sites, cada domínio deve ter o certificado correto configurado. Para suas necessidades de SSL, você pode conferir a página de certificados SSL no Hostragons.

Se você estiver usando Let’s Encrypt, pode obter um certificado para cada domínio com o Certbot. No processo de exemplo, o comando certbot --nginx -d site1.com -d www.site1.com detectará a configuração do Nginx e poderá adicionar automaticamente o bloco HTTPS. Contudo, é uma boa prática verificar o arquivo após a edição automática. Redirecionamentos incorretos ou problemas de blocos de servidor duplicados podem ocorrer.

Na configuração de HTTPS, o tráfego na porta 80 é geralmente redirecionado permanentemente para a porta 443. O redirecionamento 301 fornece um sinal de preferência permanente para SEO. Decida se você usará www ou não e unifique todas as variações em um único endereço canônico. Por exemplo, se você optar por usar https://site1.com em vez de https://www.site1.com, redirecione tanto o tráfego HTTP quanto HTTPS www para o endereço sem www. Isso reduz o risco de conteúdo duplicado.

Blocos de Servidor Nginx para Sites PHP e WordPress

Em sites HTML estáticos, a configuração é simples; no entanto, para WordPress, Laravel ou aplicativos PHP personalizados, é necessária a integração com PHP-FPM. Nesse caso, o arquivo index.php é definido e as solicitações PHP são direcionadas para o socket apropriado. Por exemplo, em um Ubuntu, o caminho do socket para PHP 8.3 pode ser /run/php/php8.3-fpm.sock. A versão varia de acordo com o servidor.

Exemplo de lógica baseada em PHP: server { listen 80; server_name wordpress-site.com www.wordpress-site.com; root /var/www/wordpress-site.com/public; index index.php index.html; location / { try_files $uri $uri/ /index.php?$args; } location ~ php$ { include snippets/fastcgi-php.conf; fastcgi_pass unix:/run/php/php8.3-fpm.sock; } }

Para que os links permanentes do WordPress funcionem, a estrutura try_files $uri $uri/ /index.php?$args é crucial. Além disso, devem ser consideradas medidas de segurança como limitação de taxa para xmlrpc.php, wp-login.php e a proibição da execução de PHP no diretório uploads. Se você estiver hospedando muitos sites WordPress na mesma VPS, use um banco de dados separado, um usuário separado e uma política de atualização regular para cada site. Para aqueles que buscam alternativas de hospedagem WordPress, Hospedagem WordPress pode ser uma opção mais gerenciável.

Comparação entre Blocos de Servidor Nginx e VirtualHost Apache

Nginx e Apache alcançam o mesmo objetivo com arquiteturas diferentes. Ambos podem hospedar vários sites em um único servidor. A escolha depende das necessidades do aplicativo, hábitos de gerenciamento e expectativas de desempenho.

Se seu aplicativo depende fortemente de regras .htaccess, o Apache pode parecer mais fácil. No entanto, para tráfego intenso, proxy reverso, cache e fluxos de distribuição modernos, o Nginx é uma escolha forte na maioria dos projetos. Em algumas infraestruturas, o Nginx pode ser usado como proxy reverso, enquanto o Apache atua como servidor de aplicativos de back-end.

Melhores Práticas para Segurança

Hospedar vários sites no mesmo servidor traz vantagens de custo; porém, aumenta a responsabilidade pela segurança. Para que uma vulnerabilidade em um site não afete os outros, devem ser aplicados os princípios de isolamento e de menor privilégio.

• Crie um banco de dados separado e um usuário de banco de dados separado para cada site.
• Limite o diretório raiz da web apenas à pasta public.
• Mantenha backups, .env, .git, arquivos de configuração e SQL fora do acesso web.
• Renove os certificados SSL regularmente e obrigue o redirecionamento para HTTPS.
• Use um firewall como UFW no servidor; abra apenas as portas necessárias.
• Realize atualizações regulares do Nginx e do sistema operacional.
• Mantenha logs de access_log e error_log separados para cada site.
• Adicione restrição de IP ou autenticação adicional aos painéis de administração.
• Evite permissões amplas como 777 em arquivos.

Além disso, é útil adicionar cabeçalhos de segurança básicos. Cabeçalhos como X-Frame-Options, X-Content-Type-Options, Referrer-Policy e Content-Security-Policy podem ser considerados em projetos adequados. No entanto, especialmente o Content-Security-Policy, se mal aplicado, pode bloquear arquivos de script e estilo; por isso, deve ser testado primeiro em um ambiente de testes. Para mais conteúdos sobre segurança, você pode referenciar os artigos sobre Segurança de site.

Considerações de Desempenho e SEO

Os blocos de servidor Nginx não só afetam a publicação, mas também têm impacto na qualidade de desempenho e SEO. Cadeias de redirecionamento incorretas, preferências canônicas erradas, falta de compressão gzip ou brotli, arquivos de log grandes e configurações de cache inadequadas podem diminuir a velocidade do site. Os sinais de experiência de página do Google são centrados no usuário; sites seguros, rápidos e estáveis tendem a ter melhor desempenho.

Primeiramente, defina uma única versão canônica para cada domínio. Faça o redirecionamento de HTTP para HTTPS, de www para o não-www ou vice-versa em um único passo. A cadeia não deve ser: http://site.com para http://www.site.com, depois para https://www.site.com, e depois para https://site.com. Em vez disso, é mais correto ir direto para o alvo com um único 301.

Para arquivos estáticos, cabeçalhos de cache-control podem ser utilizados. Imagens, arquivos CSS e JS podem ser armazenados no navegador por um determinado período. No entanto, para arquivos que mudam com frequência, deve-se usar versionamento no nome do arquivo ou estratégia de query string. A compressão gzip reduz a largura de banda em arquivos de texto como HTML, CSS, JS e JSON. Para sites que recebem muito tráfego, o uso de microcache do Nginx, cache FastCGI ou CDN deve ser considerado. Para necessidades de CDN e acesso global, você pode referenciar conteúdos como O que é CDN.

Gerenciamento de Logs e Monitoramento

No gerenciamento de múltiplos sites, a administração de logs é a chave para resolver problemas. Logs separados mostram claramente em qual site um erro ocorreu. O access_log registra solicitações de visitantes, enquanto o error_log captura erros de configuração, permissões, arquivos não encontrados e upstream. O erro 502 Bad Gateway geralmente está relacionado à conexão do PHP-FPM ou do serviço de back-end. O erro 403 Forbidden pode ser um problema de permissões ou de arquivo index. O erro 404 Not Found pode indicar um problema de caminho de arquivo, reescrita ou um problema de root incorreto após DNS.

Para evitar que os arquivos de log cresçam indefinidamente, a configuração do logrotate deve ser verificada. Em projetos pequenos, a rotação diária ou semanal pode ser suficiente. Em sites com alto tráfego, deve-se usar coleta centralizada de logs, monitoramento de métricas e sistemas de alerta. O uso excessivo do disco pode impedir o Nginx de gravar logs, parar o banco de dados e tornar os sites inacessíveis. Portanto, é prático definir limites de uso de disco.

Erros Comuns e Soluções Rápidas

Ao trabalhar com blocos de servidor Nginx, alguns erros podem aparecer em quase todos os projetos. Conhecê-los pode reduzir significativamente o tempo de configuração.

• O domínio abre o site errado: verifique conflitos de server_name e o bloco de servidor default.
• Erro 403 Forbidden: verifique o diretório raiz, permissões de arquivos e a existência do arquivo index.
• Erro 404 Not Found: revise o caminho root e a regra try_files.
• Erro 502 Bad Gateway: confirme se o serviço PHP-FPM está funcionando e se o caminho do socket está correto.
• O certificado SSL parece pertencer ao site errado: verifique os server_name na porta 443 e os arquivos de certificado.
• Ciclo de redirecionamento: simplifique as regras de redirecionamento HTTP-HTTPS e www.
• Nginx não recarrega: corrija o erro de sintaxe de acordo com o número da linha na saída do sudo nginx -t.

Administradores experientes têm uma lista de verificação simples: o DNS está correto? A configuração do Nginx está ativa? O diretório raiz existe? As permissões estão corretas? O serviço passou no teste? O que os logs dizem? Seguir essa ordem ajuda a encontrar soluções rapidamente, sem entrar em pânico.

Lista de Verificação Prática para Ambientes de Produção

Antes de ir para o ar, verifique cada site com a lista de verificação abaixo. Especialmente em projetos de clientes, documentar esses itens antes da entrega estabelece um padrão de trabalho profissional.

• O registro A ou AAAA do domínio está apontando para o IP correto.
• Uma das versões www ou não-www foi escolhida como canônica.
• O tráfego HTTP é redirecionado para HTTPS com 301.
• O certificado SSL é válido e a renovação automática está ativa.
• Foi definido um root e um arquivo de log separados para cada site.
• A configuração do Nginx foi validada com sudo nginx -t.
• Um plano de backup foi definido e um teste de recuperação foi realizado.
• As permissões de arquivos estão de acordo com o princípio do menor privilégio.
• No firewall, apenas as portas necessárias estão abertas.
• Os logs de erro foram monitorados por pelo menos 15 minutos após a ativação.

Embora essa lista possa parecer pequena, ela reduz significativamente o risco de interrupções em projetos reais. Especialmente os passos de renovação de SSL, verificação de DNS e monitoramento de logs podem detectar a maioria dos erros invisíveis precocemente.

Conclusão

Os blocos de servidor Nginx são uma das principais maneiras de hospedar múltiplos sites de forma organizada, segura e eficiente em um único servidor. Com a estrutura de diretórios correta, arquivos de configuração separados, regras de redirecionamento claras, uso de HTTPS, separação de logs e um processo de teste regular, o gerenciamento de múltiplos sites se torna bastante eficiente. Os mesmos princípios podem ser aplicados desde um pequeno site de portfólio até múltiplos projetos de clientes.

Se você está prestes a lançar um novo projeto, primeiro defina suas necessidades de domínio, recurso de servidor e SSL; em seguida, configure sua estrutura Nginx passo a passo usando a lista de verificação acima. Se você está procurando uma infraestrutura mais gerenciável, pode explorar as soluções de Pacotes de hosting, servidor VPS e certificados SSL do Hostragons para escolher o ponto de partida adequado para o seu projeto.

Perguntas Frequentes

Quantos sites podem ser hospedados com blocos de servidor Nginx?

Tecnicamente, você pode hospedar muitos sites no mesmo servidor com Nginx; o limite geralmente depende da CPU, RAM, disco, tráfego, carga do banco de dados e capacidade do PHP-FPM. Em sites estáticos de baixo tráfego, dezenas de sites podem ser possíveis, enquanto em projetos intensivos como WordPress ou e-commerce, é mais saudável hospedar menos sites.

Cada site precisa de um certificado SSL separado?

Sim, cada domínio ou subdomínio que será publicado via HTTPS deve estar incluído na cobertura do certificado. Podem ser utilizados certificados individuais ou certificados SAN ou wildcard. O importante é que os arquivos de certificado corretos estejam vinculados ao domínio correto no bloco de servidor Nginx na porta 443.

É possível publicar subdomínios com blocos de servidor Nginx?

Sim. Você pode definir server_name separados para subdomínios como blog.site.com ou panel.site.com e direcioná-los para um diretório root diferente ou uma aplicação de back-end diferente. Você precisará criar um registro A ou CNAME para o subdomínio no lado do DNS.

Qual é a diferença entre sites-available e sites-enabled?

sites-available é onde as configurações de servidor disponíveis são mantidas; sites-enabled contém as configurações ativas. Normalmente, faz-se um link simbólico dentro de sites-enabled para os arquivos em sites-available. Esse método torna a ativação e desativação de sites mais organizada.

Se o site errado abrir, de onde vem o problema?

As razões mais comuns incluem o DNS apontando para o IP errado, o valor de server_name estar incorreto, o bloco de servidor default capturando a solicitação ou um bloco SSL incorreto na porta 443. Verifique primeiro os registros DNS, depois a saída do nginx -t, os links ativos em sites-enabled e o arquivo access_log correspondente.