Caddy vs nginx: HTTPS, configuração e qual escolher
Caddy vs nginx
Caddy vs nginx: HTTPS automático e configs lado a lado | We.Inc
Caddy vs nginx em tarefas reais: HTTPS automático, sites estáticos, reverse proxy, balanceamento de carga e WebSockets, com um gerador que escreve as duas configs para o seu domínio.
A grande diferença são os certificados. O Caddy serve todo site em HTTPS por padrão, obtendo e renovando certificados do Let's Encrypt ou da ZeroSSL e redirecionando o HTTP para você. O nginx precisa de arquivos de certificado que você fornece, vindos de um cliente ACME ou do módulo acme separado. Caddyfiles são mais curtos; o nginx oferece controle mais fino e um histórico muito mais longo.
Caddy e nginx comparados em tarefas do dia a dia
Tarefa
Caddy
Certificados HTTPS
Automáticos para qualquer domínio público na config
Você aponta ssl_certificate para arquivos, ou adiciona o ngx_http_acme_module separado
Redirecionamento de HTTP para HTTPS
Automático
Um server block na porta 80 que retorna 301
Compressão
encode zstd gzip
gzip on
Reverse proxy
reverse_proxy localhost:3000
proxy_pass em um location, mais headers
WebSockets pelo proxy
Tratados automaticamente
Repasse os headers Upgrade e Connection
Padrão de balanceamento de carga
round robin
Health checks ativos
health_uri no reverse_proxy
health_check só na edição comercial
Verificar e recarregar a config
caddy validate, caddy reload
nginx -t, nginx -s reload
A maioria das comparações para nos recursos. Aqui você digita um domínio e uma porta da aplicação e recebe as duas configs, para ver exatamente quanto cada servidor pede que você escreva para o mesmo resultado. Abaixo do gerador há trechos lado a lado para as tarefas mais comuns e depois notas honestas sobre onde cada um se encaixa.
Informe seu domínio e escolha se o servidor deve entregar arquivos estáticos ou encaminhar requisições para uma aplicação.
Ligue e desligue a compressão e o redirecionamento do www para ver quais linhas cada servidor precisa.
Copie o Caddyfile para junto do binário caddy e rode caddy run, ou copie o bloco nginx para um arquivo na sua pasta de sites.
No nginx, obtenha primeiro um certificado com o seu cliente ACME e atualize os dois caminhos de certificado antes de recarregar.
O Caddy só consegue obter um certificado público se o registro A ou AAAA do domínio apontar para a máquina e as portas 80 e 443 estiverem acessíveis de fora.
Dê ao Caddy um armazenamento persistente e gravável para o diretório de dados. Em containers, monte um volume, senão ele pede novos certificados a cada reinício.
Rode caddy fmt em Caddyfiles editados à mão; ele organiza a indentação sempre do mesmo jeito.
No nginx, teste com nginx -t antes de cada reload. Ele verifica a sintaxe e também tenta abrir os arquivos que a config referencia, como os caminhos dos certificados.
Desde o Caddy 2.8 a diretiva root não precisa mais do matcher *, então root /srv funciona. Guias antigos que escrevem root * /srv continuam válidos.
Perguntas frequentes
O Caddy substitui o nginx diretamente?
Para sites estáticos, reverse proxies e balanceamento de carga simples, geralmente sim, e a config fica mais curta. Instalações nginx grandes que usam muitos módulos de terceiros, lógica complexa de map e rewrite ou cache ajustado podem não ter um equivalente direto no Caddy, então converta e teste um site de cada vez.
O nginx já faz HTTPS automático?
O nginx tem um ngx_http_acme_module que implementa ACME, mas ele não vem compilado por padrão. Você o instala como um módulo dinâmico separado (o pacote nginx-module-acme) e configura um emissor. Sem ele, os certificados vêm de um cliente externo.
O Caddy consegue me dar HTTPS no localhost?
Sim. Para localhost e nomes internos, o Caddy cria a própria autoridade certificadora local e emite certificados a partir dela. Seu sistema pode pedir uma vez para confiar no certificado raiz dela.
Qual tem melhor desempenho?
Não publicamos números de velocidade porque eles variam com o hardware, as configurações de TLS e a carga. Os dois dão conta tranquilamente de sites e APIs típicos. Se throughput bruto importa para você, faça benchmark do seu próprio padrão de tráfego nos seus próprios servidores.
O Caddy suporta balanceamento de carga e health checks?
Sim. Liste vários upstreams no reverse_proxy, escolha uma lb_policy como round_robin ou least_conn e adicione health_uri para checks ativos ou fail_duration para os passivos. Sem uma política, o Caddy escolhe os upstreams aleatoriamente.
O que o HTTPS automático cobre de verdade
Quando um Caddyfile cita um domínio público, o Caddy obtém um certificado via ACME, serve o site na porta 443, redireciona a porta 80 para HTTPS e renova o certificado em segundo plano. Se um emissor falha, ele tenta de novo e pode recorrer a outro. Nada na config menciona TLS, a não ser que você queira mudar os padrões.
O nginx deixa isso com você. A configuração usual é um cliente ACME que grava os arquivos de certificado e recarrega o nginx depois de renová-los, ou o módulo acme mais recente, que você instala de propósito.
Quando o nginx é a melhor escolha
O nginx está em toda parte: em distribuições, imagens de container e painéis de hospedagem, com documentação e respostas para quase qualquer situação. Equipes que já o usam, dependem de módulos específicos ou precisam de controle fino sobre buffering e cache têm pouco motivo para mudar.
Quando o Caddy é a melhor escolha
Equipes pequenas, projetos paralelos e muitos domínios são os que mais ganham por não gerenciar certificados. O formato nativo de config dele é JSON, que o caddy adapt produz a partir de um Caddyfile, e o caddy reload envia uma nova config ao processo em execução pela API de administração, sem downtime.
Balanceando carga entre três servidores de aplicação
Caddyfile
Round robin entre três backends, com health checks em segundo plano contra /healthz.
Round robin é o padrão. O nginx open source só verifica a saúde de forma passiva, pelas requisições que falham.
Fazendo proxy de WebSockets
Caddyfile
O reverse_proxy faz o upgrade e mantém um túnel bidirecional aberto sem linhas extras.
Os headers Upgrade e Connection precisam ser repassados explicitamente; proxy_http_version 1.1 é necessário antes do nginx 1.29.7.