Apache vs Nginx — Comparacao Tecnica Completa

O Apache HTTP Server e o Nginx dominam juntos mais de metade dos servidores web na Internet. Um existe desde 1995, o outro desde 2004. Ambos fazem o mesmo trabalho, mas pensam de formas completamente diferentes.

O Apache HTTP Server foi criado em 1995 por Rob McCool e um grupo de programadores que formou a Apache Group (mais tarde Apache Software Foundation). Cresceu com a web, tornou-se o servidor mais usado durante anos, e ainda hoje é uma escolha sólida para muitos cenários. O Nginx foi criado por Igor Sysoev em 2004 para resolver um problema específico: o C10k, ou como manter 10 mil conexões simultâneas num único servidor sem cair. Desde então, o Nginx conquistou o seu espaço, ultrapassou o Apache em quota de mercado, e tornou-se a escolha padrão para sites de alto tráfego.

De acordo com a W3Techs (Junho de 2026), o Nginx serve cerca de 32% dos sites conhecidos, contra 24% do Apache. Os números variam conforme a fonte, mas a tendência é clara: o Nginx está a ganhar terreno, especialmente em sites de alto tráfego. O Apache mantém-se forte em shared hosting e em ambientes empresariais onde a flexibilidade importa mais que a performance bruta.

Neste guia completo vais aprender:

• As diferenças fundamentais de arquitectura entre os dois servidores
• Como cada um lida com performance, conexões e memória
• Configuração e casos de uso: quando usar Apache, quando usar Nginx, ou usar ambos
• Tabelas comparativas detalhadas para decisão rápida

Arquitetura

A diferença mais importante entre Apache e Nginx está na arquitectura. Não é um detalhe técnico menor. É a razão de existirem diferenças enormes em performance, uso de memória e comportamento sob carga.

Apache e os MPMs

O Apache usa um modelo baseado em processos e threads. O núcleo do servidor é pequeno e toda a funcionalidade extra vem de módulos. A forma como o Apache lida com os pedidos depende do MPM (Multi-Processing Module) que escolheres. Existem três principais:

• mpm_prefork: o mais antigo. Cria um processo filho para cada conexão. Cada processo é isolado, o que é seguro para código que não é thread-safe (como mod_php). Mas gasta muita memória. Centenas de conexões simultâneas podem facilmente encher a RAM de um servidor pequeno.
• mpm_worker: cria processos que por sua vez gerem múltiplos threads. Cada thread trata de uma conexão. Gasta menos recursos que o prefork porque os threads partilham memória dentro do mesmo processo. Mas requer que todos os módulos sejam thread-safe.
• mpm_event: uma evolução do worker, optimizado para keep-alive connections. Separa o thread que aceita a conexão do thread que processa o pedido. Isto resolve um problema clássico do Apache: conexões keep-alive a ocupar threads à espera que o cliente peça mais dados. É o MPM recomendado desde o Apache 2.4.

<IfModule mpm_event_module>
    StartServers             3
    MinSpareThreads         75
    MaxSpareThreads        250
    ThreadsPerChild         25
    MaxRequestWorkers      400
    MaxConnectionsPerChild   0
</IfModule>

Nginx e o Event Loop

O Nginx usa um modelo event-driven, assíncrono e não-bloqueante. Há um processo master que lê a configuração e gere os workers. Depois há N workers (normalmente um por core de CPU). Cada worker corre um event loop que gere milhares de conexões simultâneas usando chamadas de sistema como epoll (Linux) ou kqueue (FreeBSD/macOS).

Não há um processo ou thread por conexão. Em vez disso, o event loop do Nginx verifica centenas de conexões ao mesmo tempo e reage quando há dados para ler ou escrever. Isto significa que o Nginx consegue manter dezenas de milhares de conexões abertas com muito pouca memória.

worker_processes  auto;
events {
    worker_connections  1024;
    use epoll;
    multi_accept on;
}
http {
    sendfile        on;
    tcp_nopush      on;
    keepalive_timeout  65;
}

Performance

A performance é onde as diferenças de arquitectura se tornam mais visíveis na prática. Há três cenários principais para comparar: conteúdo estático, conteúdo dinâmico e conexões simultâneas.

Conteúdo estático

O Nginx foi desenhado para servir ficheiros estáticos de forma eficiente. Usa sendfile para enviar ficheiros directamente do disco para a placa de rede, sem passar pelo espaço do utilizador. O event loop não-bloqueante significa que servir um ficheiro não bloqueia outras conexões.

O Apache também serve conteúdo estático, mas cada conexão ocupa um thread mesmo que esteja só a esperar que o ficheiro termine de ser lido. Em testes práticos, o Nginx serve ficheiros estáticos 2 a 3 vezes mais rápido que o Apache, especialmente com muitos ficheiros pequenos ou com high concurrency.

Conteúdo dinâmico

Aqui a situação inverte-se parcialmente. O Apache consegue processar conteúdo dinâmico directamente no servidor, integrando a linguagem como módulo. Por exemplo, mod_php embebe o interpretador PHP no próprio Apache. Isto é simples e eficiente para um servidor só com PHP.

O Nginx não consegue fazer isto. Para conteúdo dinâmico, precisa de passar o pedido para um processo externo: PHP-FPM, Gunicorn (Python), Unicorn/Puma (Ruby), ou um proxy para um servidor de aplicação. Isto adiciona um salto de rede (mesmo que seja localhost), mas permite separar o servidor web da aplicação.

Nota: A abordagem do Nginx é mais flexível em arquitecturas modernas. Separar o servidor web do processamento dinâmico permite escalar cada camada de forma independente.

Conexões simultâneas

Este é o ponto forte do Nginx. Por causa do event loop, um worker do Nginx pode gerir milhares de conexões em simultâneo. Num teste típico, o Nginx mantém-se estável com 10 mil conexões concorrentes enquanto o Apache começa a degradar-se perto de mil (dependendo da RAM disponível e do MPM escolhido).

Isto faz do Nginx a escolha óbvia para sites com picos de tráfego, APIs, ou aplicações real-time (WebSockets, SSE).

Configuração

As filosofias de configuração são muito diferentes. O Apache é descentralizado e flexível. O Nginx é centralizado e explícito.

Apache e os .htaccess

O Apache permite configuração por directoria usando ficheiros .htaccess. Podes colocar um ficheiro .htaccess em qualquer directoria e ele é lido em runtime sempre que um pedido acede a essa directoria. Isto é útil em vários cenários:

• Shared hosting: cada utilizador pode configurar regras de URL, autenticação, ou limites sem mexer no servidor
• Aplicações que precisam de config dinâmica: WordPress usa .htaccess para regras de permalink
• Deployments simples: mudar config não precisa de reload do servidor

O preço é performance. O Apache tem que verificar cada directoria no caminho do ficheiro a cada pedido para ver se existe um .htaccess. Num directório com muitos níveis, isto pode ser centenas de verificações por pedido.

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

    <Directory /var/www/exemplo>
        Options Indexes FollowSymLinks
        AllowOverride All
        Require all granted
    </Directory>

    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

Nginx e os location blocks

O Nginx não suporta .htaccess. Toda a configuração é centralizada nos ficheiros de config do servidor. Isto significa:

• Menos overhead em runtime, porque não há scanning de directorias
• Mais segurança, porque utilizadores não podem mudar config do servidor
• Menos flexível em shared hosting

Em vez de directorias, o Nginx usa location blocks para definir comportamentos diferentes para diferentes paths. Os location blocks podem ser combinados, aninhados, e usam expressões regulares para correspondência de padrões.

server {
    listen 80;
    server_name exemplo.pt;
    root /var/www/exemplo;

    location / {
        try_files $uri $uri/ /index.html;
    }

    location /api/ {
        proxy_pass http://backend:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }

    location ~* \.(jpg|jpeg|png|css|js)$ {
        expires 365d;
        add_header Cache-Control "public, immutable";
    }

    location = /favicon.ico {
        log_not_found off;
        access_log off;
    }
}

Módulos e Extensibilidade

Ambos os servidores são extensíveis através de módulos, mas a forma como os carregam é radicalmente diferente.

O Apache usa módulos dinâmicos (DSO) desde o início. Podes compilar um módulo separadamente e carregá-lo com LoadModule no httpd.conf sem recompilar o servidor. A biblioteca de módulos oficiais é enorme: mais de 50 módulos que cobrem desde autenticação (mod_auth) a reescrita de URLs (mod_rewrite), passando por compressão (mod_deflate), cabeçalhos (mod_headers), proxy (mod_proxy), e SSL (mod_ssl).

O Nginx, historicamente, só carregava módulos em tempo de compilação. Queres um módulo? Recompila o Nginx com --with-http_ssl_module. Isto mudou com a versão 1.9.11 (2016), que introduziu suporte a módulos dinâmicos. Ainda assim, o ecossistema é mais limitado que o do Apache, e muitos módulos populares são de terceiros (como o PageSpeed ou o ngx_http_geoip2_module).

Proxy Reverso e Load Balancing

O Nginx nasceu para ser um proxy reverso. O seu modelo assíncrono é naturalmente bom a fazer forwarding de pedidos para backends e a esperar pela resposta sem bloquear. A configuração de upstreams e load balancing é elegante e directa.

upstream backend_servers {
    least_conn;
    server app1.local:3000 weight=3;
    server app2.local:3000 weight=2;
    server app3.local:3000 backup;
}

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

    location / {
        proxy_pass http://backend_servers;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        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;
    }
}

O Apache também faz proxy reverso com mod_proxy e mod_proxy_balancer, mas a configuração é mais verbosa e a performance é inferior em cenários de alta concorrência. Não foi desenhado de raiz para isto, foi adaptado.

<VirtualHost *:80>
    ServerName api.exemplo.pt

    <Proxy "balancer://backend">
        BalancerMember "http://app1.local:3000" loadfactor=3
        BalancerMember "http://app2.local:3000" loadfactor=2
        BalancerMember "http://app3.local:3000" status=+H
        ProxySet lbmethod=bytraffic
    </Proxy>

    ProxyPreserveHost On
    ProxyPass "/" "balancer://backend/"
    ProxyPassReverse "/" "balancer://backend/"

    RequestHeader set X-Forwarded-Proto "https"
    RequestHeader set X-Forwarded-For "%{REMOTE_ADDR}s"
</VirtualHost>

O Nginx suporta vários algoritmos de load balancing nativamente: round-robin (padrão), least_connections, ip_hash (para sessões persistentes), e random. O Apache também oferece lbmethod=byrequests, bytraffic, e bybusyness.

Ecossistema e Casos de Uso

Cada servidor brilha em cenários diferentes. A escolha certa depende do que estás a construir.

Quando usar Apache

• Shared hosting tradicional: o suporte a .htaccess permite que cada cliente configure o seu espaço sem intervenção do administrador
• Aplicações PHP legadas: mod_php integrado no Apache é mais simples de configurar que PHP-FPM
• Ambientes que precisam de módulos específicos: o ecossistema de módulos do Apache é o mais vasto
• Equipas familiarizadas com Apache: se a equipa já conhece Apache, não há razão para mudar se o site não tiver problemas de performance

Quando usar Nginx

• Sites com alto tráfego: o Nginx lida com picos de conexões sem suar
• Proxy reverso e load balancing: é para isto que o Nginx foi feito
• Microserviços e APIs: o modelo assíncrono é ideal para encaminhar pedidos entre dezenas de servicos
• Conteúdo estático: imagens, CSS, JS, downloads. O Nginx serve isto de forma extremamente eficiente
• Single-page applications: servir ficheiros estáticos + fazer proxy das chamadas API
• WebSockets e streaming: o event loop do Nginx é naturalmente bom para conexões de longa duração

Setup híbrido: Nginx + Apache

Não precisas de escolher apenas um. Muitos sites usam Nginx como proxy reverso à frente do Apache. O Nginx serve ficheiros estáticos e faz proxy dos pedidos dinâmicos para o Apache, que processa o PHP (ou outra linguagem) e devolve a resposta.

É exatamente este o setup que corre neste servidor (fuzzalab.pt). O Apache (mod_proxy) faz reverse proxy para o backend Node.js na porta 3000 e para o Flask (auth) na porta 5100. O Cloudflare está à frente como CDN e proxy SSL. Não usamos Nginx no servidor principal. Usamos Apache como proxy reverso porque o site tem tráfego moderado e a configuração centralizada no Apache simplifica a gestão.

Mas para um site com mais tráfego, o setup clássico seria: Cloudflare (CDN/SSL) → Nginx (proxy reverso, static files, cache) → Apache (PHP dinâmico) ou directamente → Node.js/Python/Ruby (aplicação).

Nota: Este setup híbrido é extremamente comum no WordPress. O Nginx serve os assets estáticos (temas, plugins, uploads) e faz proxy dos pedidos PHP para o Apache ou directamente para PHP-FPM.

Tabela Comparativa Final

Conclusão

Não há uma resposta certa para a pergunta "Apache ou Nginx?". São ferramentas diferentes para problemas diferentes. O Apache é maduro, flexível, e tem um ecossistema de módulos que ninguém iguala. O Nginx é rápido, leve, e eficiente em cenários de alta concorrência.

Se estás a gerir um servidor partilhado com dezenas de sites PHP que usam .htaccess, o Apache é provavelmente a escolha certa. Se estás a construir uma API para milhares de clientes ou um site com picos de tráfego, o Nginx vai fazer-te a vida mais fácil.

E se precisares do melhor dos dois mundos, podes sempre usar os dois em conjunto. O Nginx à frente a servir estáticos e a fazer proxy, o Apache atrás a tratar do processamento dinâmico. É um setup testado e comprovado que combina a performance do Nginx com a flexibilidade do Apache.

O que importa é perceber as diferenças e escolher a ferramenta certa para o problema certo. Agora já tens os dados para fazer essa escolha.

Recursos adicionais

• Documentação oficial do Apache HTTP Server
• Documentação oficial do Nginx
• W3Techs: Comparação de quota de mercado
• Apache MPM: Documentação oficial
• Nginx: Connection processing methods