O que é um servidor web: Nginx, Apache e Node

Toda vez que você abre um site, alguma coisa do outro lado recebe o pedido do navegador e decide o que devolver. Essa coisa é o servidor web. Às vezes é um Nginx entregando um arquivo HTML, às vezes é um Apache rodando PHP, às vezes é o seu próprio código Node.js respondendo JSON.

Entender o que o servidor web faz explica muita coisa que parece mágica: por que um site estático é barato de hospedar, por que aparece um erro 502 quando a aplicação cai e por que tanta gente coloca um Nginx na frente do Node.

O que é um servidor web?#

Um servidor web é um programa que escuta numa porta de rede, recebe requisições HTTP e devolve respostas HTTP. A resposta pode ser um arquivo que já existe no disco (HTML, CSS, imagem), uma página gerada na hora por uma aplicação, ou dados para uma API.

O termo também é usado para a máquina onde esse programa roda. Na prática, quando alguém pergunta "qual servidor web você usa?", a resposta é um software: Nginx, Apache, Caddy, ou o servidor embutido da sua linguagem.

Por padrão, HTTP usa a porta 80 e HTTPS usa a porta 443. Em desenvolvimento, é comum ver portas como 3000 ou 8080, porque no Linux portas abaixo de 1024 exigem privilégios especiais.

Como um servidor web funciona por dentro?#

O ciclo de uma requisição tem quase sempre os mesmos passos:

1. Escutar. O servidor abre uma porta e espera conexões TCP.
2. Aceitar e decifrar. Chega uma conexão. Se for HTTPS, o servidor faz o handshake TLS com o certificado do domínio.
3. Ler a requisição. Método (GET, POST), caminho (/produtos/42), cabeçalhos (Host, Cookie, Accept) e, às vezes, um corpo.
4. Decidir o que fazer. Pelo cabeçalho Host, escolhe qual site atender. Pelo caminho, decide se lê um arquivo do disco ou repassa para uma aplicação.
5. Responder. Envia o código de status (200, 404, 500), cabeçalhos (Content-Type, Cache-Control) e o corpo.
6. Registrar. Grava uma linha no log de acesso, com IP, caminho, status e tempo.

Uma troca real, simplificada:

GET /index.html HTTP/1.1
Host: exemplo.com
Accept: text/html

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 1256
Cache-Control: max-age=3600

<!doctype html>...

Quando algo dá errado nesse caminho, o código de status conta onde. Um 404 é um arquivo ou rota que não existe; um 502 é o servidor web reclamando da aplicação atrás dele. Os detalhes estão em erros HTTP 500, 502, 503 e 504.

Servidor estático, servidor de aplicação e proxy reverso: qual a diferença?#

O mesmo software pode cumprir papéis diferentes, e é daí que vem a maior parte da confusão:

• Servidor de arquivos estáticos. Lê arquivos prontos do disco e devolve como estão. Rápido e leve, porque não executa código por requisição. É o que atende um site estático.
• Servidor de aplicação. Executa o seu código para montar cada resposta: consulta o banco, aplica regras, gera HTML ou JSON. Um app Express, Django ou Laravel faz esse papel.
• Proxy reverso. Fica na frente de uma ou mais aplicações, recebe a requisição do visitante e a repassa. Costuma cuidar de TLS, compressão, cache e distribuição de carga. Veja o que é um proxy reverso.

Um arranjo comum combina os três: o Nginx recebe tudo na porta 443, entrega /static/ direto do disco e repassa o resto para um processo Node.js na porta 3000.

O que é o Nginx?#

O Nginx é um servidor HTTP e proxy reverso de código aberto, conhecido por atender muitas conexões com pouca memória. Segundo a documentação oficial, ele tem um processo mestre, que lê a configuração e mantém os workers, e vários processos worker, que atendem as requisições usando um modelo orientado a eventos. O número de workers pode acompanhar a quantidade de núcleos da CPU.

A configuração fica em arquivos centrais, organizada em blocos server e location. O exemplo abaixo serve arquivos estáticos e repassa o resto para uma aplicação:

server {
    listen 80;
    server_name exemplo.com;

    # arquivos estáticos direto do disco: /static/logo.png vem de /var/www/static/logo.png
    location /static/ {
        root /var/www;
    }

    # o resto vai para a aplicação Node.js
    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Depois de editar, nginx -t valida a sintaxe e nginx -s reload aplica a configuração. Se a nova configuração tiver erro, o processo mestre mantém a antiga em funcionamento.

Quando usar: proxy reverso na frente de aplicações, sites estáticos, terminação de TLS em servidor próprio (VPS) e cache de respostas.

O que é o Apache?#

O Apache HTTP Server (httpd) é um dos servidores web mais antigos ainda em uso amplo. Sua arquitetura gira em torno de módulos. Os módulos de multiprocessamento (MPMs) definem como ele aceita conexões: prefork (um processo por conexão, compatível com software antigo), worker e event (com threads). Em sistemas modernos, o padrão quase sempre é o event.

O recurso mais conhecido do Apache é o .htaccess: um arquivo colocado numa pasta que muda a configuração só daquela pasta, sem acesso de administrador ao servidor. É por isso que ele domina a hospedagem compartilhada com PHP e WordPress. A própria documentação recomenda evitar o .htaccess quando você tem acesso à configuração principal, porque o servidor procura esses arquivos em cada pasta a cada requisição, o que custa desempenho.

Quando usar: hospedagem compartilhada, aplicações PHP que já trazem um .htaccess e ambientes onde regras por pasta são necessárias.

O Node.js é um servidor web?#

Pode ser. O Node.js traz o módulo node:http, que cria um servidor HTTP completo em poucas linhas. A documentação do Node explica que uma aplicação roda em um único processo, sem criar uma thread por requisição, e usa E/S não bloqueante para atender muitas conexões ao mesmo tempo.

// servidor.mjs: um servidor web mínimo, sem dependências
import { createServer } from "node:http";

const port = Number(process.env.PORT ?? 3000);

const server = createServer((req, res) => {
  if (req.url === "/") {
    res.writeHead(200, { "Content-Type": "text/plain; charset=utf-8" });
    res.end("Olá do servidor web\n");
    return;
  }
  res.writeHead(404, { "Content-Type": "text/plain; charset=utf-8" });
  res.end("Não encontrado\n");
});

// 0.0.0.0 aceita conexões de fora do container, não só da própria máquina
server.listen(port, "0.0.0.0", () => console.log(`Escutando na porta ${port}`));

Rode com node servidor.mjs e teste com curl -i http://localhost:3000/. Na prática, quase ninguém escreve rotas à mão: frameworks como Express, Fastify ou Next.js ficam por cima do mesmo módulo http.

Nesse modelo, o Node é o servidor de aplicação. Ele até serve arquivos estáticos, mas não é otimizado para isso como o Nginx. TLS e cache costumam ficar numa camada à frente.

Nginx, Apache ou Node: qual usar?#

Algumas regras práticas:

• Site estático puro: qualquer servidor de arquivos resolve, e muitas hospedagens servem os arquivos sem você configurar nada. Veja a diferença entre site estático e dinâmico.
• App Node.js, Python ou Go numa VPS: a aplicação escuta numa porta interna e o Nginx fica na frente com TLS.
• WordPress ou PHP legado: Apache com .htaccess é o caminho com menos atrito.
• Plataforma de hospedagem de aplicações: normalmente a borda da plataforma faz o papel de proxy reverso, e você só escreve a aplicação. Entenda a diferença em hospedagem web vs hospedagem de aplicações.

Como fazer isso na Square Cloud#

O arranjo deste artigo, proxy reverso na frente e aplicação atrás, já vem montado na Square Cloud. A rede da plataforma faz o papel do Nginx de borda, com CDN Anycast, HTTP/3, WebSockets, WAF e TLS automático, e cada aplicação web ganha um subdomínio *.squareweb.app com HTTPS. Você escreve só o servidor de aplicação (Express, FastAPI, Django, Laravel ou outro) e faz o deploy num container isolado, entre diversos runtimes, como Node.js, Python e Go. Veja os runtimes disponíveis hoje em Runtimes. A aplicação deve escutar em 0.0.0.0, na porta da variável PORT, que a plataforma define, e o proxy não corta conexões longas: WebSocket e SSE passam sem buffer.

Se o site não tem código no servidor, o runtime de sites estáticos é o servidor de arquivos deste artigo, já configurado. O nginx fica sempre rodando e servindo a sua pasta, e uma atualização (commit, upload ou edição no gerenciador de arquivos) entra no ar na hora, sem nginx -s reload nem restart. Numa SPA, um vite.html responde a todo caminho que não é arquivo.

Cada aplicação web precisa de pelo menos 512 MB da RAM do plano, e o Hobby, a partir de R$ 12,49 por mês, atende sites; domínio personalizado começa no Standard. O analytics web sem cookies, incluso em todos os planos, mostra visitas, rotas e códigos de status coletados no servidor, útil para achar os 404 e 5xx que a sua aplicação devolve. Veja como publicar na página de Sites.