NGINX x Apache: Qual Servidor Web Usar e o Que Isso Muda para Você

Se você já leu qualquer discussão sobre desempenho de site, esbarrou nos nomes Apache e NGINX. Eles aparecem como se todo mundo devesse ter uma opinião forte, e a internet ajuda pouco: um lado jura que o NGINX é infinitamente mais rápido, o outro defende o Apache como se fosse uma questão de honra, e o dono de site, que só queria o site funcionando bem, fica sem saber se aquilo muda alguma coisa na vida dele ou se é briga de especialista. A verdade é mais tranquila do que a discussão sugere.

Este texto explica o que um servidor web faz, como Apache e NGINX fazem esse trabalho de formas diferentes, e — mais importante — o que dessa diferença realmente chega até você. Você não precisa virar administrador de sistemas para tomar uma boa decisão ou para entender por que seu site se comporta de um jeito. Precisa entender o essencial, e o essencial cabe numa leitura. No fim, você vai saber inclusive como descobrir qual dos dois está rodando o seu site agora.

O que é um servidor web, afinal#

Antes de comparar, vale saber o que está sendo comparado. Servidor web é o programa que fica escutando os pedidos que chegam do navegador e devolve o conteúdo certo. Quando alguém digita o endereço do seu site, o navegador manda uma requisição pela internet; do outro lado, num computador ligado o tempo todo, o servidor web recebe esse pedido, descobre o que foi solicitado e responde — devolvendo o HTML da página, uma imagem, um arquivo de estilo, o que for.

É importante não confundir. O "servidor" tem dois sentidos que a linguagem do dia a dia mistura. Há o servidor físico (a máquina, o computador ligado no data center) e há o software servidor web (o programa que atende os pedidos dentro dessa máquina). Apache e NGINX são a segunda coisa: programas. Os dois fazem o mesmo trabalho básico — receber requisições HTTP e responder — e os dois são maduros, gratuitos, de código aberto e usados por uma fatia enorme da web. A diferença não está no que fazem, e sim em como fazem, e esse "como" tem consequências práticas.

Vale separar também dois tipos de conteúdo, porque essa distinção reaparece o tempo todo na comparação:

• Conteúdo estático. Arquivos que já existem prontos no disco: imagens, CSS, JavaScript, um HTML fixo. O servidor só precisa encontrar o arquivo e entregá-lo. É rápido e simples.
• Conteúdo dinâmico. Páginas geradas na hora por um programa — o WordPress montando um post a partir do banco de dados, por exemplo. Aqui o servidor web não devolve o arquivo direto: ele passa o pedido para outro programa (o PHP, por exemplo), espera a resposta e a repassa ao navegador.

Guarde essa distinção. Boa parte da diferença de desempenho entre Apache e NGINX aparece justamente na forma como cada um lida com o conteúdo estático e com o volume de pedidos simultâneos.

Como o Apache processa requisições#

O Apache é o mais antigo dos dois e, por muito tempo, foi o servidor web padrão da web inteira. Seu modelo tradicional de trabalho é intuitivo: para cada conexão que chega, o Apache dedica um processo ou uma linha de execução (thread) só para aquela conexão, do início ao fim. É como um restaurante onde cada cliente que entra ganha um garçom exclusivo, que fica ao lado dele até ele terminar de comer e ir embora.

Esse modelo é robusto, previsível e fácil de entender. Enquanto há garçons livres, todo cliente é bem atendido. O problema aparece na hora do movimento. Cada processo consome memória, e o número de garçons é limitado pela memória do servidor. Quando chegam mais clientes do que há garçons, os novos ficam esperando na porta — as requisições entram numa fila. Pior: muitas conexões modernas são lentas de propósito ou ficam abertas sem fazer nada (um visitante com internet ruim, uma aba deixada aberta), e cada uma dessas prende um garçom parado, sem atender ninguém. Sob muita concorrência, o Apache tradicional gasta memória mantendo processos ociosos e acaba ficando sem capacidade para os pedidos que realmente importam.

O Apache tem uma vantagem histórica que pesa muito no mundo real: o .htaccess.

.htaccess: a configuração distribuída#

O .htaccess é um arquivo de configuração que você coloca dentro das pastas do seu site para dar ordens ao Apache: redirecionar endereços, proteger diretórios com senha, forçar HTTPS, definir regras de cache, reescrever URLs. A graça é que ele funciona por pasta e sem precisar de acesso administrativo ao servidor: você edita um arquivo dentro da sua própria conta e a regra passa a valer.

É exatamente por isso que o Apache reinou na hospedagem compartilhada. Num ambiente onde milhares de sites dividem a máquina e ninguém tem acesso à configuração central do servidor, o .htaccess deixa cada dono ajustar o próprio site sem tocar no dos outros. WordPress, Joomla, praticamente todo CMS popular assume que o .htaccess existe. É comodidade real.

Só que comodidade cobra um preço. Como qualquer pasta pode ter um .htaccess, o Apache precisa, a cada requisição, procurar esses arquivos em todos os diretórios do caminho e lê-los de novo — ele não pode confiar numa configuração lida uma vez, porque você pode mudar o arquivo a qualquer momento. Essa verificação constante custa desempenho. É flexível e prático, mas não é de graça.

Como o NGINX processa requisições#

O NGINX nasceu depois, e nasceu justamente para resolver o problema de concorrência que apertava o Apache. Em vez de um garçom exclusivo por cliente, o NGINX trabalha com pouquíssimos processos, cada um capaz de fazer malabarismo com milhares de conexões ao mesmo tempo. O nome disso é modelo orientado a eventos (event-driven), e a metáfora certa não é mais o garçom exclusivo, e sim um garçom experiente que cuida de muitas mesas em paralelo: leva o pedido de uma, enquanto a cozinha prepara vai atender outra, volta quando a comida fica pronta. Ninguém fica parado esperando.

A consequência é direta. Aquelas conexões lentas ou ociosas que prendiam um processo inteiro do Apache não travam mais nada no NGINX — ele simplesmente as mantém abertas de canto enquanto cuida das demais, gastando pouquíssima memória por conexão. Sob altíssima concorrência, milhares de visitantes ao mesmo tempo, o NGINX mantém o consumo de memória estável e previsível, onde o Apache tradicional dispararia. É por isso que ele brilha entregando conteúdo estático e absorvendo picos de tráfego: entregar arquivos prontos para muita gente ao mesmo tempo é exatamente o cenário para o qual ele foi desenhado.

Em compensação, o NGINX não tem .htaccess. Toda a configuração é central: fica num conjunto de arquivos que só quem administra o servidor edita, e uma mudança normalmente exige recarregar o serviço. Isso é ao mesmo tempo a força e a fraqueza do modelo.

• A favor. Sem procurar arquivos de configuração em cada pasta a cada pedido, o NGINX é mais rápido e mais previsível. A configuração é lida uma vez e fica.
• Contra. Você não ajusta regras editando um arquivo dentro da sua pasta. Redirecionar um endereço ou proteger um diretório exige mexer na configuração central, o que na prática significa ter acesso ao servidor ou pedir para quem tem.

Para conteúdo dinâmico, vale notar, os dois dependem de um programa externo para gerar a página (o PHP, tipicamente). Nesse ponto, a velocidade de gerar o HTML é do PHP e do banco, não do servidor web. A diferença entre Apache e NGINX aqui é menor do que a fama sugere: o que o NGINX ganha é na eficiência de receber os pedidos e devolver as respostas, não em gerar a página em si.

Desempenho sob concorrência: onde a diferença aparece de verdade#

Aqui mora o mal-entendido mais comum. "NGINX é mais rápido" não significa que cada página individual carregue mais depressa num site com pouco movimento. Com cinco visitantes na madrugada, você não vai notar diferença nenhuma entre um e outro. A vantagem do NGINX é de escala: ela aparece quando muita gente chega ao mesmo tempo.

Pense em duas curvas. Com poucos acessos simultâneos, Apache e NGINX correm quase juntos. À medida que os visitantes simultâneos aumentam, o Apache tradicional começa a gastar memória mantendo um processo por conexão, e a certa altura a memória acaba: novos pedidos entram na fila e o site desacelera ou passa a recusar conexões. O NGINX, mantendo o consumo achatado, continua atendendo com folga muito além desse ponto. A diferença de desempenho não é uma constante — é uma distância que cresce com o número de acessos concorrentes.

Por isso a escolha depende do perfil do site:

• Site com muito conteúdo estático e picos de tráfego (portal de notícias, blog viral, página de campanha): o NGINX faz diferença clara.
• Site com tráfego moderado e estável: os dois entregam bem, e a escolha pesa mais por conveniência (o .htaccess, o suporte do seu CMS, o que a hospedagem já configurou) do que por velocidade.
• Aplicação que gera tudo dinamicamente: o gargalo tende a ser o PHP e o banco de dados, não o servidor web, e trocar de servidor sozinho resolve pouco.

Ou seja: a pergunta útil não é "qual é mais rápido no absoluto", e sim "qual se encaixa no meu padrão de tráfego". Para muita gente, a resposta honesta é "tanto faz, e o que já está configurado serve".

O melhor dos dois: NGINX na frente do Apache#

Há uma resposta que quase ninguém menciona na briga de "um contra o outro" e que é o que muitos sites profissionais de fato usam: os dois juntos. É uma arquitetura chamada de reverse proxy, e ela é mais comum do que a discussão faz parecer.

O arranjo funciona assim: o NGINX fica na frente, recebendo todas as conexões da internet. Ele mesmo entrega o conteúdo estático — imagens, CSS, JavaScript — que é o que ele faz melhor, e faz isso absorvendo a concorrência e os picos. Quando chega um pedido de conteúdo dinâmico, que precisa do PHP e do .htaccess, o NGINX repassa para o Apache, que fica atrás, protegido, cuidando só do que é dinâmico. O Apache nunca lida diretamente com a multidão de conexões lentas; o NGINX faz esse filtro na porta.

O resultado combina as duas forças. Você ganha a eficiência do NGINX absorvendo o tráfego e servindo estático, e mantém a compatibilidade e a comodidade do Apache com .htaccess para os aplicativos que dependem dele. É por isso que "Apache x NGINX" muitas vezes é uma falsa dicotomia: em muitos servidores bem montados, a resposta é "os dois, cada um no seu papel". Você provavelmente não vai configurar isso sozinho, mas é bom saber que a arquitetura do seu site pode já ser essa — e que ela existe justamente para você não precisar escolher.

O que o dono de site precisa (e não precisa) saber#

Chega a parte mais libertadora deste texto. Se você é dono de um site e não pretende administrar servidores, a maior parte dessa discussão simplesmente não é sua para resolver. Algumas verdades práticas:

• Na hospedagem compartilhada, você quase nunca escolhe. A hospedagem decide o servidor web, e é comum ser Apache (pelo .htaccess) ou um arranjo com NGINX na frente. Você usa o que está lá, e está tudo bem.
• Seu CMS funciona nos dois. WordPress, Joomla e afins rodam tanto em Apache quanto em NGINX. Se você usa NGINX, as regras que iriam num .htaccess viram configuração central que a hospedagem já deixou pronta. Você não fica sem o recurso; ele só mora em outro lugar.
• Trocar de servidor não conserta um site lento por outros motivos. Se a lentidão vem de imagens pesadas, plugin ruim ou banco de dados sem manutenção, nem Apache nem NGINX resolvem. A escolha do servidor web só importa depois que o resto está saudável, e mesmo assim mais em cenários de alta concorrência.
• A decisão real aparece só no VPS. Quando você tem controle do servidor, aí sim escolher (ou combinar) faz sentido. Na compartilhada, é decisão da casa.

O que vale a pena saber é o mapa mental: Apache é flexível por pasta e universalmente compatível; NGINX é eficiente sob concorrência e brilha com estático; e os dois juntos, com o NGINX na frente, são um padrão sólido. Com isso, você conversa com qualquer suporte técnico de igual para igual, sem precisar decorar nenhum arquivo de configuração.

Como descobrir qual você usa#

Curioso para saber o que roda o seu site agora? Há um jeito simples que não exige nada técnico. Todo servidor web costuma se identificar num cabeçalho de resposta chamado Server, enviado junto com cada página. Duas formas de olhar:

• Ferramenta online. Existem sites gratuitos de "verificar tecnologia do site" ou "header checker": você cola o endereço e ele mostra o cabeçalho Server, que traz "Apache" ou "nginx".
• No próprio navegador. Abra as ferramentas de desenvolvedor (geralmente a tecla F12), vá até a aba de rede (Network), recarregue a página, clique no primeiro item da lista e procure, nos cabeçalhos de resposta, a linha Server.

Vale um aviso: alguns servidores escondem ou disfarçam esse cabeçalho por segurança, e se houver um CDN na frente do site, o cabeçalho pode mostrar o CDN em vez do servidor de origem. Se aparecer vazio ou com um nome que não é nenhum dos dois, não é problema — é só configuração de privacidade. Na dúvida real, a resposta mais confiável é perguntar à sua hospedagem: eles sabem exatamente o que roda por baixo do seu site.

O que levar disso#

Apache e NGINX fazem o mesmo trabalho — receber pedidos e devolver conteúdo — de jeitos diferentes. O Apache dedica um processo por conexão e ganha em flexibilidade com o .htaccess, o que o tornou o rei da hospedagem compartilhada; paga por isso em consumo de memória sob muita concorrência. O NGINX trabalha orientado a eventos, segura milhares de conexões com pouca memória e brilha entregando conteúdo estático e absorvendo picos; em troca, concentra toda a configuração no centro, sem .htaccess. Nenhum é "melhor" no absoluto: são feitos para pesos diferentes.

Para o dono de site, a conclusão é tranquilizadora. Com pouco tráfego, a diferença é imperceptível e a escolha é da hospedagem, não sua. A vantagem do NGINX aparece na escala, quando muita gente chega junto. E a resposta mais sofisticada não é escolher um contra o outro, mas usar o NGINX na frente do Apache, cada um no seu forte. Saber isso já basta para você entender o próprio site, conversar com o suporte e decidir com clareza quando — e só se — o controle do servidor de fato cair no seu colo.