Nginx versus Apache 2: diferenças, arquitetura, desempenho e qual escolher

Nginx e Apache: entendendo os dois servidores web

Quando alguém acessa um site, o servidor web recebe requisições HTTP ou HTTPS e entrega o conteúdo ao navegador. Dois dos servidores mais utilizados são o Nginx e o Apache HTTP Server 2.4. Ambos hospedam sites, aplicações e APIs, mas diferem na arquitetura, no processamento de conexões, na configuração e no consumo de recursos.

O Nginx utiliza uma arquitetura orientada a eventos. O Apache trabalha com diferentes modelos de processamento chamados MPMs. Essas diferenças influenciam a escolha da solução para cada infraestrutura.

O que é um servidor web?

Um servidor web recebe requisições de navegadores e aplicações e devolve respostas por HTTP ou HTTPS. Pode entregar arquivos HTML, CSS, JavaScript e imagens, encaminhar solicitações para aplicações, atuar como proxy reverso, distribuir tráfego e registrar acessos e erros.

Servidor web não é necessariamente servidor de aplicação. Em sistemas PHP, por exemplo, o servidor web pode encaminhar a solicitação para o PHP-FPM, que executa o código e devolve o resultado.

O que é o Nginx?

O Nginx é um servidor web de código aberto que também pode funcionar como proxy reverso, balanceador de carga e cache HTTP. É utilizado em sites de grande volume, APIs e infraestruturas com vários serviços internos.

Como funciona a arquitetura do Nginx?

O Nginx utiliza um processo principal, chamado master process, que lê e valida configurações, inicia os workers e administra o servidor. Os worker processes atendem conexões e processam requisições.

Os workers utilizam um modelo orientado a eventos. Um mesmo processo pode acompanhar várias conexões sem manter uma thread exclusiva para cada uma. No Linux, um dos mecanismos utilizados é o epoll.

                    NGINX
                      |
                Master Process
                      |
          +-----------+-----------+
          |           |           |
       Worker 1    Worker 2    Worker 3
          |           |           |
          +-----------+-----------+
                      |
              Conexões simultâneas
                      |
          +-----------+-----------+
          |           |           |
       Arquivos    PHP-FPM     Backend
       estáticos               externo

Essa arquitetura é interessante para muitas conexões abertas, entrega de arquivos estáticos e encaminhamento de solicitações para aplicações externas. Isso não torna qualquer instalação automaticamente rápida: CPU, memória, rede, armazenamento e backend continuam sendo fatores importantes.

Principais funcionalidades do Nginx

• Servidor HTTP e HTTPS.
• Proxy reverso para aplicações e serviços internos.
• Balanceamento de carga.
• Cache de respostas.
• Entrega de arquivos estáticos.
• Integração com PHP-FPM por FastCGI.
• Proxy para conexões TCP e UDP.

O que é o Apache HTTP Server 2.4?

O Apache HTTP Server é um servidor web de código aberto mantido pela Apache Software Foundation. A série 2.4 é utilizada em hospedagens, servidores Linux, aplicações corporativas e ambientes de desenvolvimento.

Uma característica importante é sua arquitetura modular. Funcionalidades como reescrita de URLs, autenticação, proxy, TLS, compressão e manipulação de cabeçalhos são fornecidas por módulos.

Como funciona a arquitetura do Apache?

O Apache utiliza componentes chamados MPMs (Multi-Processing Modules), que determinam como o servidor aceita conexões, cria processos e distribui o trabalho entre processos e threads.

MPM Prefork

Utiliza vários processos filhos, sem threads. Cada processo pode atender uma conexão por vez. Pode ser necessário quando o ambiente depende de componentes incompatíveis com processamento multithread, mas tende a consumir mais memória em cenários de alta concorrência.

MPM Worker

Utiliza vários processos, cada um com múltiplas threads. Cada thread pode atender uma conexão, compartilhando recursos entre threads do mesmo processo.

MPM Event

É baseado no Worker, mas trata determinadas conexões persistentes, como as mantidas pelo HTTP Keep-Alive, de maneira assíncrona. Isso libera threads de processamento enquanto os clientes aguardam novas solicitações.

O MPM Event é importante nesta comparação: o Apache 2.4 moderno também possui mecanismos eficientes para administrar conexões simultâneas. Não é correto afirmar que o Apache sempre cria um processo ou uma thread exclusiva para cada visitante. O comportamento depende do MPM utilizado.

              APACHE HTTP SERVER
                       |
                Processo principal
                       |
          +------------+------------+
          |            |            |
      Processo 1   Processo 2   Processo 3
          |            |            |
        Threads      Threads      Threads
          +------------+------------+
                       |
                 Requisições HTTP

Principais módulos do Apache

• mod_rewrite: reescrita de URLs e redirecionamentos.
• mod_ssl: conexões HTTPS com TLS.
• mod_proxy: funcionalidades de proxy.
• mod_proxy_fcgi: integração com FastCGI e PHP-FPM.
• mod_headers: manipulação de cabeçalhos HTTP.
• mod_auth_basic: autenticação HTTP Basic.
• mod_deflate: compressão de respostas compatíveis.

Principais diferenças entre Nginx e Apache

Qual tem melhor desempenho?

Não existe um vencedor universal. O resultado depende da aplicação, configuração, hardware, volume de conexões, cache e trabalho executado pelo backend.

Arquivos estáticos

Arquivos estáticos são recursos entregues sem executar a lógica da aplicação, como imagens, CSS, JavaScript, fontes e documentos. O Nginx é bastante utilizado nesse cenário por administrar conexões eficientemente e entregar esses recursos diretamente. O Apache também pode apresentar bom desempenho; armazenamento, cache do sistema operacional, rede e configuração influenciam o resultado.

Aplicações dinâmicas

Quando uma requisição executa PHP, consulta um banco de dados ou chama uma API externa, o tempo total depende também desses componentes. Se uma consulta SQL demora dois segundos, trocar Apache por Nginx não elimina automaticamente esse gargalo.

Muitas conexões simultâneas

O Nginx é adequado para manter muitas conexões abertas com eficiência. O Apache também pode trabalhar com alta concorrência, especialmente com MPM Event. Uma comparação justa deve usar a mesma máquina, aplicação, condições de rede e configurações equivalentes.

Consumo de memória e CPU

O Nginx costuma utilizar pouca memória para administrar muitas conexões, pois não precisa manter uma thread dedicada para cada conexão aberta. No Apache, o consumo depende do MPM. Prefork tende a consumir mais memória em cenários de alta concorrência, enquanto Worker e Event podem reduzir essa diferença.

Para avaliar o ambiente, observe memória dos processos, conexões simultâneas, CPU, requisições por segundo, tempo de resposta e recursos utilizados pelo PHP-FPM e pelo banco de dados.

Como os dois trabalham com PHP?

O PHP-FPM (FastCGI Process Manager) gerencia processos que executam aplicações PHP. Ele separa o servidor HTTP do componente que interpreta o código.

Navegador
   |
Servidor web
   |
PHP-FPM
   |
Aplicação PHP
   |
Banco de dados
   |
Resposta ao navegador

Tanto Nginx quanto Apache podem utilizar PHP-FPM. A diferença está na configuração e no mecanismo usado para encaminhar a requisição.

Nginx com PHP-FPM

# Nginx: /etc/nginx/sites-available/exemplo

server {
    listen 80;
    server_name exemplo.local;

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

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

    location ~ \.php$ {
        try_files $uri =404;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    }

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

O fastcgi_pass define o destino das requisições PHP. O caminho do socket precisa corresponder à instalação real. O try_files evita encaminhar para execução um arquivo PHP inexistente.

Apache com PHP-FPM

# Apache: VirtualHost com PHP-FPM

<VirtualHost *:80>
    ServerName exemplo.local
    DocumentRoot /var/www/exemplo/public

    <Directory /var/www/exemplo/public>
        Require all granted
        AllowOverride None
    </Directory>

    <FilesMatch "\.php$">
        SetHandler "proxy:unix:/run/php/php8.3-fpm.sock|fcgi://localhost/"
    </FilesMatch>
</VirtualHost>

O exemplo pressupõe que os módulos necessários estejam habilitados e que o socket esteja disponível. O caminho pode variar conforme a distribuição e a versão instalada. PHP-FPM é uma opção adequada com os dois servidores; PHP 8.3 não exige um servidor web específico.

O que é o arquivo .htaccess?

O .htaccess permite aplicar determinadas configurações por diretório no Apache, sem alterar diretamente o arquivo principal do servidor. É utilizado para reescrita de URLs, redirecionamentos e controles de acesso, desde que as diretivas sejam permitidas por AllowOverride.

# Apache: .htaccess

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^ index.php [QSA,L]

As condições verificam se o caminho não corresponde a arquivo ou diretório existente. Nesse caso, a requisição é encaminhada ao controlador principal. É necessário habilitar mod_rewrite e permitir as diretivas necessárias.

O Nginx não interpreta arquivos .htaccess. As regras precisam ser convertidas para blocos server e location. Em uma migração, regras de reescrita, bloqueios e redirecionamentos precisam ser reproduzidos na nova configuração.

Proxy reverso

Um proxy reverso recebe requisições externas e as encaminha para aplicações ou servidores internos. O cliente acessa o endereço público sem precisar conhecer diretamente o endereço do serviço interno.

Exemplo com Nginx

# Nginx: proxy reverso para aplicação local

server {
    listen 80;
    server_name app.exemplo.local;

    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;
    }
}

Exemplo com Apache

# Apache: VirtualHost com proxy reverso

<VirtualHost *:80>
    ServerName app.exemplo.local
    ProxyPreserveHost On
    ProxyPass / http://127.0.0.1:3000/
    ProxyPassReverse / http://127.0.0.1:3000/
</VirtualHost>

No Apache, os módulos mod_proxy e mod_proxy_http precisam estar habilitados. Ambos os servidores executam essa função: Nginx com recursos integrados à configuração e Apache por módulos especializados.

Balanceamento de carga

Quando uma aplicação recebe mais requisições do que um único servidor consegue processar, é possível distribuir o tráfego entre diferentes instâncias. Esse processo é chamado de balanceamento de carga.

Balanceamento com Nginx

# Nginx: grupo de servidores de aplicação

upstream aplicacao {
    server 10.0.0.11:8080;
    server 10.0.0.12:8080;
    server 10.0.0.13:8080;
}

server {
    listen 80;
    server_name api.exemplo.local;

    location / {
        proxy_pass http://aplicacao;
    }
}

As requisições são distribuídas entre os servidores configurados, usando por padrão uma estratégia de distribuição entre eles.

Balanceamento com Apache

# Apache: configuração de balanceamento

<Proxy "balancer://aplicacao">
    BalancerMember "http://10.0.0.11:8080"
    BalancerMember "http://10.0.0.12:8080"
    ProxySet lbmethod=byrequests
</Proxy>

<VirtualHost *:80>
    ServerName api.exemplo.local
    ProxyPass / balancer://aplicacao/
    ProxyPassReverse / balancer://aplicacao/
</VirtualHost>

O exemplo pressupõe que os módulos de proxy, balanceamento e método de distribuição estejam disponíveis e habilitados.

Segurança: qual é mais seguro?

Não existe uma resposta universal. A segurança depende das versões, configurações, módulos, permissões do sistema e aplicação hospedada.

• Manter o servidor e suas dependências atualizados.
• Habilitar somente os módulos necessários.
• Configurar HTTPS e TLS adequadamente.
• Evitar expor arquivos de configuração, backups e arquivos internos.
• Aplicar permissões mínimas aos diretórios e arquivos.
• Configurar limites de requisição quando necessário.
• Não exibir erros internos ou informações sensíveis aos visitantes.
• Monitorar logs de acesso e de erro.

O usuário do servidor web não deve receber acesso administrativo ao sistema operacional, ao banco de dados ou a arquivos que não precisa modificar. Arquivos com credenciais, configurações privadas e backups não devem ficar acessíveis pela raiz pública do site.

Instalação do Nginx no Debian e Ubuntu

# Linux: atualizar pacotes
sudo apt update

# Linux: instalar Nginx
sudo apt install nginx

# Linux: verificar serviço
sudo systemctl status nginx

# Linux: habilitar inicialização automática
sudo systemctl enable nginx

# Linux: iniciar serviço
sudo systemctl start nginx

# Linux: consultar versão
nginx -v

# Linux: validar configuração
sudo nginx -t

Depois da instalação, o servidor normalmente estará disponível na porta HTTP 80, desde que firewall e regras de rede permitam o acesso. Após validar a configuração, aplique alterações com sudo systemctl reload nginx.

Instalação do Apache no Debian e Ubuntu

# Linux: atualizar pacotes
sudo apt update

# Linux: instalar Apache
sudo apt install apache2

# Linux: verificar serviço
sudo systemctl status apache2

# Linux: habilitar inicialização automática
sudo systemctl enable apache2

# Linux: iniciar serviço
sudo systemctl start apache2

# Linux: consultar versão
apache2 -v

# Linux: validar configuração
sudo apache2ctl configtest

Se a configuração estiver correta, é possível recarregar o serviço com sudo systemctl reload apache2.

Como descobrir qual MPM o Apache utiliza?

O desempenho e o comportamento do Apache dependem do MPM ativo. Em Debian e Ubuntu, execute:

# Linux: consultar o MPM habilitado
apache2ctl -V | grep -i 'server mpm'

# Linux: listar módulos ativos
apache2ctl -M

O resultado pode indicar event, worker ou prefork. Verifique a compatibilidade dos módulos antes de alterar o MPM.

Como analisar o desempenho?

Uma comparação técnica precisa utilizar testes reproduzíveis. Disponibilize o mesmo arquivo estático nos dois servidores e mantenha iguais as condições de teste. Uma ferramenta possível é o ApacheBench, comando ab.

# Linux: instalar ApacheBench
sudo apt install apache2-utils

# Linux: 1000 requisições, até 50 simultâneas
ab -n 1000 -c 50 http://127.0.0.1/

O comando envia mil requisições, permitindo até cinquenta simultâneas. Compare requisições por segundo, tempo de resposta, taxa de transferência, falhas, CPU e memória. Verifique também se o cliente de teste ou a rede se tornou um gargalo. Um teste curto não basta para decidir uma migração.

É possível utilizar Nginx e Apache juntos?

Sim. Uma arquitetura comum utiliza o Nginx como ponto de entrada das conexões externas e o Apache para atender aplicações específicas.

                    INTERNET
                       |
                     NGINX
                  Proxy reverso
                       |
             +---------+---------+
             |                   |
       Arquivos estáticos      Apache
                                  |
                               PHP-FPM
                                  |
                               Aplicação
                                  |
                              Banco de dados

O Nginx pode entregar imagens, CSS e JavaScript diretamente e encaminhar solicitações dinâmicas para o Apache. Isso pode ser útil quando uma aplicação depende de funcionalidades específicas do Apache. Entretanto, adicionar dois servidores aumenta a complexidade de configuração, manutenção e monitoramento. Não é uma melhoria automática.

Migração de Apache para Nginx

Migrar não consiste apenas em instalar outro servidor e apontar o domínio para ele. Aplicações podem depender de recursos específicos do Apache que precisam ser reproduzidos.

Antes da migração, identifique arquivos .htaccess, regras de reescrita, redirecionamentos, VirtualHosts, módulos utilizados, regras de autenticação, configurações HTTPS, integrações com PHP-FPM, permissões e regras de proxy.

1. Inventariar o ambiente: documentar domínios, diretórios, VirtualHosts, módulos e dependências.
2. Mapear regras: converter regras dos arquivos .htaccess para a configuração Nginx.
3. Preparar o servidor: instalar Nginx e configurar os domínios equivalentes.
4. Configurar PHP-FPM: verificar sockets, permissões e parâmetros FastCGI.
5. Validar HTTPS: configurar certificados e testar conexões.
6. Executar testes: validar páginas, formulários, APIs, redirecionamentos e arquivos estáticos.
7. Comparar resultados: verificar desempenho, logs e comportamento sob carga.
8. Planejar a mudança: trocar o tráfego mantendo uma possibilidade de retorno.

Mantenha cópias dos arquivos originais e não remova o servidor anterior antes de confirmar o funcionamento de todos os recursos.

Problemas comuns e como investigar

Erro 502 Bad Gateway

Indica que o servidor que atua como gateway ou proxy recebeu uma resposta inválida do serviço intermediário. Em uma instalação Nginx com PHP-FPM, causas possíveis incluem PHP-FPM parado, caminho incorreto para o socket FastCGI, permissões inadequadas ou backend encerrando a conexão.

# Linux: verificar PHP-FPM 8.3
sudo systemctl status php8.3-fpm

# Linux: consultar logs do Nginx
sudo tail -n 50 /var/log/nginx/error.log

# Linux: consultar logs do PHP-FPM
sudo journalctl -u php8.3-fpm -n 50

Erro 403 Forbidden

Indica que o acesso ao recurso foi negado. Pode ocorrer por permissões incorretas, regras de autorização, bloqueios de diretório ou ausência de arquivo de índice. Verifique permissões, regras do servidor e logs.

Erro 404 após migração

Uma causa comum é a ausência de conversão das regras de reescrita que estavam em arquivos .htaccess. Verifique blocos location, a diretiva try_files e as rotas da aplicação.

Erro ao recarregar a configuração

Uma diretiva desconhecida, um bloco incompleto ou uma referência incorreta pode impedir o recarregamento. Teste a sintaxe antes:

# Linux: Nginx
sudo nginx -t

# Linux: Apache
sudo apache2ctl configtest

Qual servidor escolher para cada projeto?

Sites institucionais e blogs

O Nginx é uma boa opção para sites com muitos arquivos estáticos ou necessidade de proxy reverso. O Apache também é adequado quando o projeto utiliza .htaccess ou já está integrado a essa infraestrutura.

Aplicações PHP

Os dois atendem aplicações PHP utilizando PHP-FPM. Considere regras de reescrita, compatibilidade, experiência da equipe e arquitetura desejada.

APIs e microsserviços

O Nginx é uma opção interessante como proxy reverso e ponto de entrada para APIs. O Apache também pode desempenhar essa função por meio de módulos.

Hospedagem compartilhada

O Apache é comum em ambientes que dependem de configurações por diretório e arquivos .htaccess. O Nginx também pode ser utilizado, mas as regras normalmente exigem configuração centralizada pelo provedor.

Servidores com poucos recursos

O Nginx pode oferecer vantagens quando existem muitas conexões simultâneas e a memória é limitada. O resultado precisa considerar PHP-FPM, banco de dados, cache e demais serviços.

Vantagens e limitações

Nginx

Vantagens:

• Arquitetura orientada a eventos.
• Administração eficiente de muitas conexões.
• Boa integração com proxy reverso e balanceamento.
• Entrega eficiente de arquivos estáticos.
• Configuração centralizada.
• Integração com PHP-FPM.

Limitações:

• Não interpreta arquivos .htaccess.
• Regras são administradas nos arquivos do servidor.
• Migrações podem exigir conversão de configurações.
• Alguns recursos dependem da edição ou dos módulos disponíveis.

Apache HTTP Server 2.4

Vantagens:

• Arquitetura modular e flexível.
• Suporte a arquivos .htaccess.
• Diferentes MPMs.
• Compatibilidade com aplicações existentes.
• Proxy reverso e balanceamento por módulos.
• Integração com PHP-FPM.

Limitações:

• Consumo de recursos varia conforme MPM e carga.
• Configurações distribuídas podem dificultar manutenção.
• Módulos desnecessários aumentam a complexidade.
• Regras .htaccess exigem atenção à configuração de permissões.

Conclusão: Nginx ou Apache 2.4?

O Nginx e o Apache HTTP Server 2.4 são servidores web maduros, capazes de atender desde sites simples até aplicações complexas. A diferença mais importante está na arquitetura de processamento e na organização das funcionalidades.

O Nginx utiliza um modelo orientado a eventos, adequado para administrar muitas conexões simultâneas, entregar arquivos estáticos e funcionar como proxy reverso. O Apache oferece arquitetura modular, diferentes modelos de processamento e suporte a configurações por diretório.

Também é importante considerar o MPM Event do Apache 2.4. Ele administra conexões persistentes de maneira eficiente. Comparar o Nginx com um Apache configurado de forma inadequada pode produzir conclusões equivocadas.

Para projetos novos que precisam de proxy reverso e entrega eficiente de arquivos, o Nginx é uma opção interessante. Para aplicações que dependem de módulos Apache ou configurações .htaccess, o Apache pode ser mais simples e compatível.

Não existe obrigação de migrar um servidor que já atende bem. Antes de trocar a infraestrutura, identifique o gargalo, faça medições e avalie se a mudança realmente trará benefícios.

Referências técnicas

• Documentação oficial do Nginx - arquitetura, configuração e funcionalidades.
• Nginx Beginner's Guide - processos, arquivos estáticos, proxy e FastCGI.
• Nginx: HTTP Load Balancing - balanceamento de carga.
• Documentação oficial do Apache HTTP Server 2.4 - configuração, módulos e administração.
• Apache MPM Event - modelo Event.
• Apache: arquivos .htaccess - configurações por diretório.
• Apache: Reverse Proxy Guide - proxy reverso.
• PHP-FPM: documentação oficial - gerenciador de processos PHP.