Comparativo: Apache vs Nginx para hospedagem WordPress em 2025

Apache e Nginx diferem fundamentalmente no modelo de processamento de requisições: o Apache cria processos ou threads por conexão, enquanto o Nginx usa um loop de eventos assíncrono que permite atender centenas de conexões simultâneas com um único worker. Para hospedagem WordPress, essa diferença impacta diretamente o consumo de RAM, a latência sob carga e a facilidade de configuração de regras de reescrita de URL.

Pré-requisitos para comparar Apache e Nginx no WordPress

• Acesso root ou sudo ao servidor (VPS ou dedicado com Debian 12, Rocky Linux 9 ou AlmaLinux 9)
• WordPress instalado e funcional em pelo menos um dos servidores web
• PHP-FPM 8.2 ou 8.3 configurado como processador FastCGI
• Ferramenta de benchmark instalada: ab (Apache Bench) ou wrk
• Acesso aos logs em /var/log/apache2/ ou /var/log/nginx/
• Conhecimento básico de edição de arquivos de configuração via terminal

Comparativo Apache vs Nginx: arquitetura e modelo de processamento

O modelo de concorrência é o ponto central do comparativo entre Apache e Nginx para WordPress. O Apache, no modo prefork, cria um processo filho para cada conexão recebida. Isso significa que, com 200 usuários simultâneos, o servidor mantém 200 processos ativos na memória. No modo worker ou event, o Apache usa threads, o que melhora a eficiência, mas ainda assim o consumo de RAM cresce de forma linear com o número de conexões.

O Nginx, por outro lado, usa um modelo orientado a eventos baseado em epoll (Linux) ou kqueue (BSD). Um único processo worker pode gerenciar milhares de conexões abertas sem bloquear. Isso torna o Nginx especialmente eficiente para servir arquivos estáticos — imagens, CSS, JavaScript — que representam a maior parte das requisições em um site WordPress típico.

Para entender qual modo o Apache está usando no seu servidor Debian 12 ou Rocky Linux 9, execute:

apachectl -V | grep -i mpm

Server MPM:     event
  threaded:     yes (fixed thread count)
    forked:     yes (variable process count)

O modo event é o padrão nas versões modernas do Apache 2.4 e oferece desempenho significativamente melhor que o prefork para sites com tráfego moderado a alto.

Configuração de permalinks WordPress: .htaccess no Apache vs try_files no Nginx

Uma das diferenças mais práticas no dia a dia de quem administra hospedagem WordPress é o suporte ao .htaccess. O Apache lê e aplica as regras do arquivo .htaccess em cada diretório automaticamente, sem necessidade de reiniciar o serviço. Isso significa que o WordPress pode escrever suas próprias regras de reescrita de URL ao ativar ou desativar plugins, alterar a estrutura de permalinks ou instalar plugins de cache como W3 Total Cache e WP Super Cache.

No Nginx, o arquivo .htaccess simplesmente não existe. Todas as regras de reescrita precisam ser definidas diretamente no bloco de configuração do virtual host, geralmente em /etc/nginx/sites-available/seusite.conf. O bloco mínimo para que os permalinks do WordPress funcionem corretamente no Nginx é:

server {
    listen 80;
    server_name seusite.com.br www.seusite.com.br;
    root /var/www/seusite/public_html;
    index index.php index.html;

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

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

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

Após editar o arquivo, valide a sintaxe e recarregue o Nginx:

nginx -t && systemctl reload nginx

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

A diretiva try_files $uri $uri/ /index.php?$args; é o equivalente funcional das regras de reescrita do WordPress no .htaccess. Sem ela, qualquer URL que não seja a raiz do site retornará erro 404.

Se você precisa redirecionar HTTP para HTTPS no Nginx ou Apache, consulte o guia Como redirecionar um site http para https? para configurar o redirecionamento corretamente em ambos os servidores web.

Consumo de memória RAM: Apache vs Nginx em carga real

O consumo de memória é frequentemente o fator decisivo ao escolher entre Apache e Nginx para WordPress em servidores com recursos limitados. Para medir o uso real de cada servidor, use o comando ps_mem ou analise diretamente com ps:

ps aux --sort=-%mem | grep -E "apache2|nginx" | head -20

Em um servidor com 2 GB de RAM rodando WordPress com tráfego moderado (50 a 100 visitantes simultâneos), o Apache no modo event com PHP-FPM consome tipicamente entre 150 MB e 400 MB dependendo do número de workers configurados. O Nginx na mesma condição costuma operar entre 30 MB e 80 MB para o processo principal, delegando o processamento PHP inteiramente ao PHP-FPM.

É importante entender que o PHP-FPM consome a mesma quantidade de memória independentemente do servidor web utilizado. A diferença real está no processo do servidor web em si. Para verificar o consumo do PHP-FPM separadamente:

ps aux --sort=-%mem | grep php-fpm | awk '{sum += $6} END {print sum/1024 " MB"}'

Para otimizar o Apache no modo event e reduzir o consumo de RAM, edite /etc/apache2/mods-enabled/mpm_event.conf no Debian 12:

StartServers             2
MinSpareThreads         25
MaxSpareThreads         75
ThreadLimit             64
ThreadsPerChild         25
MaxRequestWorkers      150
MaxConnectionsPerChild   0

Para o Nginx, o número de workers deve ser igual ao número de núcleos de CPU disponíveis. Edite /etc/nginx/nginx.conf:

worker_processes auto;
worker_connections 1024;
use epoll;
multi_accept on;

Consulte também as Dicas de Otimização de Servidores Linux para ajustes complementares no sistema operacional que beneficiam tanto o Apache quanto o Nginx.

Quando migrar do Apache para o Nginx no servidor WordPress

A decisão de migrar de servidor web não deve ser tomada com base apenas em benchmarks teóricos. Existem sinais concretos que indicam que o Nginx pode resolver problemas reais no seu ambiente WordPress. Monitore os seguintes indicadores antes de decidir:

• Uso de RAM acima de 80% em horários de pico: se o servidor está constantemente próximo do limite de memória e o Apache é o maior consumidor, o Nginx pode reduzir esse consumo consideravelmente.
• Erros 503 Service Unavailable frequentes: geralmente indicam que o Apache esgotou o limite de MaxRequestWorkers e está rejeitando novas conexões.
• Tempo de resposta alto para arquivos estáticos: o Nginx serve arquivos estáticos diretamente do sistema de arquivos sem passar pelo PHP, o que reduz a latência para imagens, CSS e JS.
• Logs mostrando filas de conexão: verifique com netstat -an | grep :80 | grep WAIT | wc -l — valores acima de 100 indicam gargalo no servidor web.
• Servidor com menos de 1 GB de RAM: o Nginx é a escolha mais adequada para VPS com recursos limitados rodando WordPress.

Por outro lado, mantenha o Apache quando:

• Você usa plugins WordPress que escrevem regras no .htaccess e não tem tempo para traduzir essas regras para o Nginx manualmente.
• O servidor usa módulos Apache específicos como mod_security, mod_rewrite com lógica complexa ou mod_pagespeed.
• A equipe técnica tem mais familiaridade com a sintaxe de configuração do Apache.
• O tráfego é baixo e estável, sem picos de concorrência.

Usando Apache e Nginx juntos: proxy reverso para WordPress

Uma arquitetura popular em servidores WordPress de médio porte é usar o Nginx como proxy reverso na frente do Apache. Nessa configuração, o Nginx escuta na porta 80 e 443, serve arquivos estáticos diretamente e repassa apenas as requisições dinâmicas (PHP) para o Apache, que opera internamente na porta 8080.

Atenção: antes de alterar as portas do Apache, certifique-se de que nenhum outro serviço está usando a porta 8080 com ss -tlnp | grep 8080. Essa mudança derruba temporariamente o site se feita sem planejamento.

Passo 1 — Altere a porta do Apache em /etc/apache2/ports.conf no Debian 12:

Listen 8080

Passo 2 — Atualize o VirtualHost do Apache para escutar na nova porta:

<VirtualHost *:8080>
    ServerName seusite.com.br
    DocumentRoot /var/www/seusite/public_html
    <Directory /var/www/seusite/public_html>
        AllowOverride All
        Require all granted
    </Directory>
</VirtualHost>

Passo 3 — Configure o Nginx como proxy reverso:

server {
    listen 80;
    server_name seusite.com.br www.seusite.com.br;

    location ~* \.(jpg|jpeg|png|gif|ico|css|js|woff2|svg)$ {
        root /var/www/seusite/public_html;
        expires 30d;
        access_log off;
    }

    location / {
        proxy_pass http://127.0.0.1:8080;
        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;
    }
}

Passo 4 — Reinicie ambos os serviços:

systemctl restart apache2 && systemctl restart nginx

Nessa arquitetura, o WordPress continua usando o .htaccess normalmente (gerenciado pelo Apache), enquanto o Nginx cuida da eficiência no tráfego de entrada e na entrega de arquivos estáticos.

Benchmark prático: testando desempenho com Apache Bench

Para validar qual configuração oferece melhor desempenho no seu ambiente específico, use o ab (Apache Bench) para simular carga real. Instale no Debian 12 ou AlmaLinux 9:

apt install apache2-utils -y   # Debian/Ubuntu
dnf install httpd-tools -y     # AlmaLinux/Rocky Linux

Execute um teste com 500 requisições e 50 conexões simultâneas contra a página inicial do WordPress:

ab -n 500 -c 50 -H "Accept-Encoding: gzip" https://seusite.com.br/

Requests per second:    142.38 [#/sec] (mean)
Time per request:       351.214 [ms] (mean)
Transfer rate:          1823.45 [Kbytes/sec] received
Failed requests:        0

Compare os resultados entre Apache puro, Nginx puro e a configuração de proxy reverso. Os campos mais relevantes são Requests per second (maior é melhor) e Failed requests (deve ser zero). Execute o teste pelo menos três vezes e calcule a média para evitar variações causadas por cache de sistema operacional.

Problemas comuns e como resolver

Sintoma: Permalinks do WordPress retornam erro 404 no Nginx

Causa: A diretiva try_files está ausente ou incorreta no bloco location / do arquivo de configuração do Nginx. Sem ela, o Nginx tenta encontrar um arquivo físico correspondente à URL e, não encontrando, retorna 404.
Solução: Adicione try_files $uri $uri/ /index.php?$args; dentro do bloco location / { } e execute nginx -t && systemctl reload nginx. Verifique também se o arquivo index.php existe no root configurado.

Sintoma: Apache retorna erro 503 em horários de pico

Causa: O parâmetro MaxRequestWorkers foi atingido. O Apache não consegue aceitar novas conexões e retorna 503 para os visitantes excedentes. Isso é comum em VPS com 1 ou 2 GB de RAM com configurações padrão.
Solução: Aumente gradualmente o valor de MaxRequestWorkers em /etc/apache2/mods-enabled/mpm_event.conf, mas monitore o uso de RAM após cada ajuste com free -h. Alternativamente, migre para Nginx ou implemente a arquitetura de proxy reverso descrita acima.

Sintoma: IP real do visitante aparece como 127.0.0.1 nos logs do Apache com proxy reverso

Causa: Quando o Nginx repassa a requisição para o Apache na porta 8080, o Apache registra o IP do Nginx (127.0.0.1) em vez do IP real do visitante.
Solução: Ative o módulo remoteip no Apache e configure-o para confiar no proxy local. No Debian 12: a2enmod remoteip. Em seguida, adicione ao VirtualHost: RemoteIPHeader X-Forwarded-For e RemoteIPInternalProxy 127.0.0.1. Reinicie o Apache após a alteração.

Sintoma: Plugin de cache WordPress não funciona corretamente no Nginx

Causa: Plugins como W3 Total Cache e WP Super Cache escrevem regras no .htaccess para servir páginas em cache diretamente, sem passar pelo PHP. No Nginx, essas regras são ignoradas.
Solução: Configure o plugin de cache para o modo compatível com Nginx. No W3 Total Cache, selecione "Disk: Enhanced" e copie manualmente as regras geradas pelo plugin para o arquivo de configuração do Nginx. O WP Super Cache tem uma seção específica com as regras Nginx prontas para copiar.

Perguntas frequentes sobre Apache e Nginx para WordPress

Apache ou Nginx é melhor para WordPress?

Depende do cenário. O Apache oferece suporte nativo ao .htaccess, o que facilita a configuração de permalinks e regras de reescrita no WordPress sem alterar arquivos do servidor. O Nginx exige que essas regras sejam definidas manualmente no bloco de configuração do site, mas em contrapartida consome menos memória e lida melhor com alto volume de requisições simultâneas.

Nginx consome menos memória que o Apache?

Sim. O Nginx usa um modelo orientado a eventos com workers assíncronos, o que significa que um único processo pode atender centenas de conexões simultâneas sem criar novos processos ou threads. O Apache no modo prefork cria um processo filho por conexão, o que eleva o consumo de RAM em ambientes com muitos acessos concorrentes. No modo event, o Apache melhora esse comportamento, mas o Nginx ainda tende a ser mais eficiente em memória para o processo do servidor web em si.

Posso usar Apache e Nginx juntos no mesmo servidor?

Sim, é uma configuração comum chamada de proxy reverso: o Nginx fica na frente recebendo todas as requisições HTTP/HTTPS e repassa para o Apache na porta 8080 ou outra porta interna. Essa arquitetura combina a flexibilidade do .htaccess do Apache com a eficiência do Nginx para servir arquivos estáticos e gerenciar conexões. É uma solução válida quando você precisa manter compatibilidade com plugins que dependem do .htaccess sem abrir mão da performance do Nginx.

O WordPress funciona sem .htaccess no Nginx?

Funciona, mas requer configuração manual. No Nginx, você precisa adicionar a diretiva try_files $uri $uri/ /index.php?$args; no bloco de configuração do site para que os permalinks do WordPress funcionem corretamente. Sem essa linha, todas as URLs que não sejam a raiz retornarão erro 404. Plugins que dependem de regras no .htaccess também precisam ter suas regras traduzidas manualmente para a sintaxe do Nginx.

Quando devo migrar do Apache para o Nginx no meu servidor WordPress?

Considere migrar quando o servidor apresentar uso de memória RAM acima de 80% em horários de pico, quando o número de conexões simultâneas causar lentidão perceptível, ou quando você precisar servir muitos arquivos estáticos como imagens, CSS e JS com alta eficiência. Em sites com tráfego baixo e uso intenso de plugins que dependem de .htaccess, o Apache pode ser a escolha mais simples de manter. Avalie sempre o perfil real de tráfego do seu site antes de migrar.

Conclusão

• Escolha o Nginx se o servidor tem menos de 2 GB de RAM, recebe picos de tráfego simultâneo ou precisa servir muitos arquivos estáticos com eficiência — configure a diretiva try_files corretamente para garantir que os permalinks do WordPress funcionem.
• Mantenha o Apache se você depende de plugins que escrevem no .htaccess, usa módulos específicos do Apache ou prefere uma configuração mais simples de gerenciar sem editar arquivos de configuração do servidor a cada mudança no WordPress.
• Considere o proxy reverso (Nginx na frente do Apache) como o melhor dos dois mundos em servidores com tráfego moderado a alto: você mantém a compatibilidade com .htaccess e ganha eficiência na entrega de conteúdo estático e no gerenciamento de conexões.

Leia também

• Nginx vs Apache: Qual é o Melhor para Hospedagem Linux em 2026?
• Nginx vs Apache vs LiteSpeed: Melhor Escolha para 2026
• Como Instalar e Configurar o Nginx como Servidor Web no VPS Linux

Precisa de ajuda com Apache ou Nginx no seu servidor?

Configurar e otimizar servidores web para WordPress exige atenção a detalhes que variam conforme o volume de tráfego, os plugins utilizados e os recursos disponíveis. Um VPS bem configurado pode fazer diferença real no desempenho e na estabilidade do seu site.

Conheça os planos de VPS da AviraHost e comece com o servidor certo para o seu WordPress