Nginx: o que é, para que serve e diferença do Apache

Você contrata uma VPS, sobe uma aplicação em Node na porta 3000 e descobre o primeiro problema. O visitante digita o domínio, e o navegador procura a porta 80 ou a 443.

Alguém precisa ficar nessas portas, cuidar do certificado HTTPS e entregar as imagens do site sem gastar o processo da aplicação. Em boa parte dos servidores Linux, quem faz esse trabalho é o Nginx.

O nome se pronuncia "engine x". O programa ficou conhecido como alternativa ao Apache e hoje costuma ficar na frente de aplicações em PHP, Python ou Node.

Na maior parte dos sites, o Nginx fica na porta da frente: ele recebe cada requisição e decide se entrega um arquivo do disco ou se repassa o pedido para a aplicação que roda atrás.

O que o Nginx faz: três papéis

A página oficial do projeto descreve o programa como servidor HTTP, proxy reverso, cache de conteúdo, balanceador de carga, proxy TCP/UDP e proxy de e-mail. Ele foi escrito originalmente por Igor Sysoev e é distribuído sob a licença BSD de 2 cláusulas. Da lista, três funções aparecem em quase toda instalação.

O primeiro papel é servir arquivo estático. Você aponta uma pasta, e o servidor entrega HTML, CSS, JavaScript e imagens a partir do disco. Um site gerado por Astro, Hugo ou Jekyll precisa só disso, sem banco e sem linguagem de servidor rodando.

O segundo é o proxy reverso. A aplicação escuta numa porta interna, como a 3000, e o servidor da frente recebe a requisição na 443, encerra o HTTPS e repassa o pedido. Para o visitante existe um endereço só. Para você, a aplicação nem precisa saber o que é certificado.

O terceiro é o balanceamento de carga. Com duas ou mais cópias da aplicação, você lista os endereços num bloco upstream, e o servidor distribui as requisições entre elas. Sem configuração extra, o método é o round-robin, um pedido para cada servidor em sequência. Também dá para escolher o servidor com menos conexões ativas (least_conn) ou fixar o cliente pelo IP (ip_hash).

Os três papéis convivem no mesmo arquivo. Um bloco entrega a pasta de imagens, outro repassa /api/ para a aplicação, e o mesmo processo cuida das duas coisas. Se o conceito de servidor ainda está nebuloso, o post sobre o que é um servidor explica a base antes deste.

Eventos contra processos: a diferença do Apache

O guia para iniciantes resume o modelo em poucas linhas. Existe um processo mestre, que lê a configuração e mantém os workers. Os workers atendem as requisições. A distribuição usa um modelo orientado a eventos, com os mecanismos próprios de cada sistema operacional.

Isso quer dizer que cada worker acompanha muitas conexões abertas ao mesmo tempo. Por isso poucos workers dão conta de um site com bastante acesso simultâneo.

O Apache nasceu com outro desenho, um processo ou uma thread por conexão. Hoje a documentação dos MPMs do Apache 2.4 diz que o padrão quase sempre é o módulo event, porque os sistemas modernos têm threads e polling seguro, o que deixa os dois servidores mais parecidos por dentro.

A diferença que mais aparece para quem administra está na configuração. O Apache aceita arquivos .htaccess, que mudam o comportamento pasta por pasta. A própria documentação do Apache recomenda evitar esse recurso quando você tem acesso ao arquivo principal, por desempenho e por segurança. No servidor da frente, a configuração fica nos arquivos centrais e só muda quando o processo mestre recarrega.

Um bloco server mínimo, comentado

Toda a configuração de um site mora num bloco server. O exemplo abaixo atende o domínio na porta 80, entrega os arquivos de uma pasta e repassa tudo que começa com /api/ para uma aplicação em localhost:3000.

# Site estático em /var/www/meusite e API na porta 3000.
server {
    # Porta HTTP e domínios que este bloco atende.
    listen 80;
    server_name meusite.com.br www.meusite.com.br;

    # Pasta dos arquivos e página inicial.
    root /var/www/meusite;
    index index.html;

    # Se o arquivo existe, entrega. Se não, devolve 404.
    location / {
        try_files $uri $uri/ =404;
    }

    # Tudo em /api/ segue para a aplicação.
    location /api/ {
        proxy_pass http://localhost:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

Três detalhes evitam dor de cabeça. O proxy_pass sem caminho no fim repassa a URI como chegou, então /api/pedidos chega à aplicação como /api/pedidos. As linhas proxy_set_header mandam o domínio original e o IP do visitante, que de outro modo chegariam como localhost:3000 e 127.0.0.1. E o try_files evita que um endereço inexistente vá parar na aplicação.

Uma regra da documentação do módulo de proxy costuma passar despercebida: os proxy_set_header só são herdados do nível de cima se o nível atual não definir nenhum. Se um location definir um cabeçalho, ele precisa repetir os outros.

HTTPS com Let's Encrypt e Certbot

O certificado gratuito vem da Let's Encrypt, e o cliente mais usado para pedi-lo é o Certbot, mantido pela EFF. As instruções oficiais do Certbot para Linux com snap pedem quatro comandos:

sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/local/bin/certbot
sudo certbot --nginx
sudo certbot renew --dry-run

O primeiro instala o Certbot e o segundo cria o atalho no caminho padrão. O terceiro emite o certificado e edita o bloco do site, que passa a escutar na 443. O último simula a renovação. Se o pacote do sistema já tiver um Certbot antigo, a página manda removê-lo antes.

A renovação automática fica a cargo do pacote, que cria um timer do systemd ou uma tarefa no cron. Você confere com systemctl list-timers. Quem prefere editar a configuração à mão usa certbot certonly com o mesmo plugin, e o Certbot só baixa o certificado.

O conceito de certificado e a diferença entre HTTP e HTTPS estão no guia de SSL e HTTPS no WordPress, que vale para qualquer site.

Docker, versão comercial e alternativas

Em contêiner, o servidor roda a partir da imagem oficial publicada no Docker Hub pelos mantenedores do projeto. O uso mais simples monta a pasta do site, somente leitura, sobre a pasta de HTML da imagem. A porta 80 do contêiner vira, por exemplo, a 8080 da máquina com -p 8080:80. Para proxy reverso, você monta também o arquivo de configuração.

O desenho comum em Docker Compose põe um contêiner de proxy na frente e as aplicações numa rede interna, sem porta publicada. A base de imagem, contêiner e Compose está em Docker para iniciantes.

Sobre versões, existe o projeto open source, gratuito, e o NGINX Plus, produto da F5. A documentação da F5 apresenta o Plus como a versão que soma recursos premium para empresas, com período de teste. Um blog ou uma API interna rodam bem na versão aberta.

Duas alternativas aparecem em projetos novos. O Caddy foi o primeiro servidor web a usar HTTPS automático e por padrão, e a configuração cabe em poucas linhas. O Traefik se descreve como proxy de aplicação open source que descobre a configuração inspecionando a infraestrutura, com Docker e Kubernetes entre as fontes. Ele compensa quando os serviços sobem e descem com frequência.

Como subir um site numa VPS Ubuntu

Este roteiro parte de uma VPS limpa com Ubuntu, acesso SSH com sudo e um domínio cujo DNS você controla. Se a dúvida ainda é qual máquina contratar, o comparativo entre VPS ou servidor físico ajuda a decidir.

1. Aponte o domínio. Crie um registro A com o IP da VPS para o domínio e para o www. Espere a propagação antes do HTTPS.
2. Instale o pacote. Rode sudo apt update && sudo apt install nginx e abra o IP no navegador. A página de boas-vindas confirma que o serviço subiu.
3. Libere as portas. Abra a 80 e a 443 no firewall da máquina e no painel do provedor. Sem a 80 aberta, o Certbot não valida o domínio.
4. Copie os arquivos. Coloque o site em /var/www/meusite e deixe a aplicação, se houver, escutando em localhost:3000.
5. Crie o bloco do site. Grave o exemplo da seção anterior em /etc/nginx/sites-available/meusite, trocando domínio e pasta, e crie um link para ele em sites-enabled, a pasta que o pacote do Ubuntu carrega.
6. Teste e recarregue. Rode sudo nginx -t para checar a sintaxe e, se passar, sudo nginx -s reload. O mestre aplica a configuração nova, e os workers antigos param de aceitar conexões e terminam as requisições em andamento antes de sair.
7. Ative o HTTPS. Rode os comandos do Certbot da seção de HTTPS e teste a renovação.
8. Leia os logs. Os arquivos access.log e error.log mostram cada requisição e cada erro. Comece por eles quando algo não responder.

Antes de trocar de servidor

Quem já tem um site rodando em Apache sem problema não precisa migrar por moda. A troca faz sentido quando a aplicação nova roda numa porta própria e precisa de alguém na frente, ou quando o .htaccess virou um labirinto que ninguém entende.

Para um projeto que começa hoje numa VPS, o servidor da frente resolve porta, certificado e arquivo estático num arquivo só. O reload do guia oficial ainda testa a sintaxe antes de aplicar: se o arquivo novo tiver erro, o processo mestre desfaz a mudança e continua com a configuração antiga.