Apache vs. NGINX: qual é o melhor servidor web para WordPress?

Se você roda WordPress no seu próprio VPS, tanto Apache quanto NGINX podem servir bem o site, mas fazem escolhas diferentes. NGINX costuma ser o padrão melhor para alta concorrência, entrega de arquivos estáticos e HTTP/3 opcional. Apache é mais fácil quando a sua stack WordPress depende de .htaccess ou de módulos específicos do Apache.

Esta comparação entre Apache e NGINX foca nas diferenças que importam para o WordPress: arquitetura, tratamento do PHP, configuração, HTTP/3 e se vale a pena a complexidade extra de rodar os dois. LiteSpeed e Caddy ficam fora do escopo.

Resposta curta: para um VPS WordPress autogerenciado, escolha NGINX por padrão. Escolha Apache se o seu site ou os seus plugins dependem muito de .htaccess. Rode os dois apenas quando você realmente precisar do NGINX na frente sem abrir mão da compatibilidade com o Apache.

O que é o Apache?

O Apache é um software de servidor web de código aberto muito usado, desenvolvido e mantido pela organização americana sem fins lucrativos Apache Software Foundation (ASF). Ele também é conhecido como Apache HTTP Server e HTTPD.

A página de download do Apache lista a 2.4.68, lançada em junho de 2026, como a versão estável atual.

O Apache HTTP Server é um servidor open source modular com suporte maduro a regras .htaccess por diretório, vários módulos de multiprocessamento (MPMs), proxy reverso, reescrita de URL, TLS e módulos carregados dinamicamente. Para o WordPress, sua maior vantagem prática é a compatibilidade de configuração, não a velocidade bruta.

Os recursos do Apache que mais pesam nesta comparação são os MPMs prefork, worker e event; .htaccess; HTTP/2; proxy reverso e balanceamento de carga; suporte a FastCGI; módulos dinâmicos; reescrita de URL; e TLS.

O que é o NGINX?

O NGINX ("engine x") é um servidor web de código aberto, proxy reverso, cache de conteúdo, balanceador de carga, proxy TCP/UDP e proxy de e-mail, escrito originalmente por Igor Sysoev. Seus processos worker usam um modelo orientado a eventos, feito para atender muitas conexões simultâneas com pouco custo por conexão.

A página de download do NGINX lists the 1.30.x stable branch and the 1.31.x mainline branch.

Apache vs. NGINX: principais diferenças para o WordPress

Apache e NGINX se diferenciam principalmente em como lidam com conexões, configuração, PHP e suporte a protocolos. O comportamento do Apache depende muito do MPM que ele usa, enquanto o NGINX trabalha com processos worker orientados a eventos.

Apache vs. NGINX: arquitetura

O modelo de requisições do Apache depende do MPM que você usa. O prefork é baseado em processos, enquanto worker e event usam threads. O NGINX usa processos worker construídos em torno de loops de eventos. Por isso a comparação conhecida de "Apache orientado a processos contra NGINX orientado a eventos" é simplista demais para uma instalação atual do Apache 2.4.

O MPM event do Apache pode passar as conexões keep-alive ociosas para a sua thread listener em vez de prender uma thread worker para cada uma. O NGINX ainda tende a ter menos custo por conexão quando há um número muito alto de conexões simultâneas, mas a distância arquitetural é bem menor do que sugerem as comparações antigas da era do prefork.

Apache vs. NGINX: desempenho

A vantagem de desempenho do NGINX aparece principalmente sob alta concorrência e cargas de arquivos estáticos. Seus workers orientados a eventos conseguem manter muitas conexões abertas com um custo por conexão relativamente baixo. O MPM event do Apache reduz bastante essa distância em relação às configurações prefork mais antigas.

As requisições dinâmicas do WordPress são outra história. O NGINX normalmente encaminha o PHP para o FastCGI, em geral o PHP-FPM. O Apache também pode usar PHP-FPM via FastCGI ou executar PHP por um módulo do Apache.

Assim que o PHP começa a executar o WordPress, o código dos plugins, as consultas ao banco de dados, o cache de objetos ou de páginas e o dimensionamento dos workers do PHP podem pesar mais do que o servidor web na frente. Se um plugin dispara uma dúzia de consultas caras por requisição, trocar Apache por NGINX não vai resolver o problema de fundo.

Apache vs. NGINX: suporte a HTTP/3 e QUIC

O HTTP/3 é a versão atual do protocolo e roda sobre QUIC em vez de TCP. Se o seu site pode oferecê-lo depende do servidor web que está na frente, e este é o único ponto da comparação em que os dois servidores não estão perto um do outro.

O NGINX traz um módulo HTTP/3 desde a versão 1.25.0. Ele não é compilado por padrão, e a build exige o parâmetro --with-http_v3_module.

A documentação do módulo HTTP/3 do NGINX ainda descreve o módulo como "experimental, caveat emptor applies".

O Apache 2.4 não traz nenhum módulo nativo de HTTP/3 ou QUIC; o suporte a protocolos que vem com ele para em mod_http2.

A consequência prática para quem tem um site: uma instalação padrão do Apache 2.4 não oferece HTTP/3. Em produção, a opção viável continua sendo terminar o HTTP/3 em um proxy reverso ou uma CDN compatíveis na frente do Apache. Se você quer o protocolo, uma opção é colocar o NGINX na frente do Apache e deixar que o NGINX termine as conexões dos clientes, o arranjo descrito mais adiante.

Apache vs. NGINX: segurança

Nem Apache nem NGINX é categoricamente "mais seguro". Os dois são projetos maduros com manutenção de segurança ativa, e a segurança de uma implantação em produção depende mais das correções aplicadas, dos módulos habilitados, da configuração de TLS, dos controles de acesso, dos limites de taxa e da aplicação por trás do servidor.

A comparação útil é sobre superfície de ataque e configuração, não sobre um vencedor absoluto. Desative os módulos e endpoints de que você não precisa, mantenha o servidor atualizado e reforce a stack WordPress que está atrás dele.

Apache vs. NGINX: configuração

Os arquivos .htaccess por diretório do Apache funcionam sempre que o AllowOverride permite. Isso é útil para o WordPress, porque as regras de reescrita podem ser alteradas sem mexer na configuração global do servidor.

Essa conveniência tem um custo. A própria documentação do Apache recomenda colocar as regras na configuração principal do servidor quando você tem acesso root: os arquivos .htaccess são verificados durante as requisições, e habilitá-los traz implicações de desempenho e de segurança.

O NGINX não tem equivalente ao .htaccess. Sua configuração é centralizada, então o WordPress não consegue escrever regras de reescrita no nível do servidor por você. Regras de links permanentes e diretivas de servidor exigidas por plugins precisam ser adicionadas à configuração do NGINX por um administrador e depois recarregadas.

Apache vs. NGINX: módulos e extensibilidade

O Apache tem suporte maduro a Dynamic Shared Objects (DSO): os módulos podem ser compilados separadamente e carregados por LoadModule. O NGINX também aceita módulos dinâmicos via load_module, mas a compatibilidade binária com a versão instalada do NGINX e com sua configuração de build pesa mais quando você usa módulos de terceiros fora do comum.

O Apache leva vantagem, portanto, se você depende de módulos de terceiros pouco comuns. Para hospedagem WordPress comum, essa diferença costuma pesar menos do que .htaccess, o tratamento do PHP e as ferramentas que você já usa.

Apache vs. NGINX: suporte a plataformas

O Apache roda em Linux, Windows, macOS e muitos sistemas do tipo Unix. O NGINX também está disponível nas principais plataformas, mas sua build nativa para Windows tem limitações importantes. O NGINX ainda classifica a versão para Windows como beta, avisa que não se deve esperar alto desempenho nem escalabilidade, observa que apenas um worker realmente executa trabalho e não oferece suporte a UDP nem a QUIC. Para implantar NGINX em produção, um sistema do tipo Unix é a escolha prática.

Apache vs. NGINX: tratamento de requisições

O Apache normalmente mapeia a URL de uma requisição para o sistema de arquivos abaixo do DocumentRoot, enquanto seu sistema de configuração também pode aplicar locations baseadas no URI, reescritas e regras de proxy. O NGINX escolhe primeiro um bloco server e depois um bloco location, principalmente a partir do URI da requisição, antes de decidir se serve um arquivo ou repassa a requisição adiante.

Essa diferença muda como você escreve a configuração, mas por si só não prova que o NGINX transfere dados mais rápido.

Uma comparação rápida entre NGINX e Apache

Veja como os dois servidores se posicionam nos eixos acima, mais o suporte a protocolos e a versão atual de cada um.

Usar Apache e NGINX juntos

Sim, você pode rodar os dois. Um arranjo híbrido comum coloca o NGINX na frente como proxy reverso voltado ao cliente e o Apache atrás. O NGINX pode terminar TLS e HTTP/2, e pode terminar HTTP/3 quando seu módulo HTTP/3 experimental está compilado e habilitado. Ele também pode servir alguns arquivos estáticos por conta própria enquanto repassa as requisições de aplicação ao Apache.

A ressalva importante é saber de quem são as regras. Uma requisição que o NGINX atende diretamente nunca chega ao Apache, então as regras .htaccess do Apache não valem para ela. As duas configurações precisam concordar sobre reescritas, cache, encaminhamento do IP do cliente, comportamento de TLS e qual servidor manda em cada caminho.

O custo é que agora você tem dois servidores web rodando. Duas configurações que precisam concordar entre si, dois ciclos de atualização para acompanhar e mais um lugar onde procurar quando uma requisição devolve algo inesperado. Em um único site pequeno esse trabalho extra costuma superar o benefício; ele começa a compensar quando você quer HTTP/3 ou entrega estática mais rápida sem abrir mão do comportamento de .htaccess de que seus plugins dependem.

O NGINX é mais fácil que o Apache?

Nenhum dos dois é mais fácil de forma universal. O NGINX é, se você prefere uma configuração centralizada e se sente à vontade editando blocos server. O Apache é, quando o WordPress ou plugins de terceiros esperam regras .htaccess, porque essas regras atuam no nível do diretório sem mexer na configuração global do servidor.

Num servidor que você controla, "mais fácil" se resume principalmente a qual modelo de configuração a sua stack já espera.

Quando usar Apache em vez de NGINX?

Escolha Apache quando a sua stack WordPress depende de .htaccess, quando plugins ou ferramentas de painel de controle esperam diretivas de reescrita do Apache, ou quando você precisa de um módulo específico do Apache. Também é razoável manter o Apache num site que já funciona bem: trocar de servidor web por um ganho teórico de benchmark raramente compensa o transtorno.

Quando usar NGINX em vez de Apache?

Escolha NGINX quando esperar muitas conexões simultâneas, quiser uma camada forte de arquivos estáticos ou de proxy reverso, preferir configuração centralizada, ou quiser a opção de habilitar HTTP/3. No WordPress, a contrapartida é que as regras de reescrita e as diretivas de servidor específicas de plugins viram tarefa do administrador, e não algo que o WordPress possa escrever no .htaccess.

NGINX vs Apache: qual é o melhor servidor web para WordPress?

Use NGINX. Para um site WordPress em um servidor que você controla, é o melhor padrão: baixo custo por conexão sob alta concorrência, entrega eficiente de arquivos estáticos e HTTP/3 disponível se você quiser.

A exceção é o .htaccess, e ela pesa. O WordPress consegue escrever regras de reescrita do Apache quando o .htaccess está habilitado, mas não consegue alterar a configuração de servidor do NGINX. Se um plugin espera diretivas de reescrita, de segurança ou de cache, você precisa das instruções dele para NGINX ou de uma regra equivalente no bloco server, e depois recarregar o NGINX. Se você não quer essa responsabilidade operacional, o Apache é a escolha WordPress mais simples. Num site de tráfego normal, PHP, banco de dados e cache têm mais chance de limitar o desempenho do que o próprio servidor web.

Sob tudo isso há um pressuposto: o servidor precisa ser seu e poder ser alterado. Numa hospedagem WordPress gerenciada, o servidor web é decisão do provedor, e a resposta a esta pergunta é simplesmente o que ele já executa. Esta comparação é para quem tem acesso root na própria máquina.

Como saber se você está rodando Apache ou NGINX?

Se este é o seu próprio VPS, verifique diretamente os serviços em execução:

systemctl status nginx
systemctl status apache2   # Debian/Ubuntu
systemctl status httpd     # RHEL/Fedora-family systems

Para um site remoto que você não controla, o cabeçalho de resposta HTTP Server pode ser uma pista, mas não é definitivo. Um proxy reverso ou uma CDN pode expor o próprio software de servidor em vez do da origem, e o cabeçalho também pode ser ocultado ou alterado.

Hospedar Apache ou NGINX em um VPS

Se o VPS é seu, os dois servidores são simples de rodar. Dimensione a máquina para toda a stack WordPress, não só para o Apache ou o NGINX: workers do PHP, banco de dados, cache, tráfego e tarefas em segundo plano costumam consumir mais recursos do que o próprio servidor web.

Seja qual for o servidor escolhido, configuração, atualizações, TLS, backups e monitoramento ficam por sua conta. Rodar os dois acrescenta mais uma configuração e mais um caminho de atualização, então use o arranjo híbrido só se tiver um motivo específico.

O VPS NGINX da Cloudzy é um VPS Linux autogerenciado com acesso root completo, então a configuração do servidor continua sendo sua.

A imagem do Apache HTTP Server no nosso marketplace instala do mesmo jeito, em um clique, então subir qualquer um dos servidores, ou os dois, não começa compilando a partir do código-fonte.

LER

Caddy vs Nginx em um VPS: a comparação dos arquivos de configuração

Perguntas frequentes

O Apache é melhor que o NGINX?

Nenhum é melhor de forma universal. O NGINX costuma ser o padrão mais forte quando você se importa com alta concorrência, entrega de arquivos estáticos, proxy reverso ou HTTP/3. O Apache costuma ser mais fácil quando a sua stack WordPress depende de .htaccess ou de módulos específicos do Apache.

Por que o NGINX é mais rápido que o Apache?

O NGINX consegue tratar muitas conexões dentro do loop de eventos de cada worker, o que mantém baixo o custo por conexão em alta concorrência. O MPM event do Apache também lida com conexões de forma assíncrona, então a diferença é menor do que sugerem as comparações antigas com prefork. No WordPress, PHP, consultas ao banco e cache podem pesar mais do que a diferença entre os servidores web.

Devo usar Apache ou NGINX para o WordPress?

Para um VPS WordPress autogerenciado, o NGINX é um ótimo padrão se você se sente à vontade cuidando das regras nos blocos server. Escolha Apache se depende de .htaccess ou de plugins que esperam regras de reescrita do Apache e quer que elas funcionem com menos configuração manual de servidor.

Por que o NGINX é tão popular?

O NGINX combina tratamento eficiente de requisições em alta concorrência com proxy reverso, balanceamento de carga, cache, suporte a FastCGI e terminação de TLS. Isso o torna útil tanto como servidor web principal quanto como proxy de frente.

Por que o Apache ainda é usado?

O Apache continua muito usado por causa do seu ecossistema de módulos, do suporte a .htaccess, das ferramentas maduras, do amplo suporte a plataformas e da compatibilidade com fluxos de trabalho de hospedagem e painéis de controle construídos em torno dele.

Qual é a diferença entre Apache e apache2?

No Debian e no Ubuntu, apache2 é o nome do pacote e do serviço do Apache HTTP Server. Sistemas da família RHEL e Fedora costumam chamar esse serviço de httpd. Não são servidores web diferentes: os dois se referem ao Apache HTTP Server. O ramo estável atual do Apache é o 2.4, com a 2.4.68 como versão mais recente.

O Apache oferece suporte a HTTP/3?

Nativamente, não. O Apache HTTP Server 2.4 não vem com um módulo de HTTP/3 ou QUIC; o suporte a protocolos que o acompanha para em HTTP/2. Se você precisa de HTTP/3 em produção, pode terminá-lo em um proxy reverso ou uma CDN compatíveis na frente do Apache.