Comparativo: Apache vs Nginx para hospedagem WordPress em 2025

17 min de leitura  ·  Guia técnico

Apache e Nginx diferem fundamentalmente em arquitetura: o Apache usa um modelo baseado em processos ou threads por conexão, enquanto o Nginx adota um modelo assíncrono orientado a eventos. Para hospedagem WordPress em 2025, essa diferença impacta diretamente o consumo de memória RAM, a latência sob carga e a facilidade de configuração de regras de reescrita de URL.

Pré-requisitos para este comparativo

• Acesso root ou sudo a um servidor Linux (Debian 12, Rocky Linux 9 ou AlmaLinux 9)
• WordPress instalado e funcional em pelo menos um ambiente de teste
• PHP-FPM 8.3 configurado (necessário para Nginx; recomendado também com Apache)
• Familiaridade básica com linha de comando e edição de arquivos de configuração
• Conhecimento do conceito de virtual host / server block

Apache vs Nginx: diferenças de arquitetura para WordPress

O Apache HTTP Server existe desde 1995 e dominou o mercado de servidores web por décadas. Sua força para WordPress está no suporte nativo ao arquivo .htaccess, que permite configurações por diretório sem reiniciar o serviço. Isso significa que plugins como WP Super Cache, W3 Total Cache e Yoast SEO podem gravar regras de reescrita automaticamente, sem que o administrador precise editar arquivos globais.

O Nginx (pronuncia-se "engine-x") foi lançado em 2004 com foco em alta concorrência. Seu modelo de worker processes com event loop permite que um único processo atenda centenas de conexões simultâneas sem criar novos processos ou threads. Para WordPress, isso se traduz em menor uso de RAM em picos de tráfego, mas exige que todas as regras de reescrita sejam configuradas manualmente no bloco server do virtual host.

Em termos de MPM (Multi-Processing Module), o Apache oferece três modos principais:

• prefork: um processo filho por conexão — maior compatibilidade, maior consumo de RAM
• worker: threads por processo — equilíbrio entre compatibilidade e desempenho
• event: similar ao worker, mas com tratamento assíncrono de keep-alive — mais próximo do modelo Nginx

Usar o Apache no modo event MPM com PHP-FPM reduz significativamente a diferença de consumo de memória em relação ao Nginx, tornando a comparação mais equilibrada em ambientes modernos.

Configurando Apache para WordPress no Debian 12

O servidor web Apache com mod_rewrite é a combinação mais comum em hospedagens compartilhadas e painéis como cPanel. Para um VPS com Debian 12, a configuração de um virtual host WordPress segue este padrão:

1. Instale o Apache e habilite os módulos necessários
2. Crie o arquivo de virtual host para o domínio
3. Habilite mod_rewrite e AllowOverride para suporte ao .htaccess
4. Ative o virtual host e recarregue o Apache
5. Verifique os permalinks do WordPress no painel administrativo

apt update && apt install apache2 libapache2-mod-php8.3 -y
a2enmod rewrite headers expires deflate

Crie o arquivo de virtual host em /etc/apache2/sites-available/meusite.conf:

<VirtualHost *:80>
    ServerName meusite.com.br
    ServerAlias www.meusite.com.br
    DocumentRoot /var/www/meusite

    <Directory /var/www/meusite>
        AllowOverride All
        Require all granted
        Options -Indexes +FollowSymLinks
    </Directory>

    ErrorLog ${APACHE_LOG_DIR}/meusite_error.log
    CustomLog ${APACHE_LOG_DIR}/meusite_access.log combined
</VirtualHost>

a2ensite meusite.conf
systemctl reload apache2

Output esperado após systemctl reload apache2:

(sem saída — indica sucesso. Verifique com: systemctl status apache2)

Com AllowOverride All, o WordPress pode gravar e ler o .htaccess livremente. O arquivo padrão gerado pelo WordPress para permalinks tem este conteúdo:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Esse bloco é gerado automaticamente pelo WordPress ao salvar as configurações de permalink — nenhuma intervenção manual é necessária no Apache.

Configurando Nginx para WordPress no Rocky Linux 9

O servidor web Nginx exige uma abordagem diferente: todas as regras de reescrita precisam estar no arquivo de configuração do server block. No Rocky Linux 9, a instalação e configuração básica para WordPress segue este fluxo:

dnf install nginx php-fpm php-mysqlnd php-xml php-gd php-mbstring -y
systemctl enable --now nginx php-fpm

Crie o arquivo de server block em /etc/nginx/conf.d/meusite.conf:

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

    # Regra principal de permalink do WordPress
    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    # Processamento de PHP via PHP-FPM
    location ~ \.php$ {
        fastcgi_pass unix:/run/php-fpm/www.sock;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;
    }

    # Bloquear acesso a arquivos sensíveis
    location ~ /\.(ht|git|svn) {
        deny all;
    }

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

    error_log /var/log/nginx/meusite_error.log;
    access_log /var/log/nginx/meusite_access.log;
}

nginx -t && systemctl reload nginx

Output esperado:

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 Nginx das regras de reescrita do .htaccess do WordPress. Sem ela, todas as URLs amigáveis retornam erro 404. Para saber mais sobre como redirecionar tráfego HTTP para HTTPS nessa configuração, consulte o artigo Como redirecionar um site http para https?.

Comparativo de desempenho: consumo de memória e concorrência

A diferença de consumo de recursos entre os dois servidores web fica mais evidente em cenários de alta concorrência. O modelo de processos do Apache (especialmente no modo prefork) aloca memória para cada conexão ativa, enquanto o Nginx mantém um número fixo de worker processes independentemente do número de conexões.

Considere um servidor com 2 GB de RAM rodando WordPress. Em modo prefork com 150 conexões simultâneas, cada processo Apache pode consumir entre 20 MB e 50 MB, dependendo dos módulos carregados. Isso pode esgotar a memória disponível rapidamente. Com o modo event MPM e PHP-FPM, o Apache se comporta de forma muito mais eficiente, delegando o processamento PHP a processos separados.

O Nginx, por padrão, usa um número de workers igual ao número de CPUs disponíveis. Em um servidor com 4 vCPUs, você terá 4 worker processes, cada um capaz de atender milhares de conexões simultâneas via event loop. Para arquivos estáticos (imagens, CSS, JS), o Nginx é especialmente eficiente porque não precisa invocar PHP-FPM.

Resumo prático das diferenças de desempenho:

• Arquivos estáticos: Nginx entrega com menor overhead — sem fork de processo
• Requisições PHP: Com PHP-FPM, ambos têm desempenho similar
• Muitas conexões simultâneas: Nginx consome menos RAM no modo padrão
• Poucas conexões simultâneas: Diferença de RAM é mínima entre os dois
• Configuração de cache: Apache com .htaccess é mais simples para plugins WordPress

Nginx como proxy reverso na frente do Apache

Uma arquitetura híbrida popular combina os pontos fortes de ambos os servidores: o Nginx atua como proxy reverso na porta 80/443, servindo arquivos estáticos diretamente e repassando requisições PHP ao Apache, que escuta internamente na porta 8080.

Essa configuração permite manter a compatibilidade com .htaccess e plugins WordPress que dependem do Apache, enquanto o Nginx absorve o tráfego de arquivos estáticos com alta eficiência. Para implementar, configure o Apache para escutar apenas em localhost:

# Em /etc/apache2/ports.conf
Listen 127.0.0.1:8080

E no server block do Nginx, adicione o bloco de proxy:

server {
    listen 80;
    server_name meusite.com.br;

    # Servir estáticos diretamente
    location ~* \.(jpg|jpeg|png|gif|ico|css|js|woff2|svg)$ {
        root /var/www/meusite;
        expires 30d;
    }

    # Repassar tudo mais ao Apache
    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;
    }
}

Atenção: ao usar proxy reverso, certifique-se de que o WordPress detecta corretamente o protocolo HTTPS. Adicione ao wp-config.php:

if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
    $_SERVER['HTTPS'] = 'on';
}

Para uma visão mais ampla sobre como estruturar seu ambiente de hospedagem, o artigo Configurando um Servidor Linux para Hospedagem de Sites cobre os fundamentos de configuração de stack completa.

Segurança: hardening do Apache e Nginx para WordPress

Independentemente do servidor web escolhido, algumas configurações de segurança são essenciais para proteger uma instalação WordPress em produção. O hardening básico inclui ocultar a versão do servidor, bloquear acesso a arquivos sensíveis e limitar métodos HTTP.

Para o Apache, adicione ao httpd.conf ou ao virtual host:

ServerTokens Prod
ServerSignature Off

<FilesMatch "^(wp-config\.php|\.htaccess|readme\.html|license\.txt)$">
    Require all denied
</FilesMatch>

<LimitExcept GET POST HEAD>
    Require all denied
</LimitExcept>

Para o Nginx, adicione ao bloco server:

server_tokens off;

# Bloquear acesso ao wp-config.php
location = /wp-config.php {
    deny all;
}

# Bloquear xmlrpc.php se não for necessário
location = /xmlrpc.php {
    deny all;
    return 444;
}

# Bloquear upload de arquivos PHP em wp-content
location ~* /wp-content/uploads/.*\.php$ {
    deny all;
}

Após qualquer alteração no Nginx, sempre valide a sintaxe antes de recarregar:

nginx -t && nginx -s reload

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 server block. O Nginx não lê .htaccess, então as regras de reescrita do WordPress precisam estar explicitamente no arquivo de configuração.
Solução: Certifique-se de que o bloco location / contém exatamente try_files $uri $uri/ /index.php?$args;. Após editar, execute nginx -t && systemctl reload nginx e limpe o cache do WordPress.

Sintoma: Apache retorna erro 500 após ativar plugin de cache

Causa: O plugin gravou regras no .htaccess que contêm sintaxe inválida ou incompatível com a versão do Apache, ou o diretório não tem permissão de escrita para o usuário do servidor web.
Solução: Verifique o log de erros com tail -f /var/log/apache2/meusite_error.log. Se o problema for permissão, ajuste com chown www-data:www-data /var/www/meusite/.htaccess. Se for sintaxe, desative o plugin, restaure o .htaccess padrão do WordPress e reative o plugin.

Sintoma: Nginx não processa PHP — retorna o código-fonte do arquivo

Causa: O bloco location ~ \.php$ está ausente, comentado ou o socket do PHP-FPM está incorreto no arquivo de configuração.
Solução: Verifique se o PHP-FPM está rodando com systemctl status php-fpm e confirme o caminho do socket com ls /run/php-fpm/. Certifique-se de que o valor em fastcgi_pass corresponde ao socket existente. No Rocky Linux 9, o socket padrão é /run/php-fpm/www.sock.

Sintoma: imagens e CSS não carregam após configurar proxy reverso Nginx + Apache

Causa: O Nginx está tentando servir os arquivos estáticos diretamente, mas o root configurado no bloco de estáticos não corresponde ao DocumentRoot real dos arquivos.
Solução: Confirme que o caminho em root no bloco de estáticos do Nginx aponta para o mesmo diretório que o DocumentRoot do Apache. Teste com curl -I http://meusite.com.br/wp-content/themes/meutema/style.css para verificar o código de resposta.

Perguntas frequentes sobre Apache vs Nginx para WordPress

Apache ou Nginx é melhor para WordPress?

Para WordPress, o Nginx geralmente entrega menor latência em sites com alto volume de requisições estáticas, pois seu modelo assíncrono não cria um processo por conexão. O Apache, por outro lado, suporta .htaccess nativamente, o que simplifica configurações de permalink e plugins de cache sem necessidade de editar arquivos do servidor. A escolha ideal depende do seu nível de controle sobre o servidor e do perfil de tráfego do site.

Nginx consome menos memória RAM que o Apache?

Sim, em cenários de muitas conexões simultâneas o Nginx tende a consumir menos RAM porque usa um modelo orientado a eventos com um número fixo de workers, enquanto o Apache no modo prefork cria um processo filho por conexão. Em ambientes com poucos usuários simultâneos a diferença é pequena. Usar o Apache no modo event MPM reduz significativamente essa diferença.

É possível usar Apache e Nginx juntos no mesmo servidor?

Sim, uma arquitetura comum é colocar o Nginx como proxy reverso na porta 80/443 e o Apache escutando em uma porta interna como 8080. O Nginx serve arquivos estáticos diretamente e repassa requisições PHP ao Apache, combinando a eficiência do Nginx para conteúdo estático com a compatibilidade do Apache com .htaccess e módulos como mod_rewrite.

O .htaccess do WordPress funciona no Nginx?

Não diretamente. O Nginx não lê arquivos .htaccess; todas as regras de reescrita precisam ser traduzidas para blocos location dentro do arquivo de configuração do virtual host. Para WordPress, isso significa converter as regras de permalink do .htaccess para a diretiva try_files do Nginx, o que exige acesso root ao servidor.

Qual servidor web é mais fácil de configurar para iniciantes?

O Apache é considerado mais acessível para iniciantes porque permite configurações por diretório via .htaccess, sem necessidade de reiniciar o serviço ou editar arquivos globais. O Nginx exige que todas as configurações sejam feitas centralmente e recarregadas com nginx -s reload, o que demanda maior familiaridade com a linha de comando e a estrutura de blocos server e location.

Conclusão

Tanto o Apache quanto o Nginx são escolhas sólidas para hospedar WordPress em 2025, mas cada um se destaca em cenários diferentes. A decisão deve considerar o perfil de tráfego, o nível técnico da equipe e os plugins utilizados.

• Escolha Apache se você usa hospedagem compartilhada, cPanel, ou precisa que plugins WordPress gerenciem regras de reescrita automaticamente via .htaccess — a curva de aprendizado é menor e a compatibilidade é maior.
• Escolha Nginx se você tem acesso root ao servidor, espera alto volume de tráfego simultâneo ou quer servir arquivos estáticos com máxima eficiência — o ganho de desempenho em picos de acesso justifica a configuração manual.
• Considere a arquitetura híbrida (Nginx como proxy reverso + Apache no backend) se precisar do melhor dos dois mundos: eficiência do Nginx para estáticos e compatibilidade total do Apache com o ecossistema WordPress.

Leia também

• Nginx vs Apache vs LiteSpeed: Escolha o Melhor para Linux
• Como otimizar o Apache para alta performance em VPS Linux: Guia Completo
• Como otimizar o WordPress para alta performance em VPS Linux: Guia Completo

Precisa de ajuda com Apache ou Nginx para WordPress?

Configurar e otimizar servidores web para WordPress exige atenção a detalhes que vão além da instalação básica. Na AviraHost, os planos de hospedagem de sites incluem suporte técnico especializado para ajudar na configuração do servidor web mais adequado ao seu projeto.

Conheça os planos de hospedagem WordPress da AviraHost