Headscale vs WireGuard (2026): um é o túnel, o outro distribui as chaves

Divulgação de afiliados - Este artigo contém um link de afiliado da Contabo. Se encomendar um VPS através do nosso link, ganhamos uma comissão sem custo adicional para si. Os factos sobre o Headscale e o WireGuard abaixo foram lidos na documentação oficial de cada projeto a 8 de outubro de 2026.

Resposta rápida: «Headscale vs WireGuard» não é uma escolha entre dois protocolos VPN. O WireGuard é o túnel. O Headscale é um servidor de controlo que diz aos clientes Tailscale que chaves WireGuard, que endereços e que rotas usar, para que não tenha de os escrever à mão. Fique com o WireGuard simples se tem um servidor e meia dúzia de dispositivos que só precisam de chegar a esse servidor. Escolha o Headscale se quer que muitos dispositivos cheguem uns aos outros, através de NAT, com nomes, regras de acesso e nenhum ficheiro de configuração para editar em cada máquina.

Duas camadas, não dois rivais

O projeto WireGuard resume o que faz numa frase: encapsula de forma segura pacotes IP sobre UDP. Adiciona-se uma interface, dá-se-lhe a chave privada e as chaves públicas dos peers, e os pacotes circulam. A mesma página é igualmente clara sobre o que deixa de fora: todas as questões de distribuição de chaves e de configurações enviadas aos clientes estão fora do âmbito do WireGuard ("out of scope", no original).

Essa camada em falta é exatamente o que o Headscale fornece. O seu README define-o como uma implementação open source e auto-alojada do servidor de controlo do Tailscale, e descreve esse servidor como o ponto de troca das chaves públicas WireGuard dos nós da rede: atribui os endereços IP dos clientes e expõe as rotas que eles anunciam.

A comparação real é, portanto, esta:

• WireGuard simples: o plano de controlo é o utilizador. Gera as chaves, escolhe os endereços, escreve cada bloco [Peer] e copia-o para as duas pontas.
• Headscale: o plano de controlo é um serviço que aloja. Os dispositivos correm o cliente Tailscale, iniciam sessão no seu servidor e recebem os peers automaticamente.

Em ambos os casos, o tráfego entre as suas máquinas é cifrado com o protocolo WireGuard.

O que o WireGuard simples lhe pede

Uma rede WireGuard é definida por ficheiros de configuração. Cada peer é uma chave pública mais os endereços de túnel que está autorizado a usar, aquilo a que o projeto chama Cryptokey Routing:

[Interface]
PrivateKey = <server-private-key>
Address = 10.8.0.1/24
ListenPort = 51820

[Peer]
PublicKey = <laptop-public-key>
AllowedIPs = 10.8.0.2/32

Para um servidor central com poucos clientes, isto é curto e transparente, e nada mais corre além da própria interface. O nosso guia de WireGuard na Contabo cobre essa instalação de uma ponta à outra, e o wg-easy acrescenta-lhe uma interface web sem mudar o modelo.

O custo aparece quando a rede cresce numa direção específica:

• Cada dispositivo adicionado obriga a editar pelo menos dois ficheiros. O novo peer precisa de conhecer o servidor, o servidor precisa de conhecer o novo peer.
• Uma malha completa multiplica isso. Se 10 dispositivos tiverem de chegar diretamente a cada um dos outros 9, são 45 pares para descrever, dos dois lados.
• Alguém tem de estar acessível. Um túnel estabelece-se para um endpoint, um endereço IP e uma porta UDP. Dois dispositivos que estejam ambos atrás de NAT não têm esse endpoint um para o outro: é a situação descrita no nosso guia de WireGuard atrás de CGNAT. A resposta habitual é fazer passar tudo pelo servidor.
• Os nomes e as regras de acesso ficam por sua conta. O WireGuard dá-lhe endereços. O DNS e a filtragem entre peers são trabalho à parte.

Nada disto é um defeito. É o âmbito que o projeto escolheu, e para um único servidor é uma vantagem: menos peças móveis, uma só porta UDP.

O que o Headscale acrescenta

Com o Headscale, o trabalho por dispositivo reduz-se a um comando. No servidor, cria um utilizador e uma chave pré-autenticada:

headscale users create <USER>
headscale preauthkeys create --user <USER_ID>

e em cada dispositivo, com o cliente Tailscale instalado:

tailscale up --login-server <YOUR_HEADSCALE_URL> --authkey <YOUR_AUTH_KEY>

O dispositivo recebe então o seu endereço e os seus peers a partir do seu servidor. A lista de funcionalidades na documentação do Headscale inclui:

• MagicDNS e split DNS, para que as máquinas tenham nomes em vez de endereços.
• ACL num ficheiro de política central, em vez de regras de firewall em cada host.
• Subnet routers e exit nodes, para chegar a uma LAN inteira ou fazer sair todo o tráfego por um nó.
• Um servidor DERP incorporado. A documentação descreve o DERP como um relay usado sobretudo quando não é possível estabelecer uma ligação direta entre dois nós. Vem desativado por omissão.
• Registo através de OpenID Connect, além das chaves pré-autenticadas.

O que a documentação do Headscale diz que ele não é

É a parte que os comparativos costumam saltar, e o próprio projeto escreve-a sem rodeios.

• Âmbito. O README indica que o Headscale cobre um âmbito restrito: uma única rede Tailscale (tailnet), adequada a uso pessoal ou a uma pequena organização open source.
• Escala. As perguntas frequentes dizem que o Headscale não é software empresarial ("not enterprise software") e que o desempenho não é uma prioridade. Estimam que o servidor consegue provavelmente gerir centenas de dispositivos quando pouco muda na rede.
• Funcionalidades em falta. Funnel, Serve e os registos de fluxos de rede não estão assinalados na lista de funcionalidades.
• Implementação. O README diz que os mantenedores não suportam nem incentivam o uso de reverse proxies e de contentores para correr o Headscale. O suporte oficial abrange os binários e os pacotes DEB. As imagens de contentor são construídas por conveniência.
• Clientes. Os dispositivos usam o cliente Tailscale. O projeto procura suportar as suas 10 últimas versões, em Linux, OpenBSD, FreeBSD, Windows, Android, macOS, iOS e tvOS.
• Base de dados. Recomenda-se SQLite. O PostgreSQL continua a ser suportado, mas é descrito como estando em "maintenance mode".

O Headscale é publicado sob a licença BSD-3-Clause. A versão mais recente no GitHub à data em que esta página foi escrita é a v0.29.4, publicada a 23 de setembro de 2026.

O que cada um precisa no servidor

Fontes: wireguard.com, o README do Headscale e a documentação do Headscale (requisitos, funcionalidades, perguntas frequentes, DERP), lidos a 8 de outubro de 2026.

Ambos precisam da mesma base: uma pequena máquina Linux com um endereço IP público que se mantenha online. Nenhum dos dois projetos publica um mínimo de RAM ou de CPU nas páginas aqui citadas, e um VPS de entrada de gama é a casa habitual de qualquer um deles.

Ver os planos atuais do Contabo Cloud VPS

Qual deve usar?

Se a última linha se aproxima do seu caso, Tailscale vs Headscale compara o serviço alojado e o servidor auto-alojado, e Tailscale vs WireGuard auto-alojado trata a mesma questão do lado do WireGuard.

Pode usar os dois?

Sim, e é uma configuração razoável. Uma interface WireGuard comum na sua própria porta UDP e um serviço Headscale na porta TCP 443 não disputam a mesma porta. Uma divisão habitual: um túnel WireGuard para uma ligação fixa, como a ligação site-to-site entre duas redes, e o Headscale para os dispositivos pessoais que andam de um lado para o outro. O preço são dois sistemas para manter atualizados, por isso faça-o apenas se cada um resolver um problema que o outro não resolve.

Resumo

O WireGuard é um protocolo e deixa a distribuição de chaves consigo. O Headscale é uma forma de tratar dessa distribuição por conta própria, com o cliente Tailscale, num servidor que controla. Comece pelo WireGuard simples quando um servidor central chega. Passe para o Headscale quando os ficheiros de configuração se tornarem a principal coisa que mantém, e leia primeiro a documentação: é explícita quanto a ter sido feito para redes pessoais e pequenos grupos. A instalação passo a passo está no nosso guia do plano de controlo Headscale.