Os dois projetos respondem à mesma pergunta (como gerir uma rede mesh privada sem pagar a uma empresa para guardar o mapa) e respondem-lhe de formas quase opostas. Escolher entre eles não é realmente uma decisão de desempenho. É uma decisão sobre o software cliente de que está disposto a depender, e sobre a falha que prefere explicar aos seus colegas.
Em qualquer dos casos precisa de uma máquina pública: o servidor de controlo do Headscale ou o lighthouse do Nebula tem de estar num host com um IPv4 público acessível, o que um pequeno VPS como um Contabo Cloud VPS 4 (link de afiliado) assegura por 5,50 € por mês num compromisso de 24 meses.
Está a comparar o Headscale com o próprio serviço alojado? A nossa comparação Tailscale vs Headscale enumera as funcionalidades em falta, o custo a 3 anos e um veredicto por dimensão de equipa.
A versão numa frase
O Headscale substitui o servidor de coordenação do Tailscale por um gerido por si, mantendo os clientes oficiais e o plano de dados WireGuard. O Nebula substitui tudo, com o seu próprio protocolo, o seu próprio binário e uma autoridade de certificação que é o próprio utilizador a operar, e é por isso que comparar o Nebula com o próprio WireGuard é comparar uma rede inteira com um protocolo de túnel.
Ambos são projetos consolidados e não experimentais, e ambos têm licenças permissivas, o que conta se vai apostar a sua infraestrutura neles: o Nebula foi aberto pela Slack em novembro de 2019 sob licença MIT, e o Headscale nasceu em junho de 2020 e está sob BSD-3-Clause.
Note-se que ambos são meshes. Se a pergunta por trás da sua é se deve sequer usar uma mesh em vez de um único servidor a que tudo se liga, essa é outra comparação: Headscale vs OpenVPN aborda-a como uma questão de topologia e não de funcionalidades.
Onde reside realmente a confiança
Esta é a diferença que sobrevive a qualquer comparação de funcionalidades.
Numa rede Headscale, uma máquina entra ao autenticar-se no seu servidor de controlo. O servidor é seu, portanto a decisão é sua, mas o cliente é software mantido pela Tailscale Inc., apontado para o seu servidor através da substituição do URL de login. Este arranjo funciona há anos, mas não é contratual.
Numa rede Nebula, uma máquina entra porque detém um certificado assinado pela sua autoridade de certificação. É o utilizador que gera essa CA, e ela nunca precisa de sair da máquina onde foi gerada. Nada se inscreve sem a sua assinatura. O custo é que o ciclo de vida dos certificados (emissão, distribuição, expiração, revogação) passa a ser tarefa sua desde o primeiro dia, e não algo em que vai crescendo. Esse custo tem uma data associada: nebula-cert ca usa por defeito uma validade de 8760 horas, um ano, pelo que uma rede sem supervisão deixa de aceitar inscrições exatamente doze meses depois de ter sido configurada, a menos que alguém tenha renovado a CA.
Nenhum dos modelos é mais seguro em abstrato. Um pede-lhe que confie na tolerância continuada de um fornecedor de clientes; o outro pede-lhe que seja competente a gerir uma CA.
Como cada um encontra os seus pares
O Nebula usa lighthouses: nós com um endereço estável e acessível cuja função é saber onde está cada um e apresentar os pares uns aos outros. São nós Nebula comuns com uma flag ativada (am_lighthouse: true), transportam muito pouco tráfego e normalmente corre-se dois em instâncias VPS baratas. O Nebula escuta por defeito na porta UDP 4242, e a configuração de exemplo indica que um lighthouse deve ter a porta fixa, enquanto os nós móveis ficam melhor com a porta 0, que pede ao sistema operativo uma porta dinâmica.
O Headscale desempenha ele próprio o papel de coordenação, distribuindo as chaves e o mapa da rede, com relays DERP para o tráfego que não consegue estabelecer um caminho direto. Pode correr o seu próprio DERP em vez de usar os públicos.
As arquiteturas assemelham-se. O que difere é a forma operacional: o lighthouse do Nebula é um nó da mesh, o plano de controlo do Headscale é um serviço com uma base de dados por trás.
Regras de firewall, e onde são aplicadas
O Nebula coloca uma firewall de host na própria configuração do nó. Cada host declara que ligações de entrada aceita, expressas em termos de grupos de certificados e não de endereços IP. A aplicação é local, o que significa que um plano de controlo comprometido não consegue abrir um host silenciosamente.
O Headscale exprime o controlo de acesso como ACLs compatíveis com o Tailscale, definidas centralmente e distribuídas. Um único ficheiro descreve toda a rede, o que é muito mais fácil de auditar e de compreender, e que coloca mais peso na correção desse ficheiro.
Uma política centralizada é mais legível; uma política distribuída é mais difícil de contornar a partir de um único ponto.
Uma forma prática de escolher
| Se isto se aplica à sua frota | Incline-se para |
|---|---|
| Portáteis e telemóveis usados por pessoas que não deviam gerir certificados | Headscale |
| Servidores, contentores e appliances que já configura de forma declarativa | Nebula |
| Quer MagicDNS, exit nodes e um processo de login familiar | Headscale |
| Quer zero dependência do roadmap de clientes de qualquer fornecedor | Nebula |
| O seu instinto diz que um plano de controlo comprometido não pode abrir hosts | Nebula |
| O seu instinto diz que um único ficheiro de política auditável vale mais do que muitos | Headscale |
Ambos acabam no mesmo tipo de servidor: o Headscale precisa de um pequeno VPS sempre ligado com IP público e um domínio, e o Nebula precisa de um para o seu lighthouse. Se a tabela apontar para o Headscale, o nosso gerador de configuração Headscale gratuito escreve o config.yaml, o ficheiro Docker Compose e o bloco de reverse proxy para esse VPS, e um Contabo Cloud VPS 4 aparece a partir de 5,50 €/mês em contabo.com (verificado a 17 out. 2026). Se preferir um host norte-americano com garantia de reembolso de 30 dias, o Ultahost VPS Basic custa 5,52 $ por mês num compromisso de 24 meses (1 GB de RAM, IPv4 dedicado, consultado a 21 de outubro de 2026), o suficiente para um servidor Headscale de uma pequena equipa.
O que não afirmaríamos
As comparações de débito entre os dois circulam muito e medem sobretudo a máquina em que foram feitas. O WireGuard corre normalmente no kernel Linux, enquanto o transporte do Nebula corre em espaço de utilizador, o que tende a favorecer o WireGuard num servidor Linux; mas em ligações saturadas, noutros sistemas operativos ou em CPUs modestos, essa vantagem dilui-se muitas vezes no ruído. Se o débito for realmente o seu fator decisivo, o único número que vale a pena ter é o que mede no seu próprio percurso, com o seu próprio hardware, na rota que o seu tráfego realmente segue.
★ Datacenter GDPR em Nuremberg · ✓ IPv4 dedicado incluído · porta de 200 Mbit/s
Aloje a sua VPN no seu próprio VPS → ContaboAcesso root completo · IPv4 público · escolha a sua região→
