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

example.com {
    reverse_proxy localhost:3000
}

nginx.conf

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    location / {
        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;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

server {
    listen 80;
    server_name example.com;
    return 301 https://$host$request_uri;
}

As linhas de TLS no bloco do Nginx presumem que o Certbot já foi executado. Para um upstream HTTP como o acima, o Caddy passa o cabeçalho Host recebido adiante e define X-Forwarded-For, X-Forwarded-Proto, e X-Forwarded-Host por padrão. Com o Nginx, você normalmente adiciona os cabeçalhos de proxy explicitamente quando o upstream precisa do host original, do esquema e da cadeia de endereços do cliente. Esse é o trade-off em miniatura: o Caddy vem com padrões de proxy práticos, enquanto o Nginx torna mais desse comportamento explícito.

Servimento de arquivos estáticos:

Caddyfile

example.com {
    root * /var/www
    file_server
}

nginx.conf

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    root /var/www;
    index index.html;
    location / {
        try_files $uri $uri/ =404;
    }
}

Autenticação básica, protegendo tudo por trás de um nome de usuário e uma senha:

Caddyfile

example.com {
    basic_auth {
        Bob $2a$14$Zkx19XLiW6VYouLHR5NmfOFU0z2GTNmpkT/5qqR7hx4IjWJPDhjvG
    }
    reverse_proxy localhost:3000
}

nginx.conf

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    auth_basic           "Restricted";
    auth_basic_user_file /etc/nginx/.htpasswd;
    location / {
        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;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

As duas ferramentas geram o hash da senha fora do fluxo. O Caddy usa caddy hash-password; o Nginx usa htpasswd para construir o arquivo .htpasswd. A diretiva é basic_auth no Caddy atual, aliás. Ela era basicauth até a v2.8.0 renomeá-la, conforme observado na documentação do basic_auth do Caddy, e tutoriais antigos ainda fazem as pessoas tropeçarem nisso.

Dica profissional: Aquele hash no Caddyfile não é a senha. É a saída bcrypt de caddy hash-password. Execute o comando, cole o que ele imprimir. O Caddy recusa senhas em texto puro na configuração, o que é o padrão correto e uma pequena surpresa na primeira vez.

As configurações defendem seu próprio argumento. O Caddy reúne o TLS, cabeçalhos de proxy sensatos e um redirecionamento em poucas linhas; o Nginx é explícito e verboso e coloca cada botão na sua mão. Se você passou anos no Nginx, a verbosidade é memória muscular e o controle é o ponto. Se não passou, o Caddyfile é uma configuração que você consegue guardar na cabeça. A questão prática é simples: a configuração do Caddy é mais fácil de ler à primeira vista, enquanto o Nginx dá a você mais controle explícito.

Desempenho e memória: lendo os benchmarks com cuidado

Os testes publicados apontam na mesma direção geral: o Nginx normalmente usa menos memória e muitas vezes lidera na vazão bruta, mas o tamanho dessa vantagem depende fortemente do ambiente.

In um teste de terceiros em uma VM de quatro núcleos, o Nginx alcançou aproximadamente 48.000 requisições por segundo, em comparação com cerca de 42.000 para o Caddy. O mesmo teste relatou uma latência p99 de HTTPS de 2,1 ms para o Nginx e 2,4 ms para o Caddy. Trate esses valores como resultados de uma única configuração, e não como uma margem de desempenho universal.

Os intervalos de memória na tabela de comparação vêm de um teste de VPS separado. Outro teste sintético com 50.000 conexões simultâneas relatou 145 MB para o Nginx e 520 MB para o Caddy, mas esse teste usou condições de hardware e de carga de trabalho substancialmente diferentes. Seus números absolutos não devem ser comparados diretamente com os números de VPS acima.

A conclusão confiável é mais estreita: o Nginx geralmente tem a menor pegada de memória e tende a liderar sob cargas de trabalho de alta vazão ou alta concorrência. Para um proxy reverso comum em um VPS de pequeno a médio porte, os dois costumam ser rápidos o suficiente, então a simplicidade operacional é muitas vezes o fator decisivo mais útil.

Conclusão da seção: escolha com base na operação, a menos que seu servidor tenha restrição de memória ou que seus próprios testes de carga mostrem que a vazão do proxy é o gargalo.

O detalhe do certificado curinga (o Caddy nem sempre é de configuração zero)

O Caddy consegue automatizar certificados curinga, mas não com seus desafios HTTP-01 ou TLS-ALPN-01 padrão. Um certificado para *.example.com exige validação DNS-01, que o Let's Encrypt exige para certificados curinga. Isso significa um plugin de provedor de DNS (embutido no seu binário do Caddy via xcaddy) mais um token de API para o seu host de DNS, configurado no bloco tls. Não é a história de digitar uma linha e ir embora que o Caddy divulga.

Isso pega os usuários de homelab que colocam muitos serviços sob um domínio real que controlam, como *.home.example.com, e presumem que a emissão de curinga é tão automática quanto app.example.com. Para nomes puramente internos como *.homelab.internal, trate isso como território de PKI local/interno, não como um curinga público do Let's Encrypt. Para ser preciso: o Caddy faz curingas bem, ele só não os faz com os desafios padrão, e a configuração é um degrau acima do caso de domínio único. O Nginx está no mesmo barco aqui, já que o requisito de DNS-01 vem do Let's Encrypt, não do servidor.

Se você quer uma GUI: Nginx Proxy Manager (um breve aparte)

O Nginx Proxy Manager é um bicho diferente das duas ferramentas acima, e merece um parágrafo porque o nome confunde as pessoas. O NPM é um invólucro de GUI sobre o Nginx: ele gerencia regras de proxy reverso e certificados Let's Encrypt por meio de uma interface web na port 81. Ele não é o Nginx core, e não é configurado do jeito que o Nginx core é.

O trade-off é o de sempre, clicar versus configurar. O NPM é o botão fácil até você sair do caminho feliz. Sua configuração é gerenciada por meio de um banco de dados da aplicação em vez de um único arquivo de configuração editado à mão. A configuração Docker padrão usa SQLite, enquanto MySQL/MariaDB e PostgreSQL são opções de banco de dados externo suportadas. Essa diferença também afeta a portabilidade: uma configuração do Caddy muitas vezes pode ser movida copiando um único Caddyfile, enquanto uma implantação do Nginx Proxy Manager exige que seus dados da aplicação e banco de dados sejam preservados. O NPM é uma boa escolha se você realmente prefere clicar a editar e sua configuração permanece simples. É a escolha errada para um fluxo de trabalho de infraestrutura como código.

Migrando do Nginx para o Caddy (o que se converte e o que não)

Se você já está no Nginx e está avaliando a mudança, comece diminuindo suas expectativas quanto à automação: existe um adaptador de configuração NGINX no Caddy, mas ele é incompleto e não deve ser tratado como um caminho de migração confiável de uma tacada só. Uma migração do Nginx para o Caddy é, na maior parte, uma reescrita manual, e a maior parte dela fica mais curta.

O que se converte e fica mais simples, segundo o guia de conversão da comunidade do Caddy:

• Para upstreams HTTP, o reverse_proxy passa o cabeçalho Host recebido adiante e define os cabeçalhos X-Forwarded-* padrão por padrão, então a maioria dessas proxy_set_header linhas desaparece.
• O PHP encolhe de um bloco de location com try_files mais fastcgi_pass mais uma pilha de parâmetros para uma única diretiva php_fastcgi .
• O tratamento de WebSocket é automático no Caddy v2. Se um tutorial mandar você adicionar uma diretiva websocket separada, é um resquício do Caddy v1. Ignore-o.

O que não se converte automaticamente: qualquer coisa ligada a um módulo específico do Nginx que o Caddy não tem, lógica complexa de rewrite e de location que você vai precisar repensar em vez de portar, e configurações de certificado curinga, que o levam de volta à configuração de desafio de DNS da seção acima. Reserve tempo para os módulos e para os rewrites; o resto costuma ser uma redução líquida de linhas.

Qual deles você deve instalar? (A decisão)

Você viu as configurações, os números, o detalhe do curinga e o custo da migração, então aqui está a conclusão. Instale o Caddy se você é um dev solo ou uma equipe pequena, se esta é uma implantação em VPS novo, se você quer TLS do tipo configure e esqueça, se você está rodando Docker com roteamento simples ou se você só quer uma configuração que cabe na memória muscular. Essa é a maioria das pessoas que estão lendo isto.

Instale o Nginx se você precisa de controle granular ou de um módulo específico do ecossistema maduro dele, se você está espremendo desempenho de um servidor com restrição de memória, se você está servindo arquivos estáticos em alta concorrência, ou se sua equipe já tem profunda experiência com Nginx e uma pilha de configurações funcionando. Esses são motivos sólidos, e se um deles é o seu, o Nginx é a escolha certa. Este não é um caso em que a ferramenta mais antiga é a ferramenta errada.

Qualquer que seja a sua escolha, o próximo passo é colocá-la na máquina. Ambos Caddy e Nginx estão disponíveis como implantações de um clique no nosso marketplace, então você pode pular o trabalho de instalação e ir direto ao Caddyfile ou ao bloco de servidor. Um VPS de 1 GB é um ponto de partida razoável para uma implantação de site único com pouco tráfego, mas dimensione o servidor para a aplicação e o tráfego por trás do proxy, e não só para o proxy. Se você está usando o Caddy como a porta de entrada para serviços auto-hospedados, ele pode ficar na frente de uma pilha de monitoramento com Prometheus e Grafana ou de uma implantação do Uptime Kuma sem exigir ferramentas de TLS separadas.

Conclusão da seção: escolha o Caddy a menos que você tenha um motivo específico que aponte para o Nginx.

Perguntas frequentes