SSD Nodes Learn 8GB de RAM — $66/ano
Guias Matt ConnorPor Matt Connor · Atualizado 2026-08-02

WireGuard, Tailscale ou Headscale: qual usar no VPS?

Entenda por que o Tailscale é WireGuard com plano de controle, o que ele resolve, quanto custa e quando escolher WireGuard ou Headscale no VPS.

WireGuard vs Tailscale: a resposta curta

WireGuard vs Tailscale não é uma escolha entre dois protocolos, porque o Tailscale é o WireGuard. O Tailscale usa a mesma criptografia e o mesmo túnel, e adiciona um plano de controle: um servidor de coordenação que troca chaves públicas, distribui endereços, atravessa NAT (tradução de endereços de rede) e aplica uma política de acesso. Você está escolhendo quanto dessa coordenação quer executar por conta própria.

Há três respostas objetivas. Use o WireGuard simples quando tiver um servidor e alguns clientes que se conectam a ele. Use o Tailscale quando quiser que todas as máquinas alcancem todas as outras sem manter um arquivo de configuração. Use o Headscale quando quiser essa malha, mas não quiser que um terceiro mantenha a lista de nós.

O que o plano de controle realmente oferece

O WireGuard puro não tem descoberta. Cada peer é um bloco de texto que você escreve manualmente: uma chave pública, uma linha AllowedIPs e uma linha Endpoint se esse peer puder ser alcançado. Adicionar uma máquina a uma rede com dez máquinas significa editar dez arquivos de configuração, porque cada lado precisa da chave do outro. Por isso, quase toda configuração do WireGuard hospedada por você usa o modelo hub-and-spoke: um servidor com um IP público e clientes que só se comunicam com ele.

Um plano de controle elimina essa edição. Cada nó se registra uma vez, recebe um endereço do intervalo 100.64.0.0/10 CGNAT (carrier grade NAT) e recebe as chaves públicas dos nós aos quais pode se conectar. O túnel continua sendo uma conexão direta do WireGuard entre dois peers, e o tráfego nunca passa pelo servidor de coordenação. O servidor transporta apenas metadados: quem existe, qual chave pertence a cada nó e quem pode se comunicar com quem.

Isso produz três resultados concretos.

Travessia de NAT. Dois laptops atrás de dois roteadores domésticos não têm um IP público entre si. O Tailscale usa STUN (session traversal utilities for NAT) para descobrir o endereço e a porta externos de cada lado. Em seguida, os dois lados enviam pacotes ao mesmo tempo, para que cada roteador veja primeiro um fluxo de saída e aceite a resposta. Quando isso falha, o tráfego recorre a um relay DERP, que é um relay criptografado operado pelo Tailscale. Seus dados continuam criptografados de ponta a ponta através do relay, porque o relay nunca possui as chaves. Execute tailscale status e cada linha de peer informará direct ou relay. Execute tailscale netcheck para ver qual relay está mais próximo e se sua rede permite UDP.

Rotação de chaves com expiração. As chaves do WireGuard nunca expiram. Uma chave emitida há três anos continua funcionando para sempre, a menos que você exclua manualmente o bloco do peer. O Tailscale expira as chaves dos nós. Em julho de 2026, o período de expiração padrão em um novo tailnet é de 180 dias. Uma máquina que não for reautenticada deixará de se conectar. Você pode desativar a expiração por dispositivo para um servidor ou um roteador de sub-rede no qual ninguém fará login.

Política em vez de roteamento. No WireGuard puro, AllowedIPs é a tabela de roteamento e a lista de controle de acesso ao mesmo tempo. Portanto, "alice pode acessar o banco de dados" precisa ser expressado como um intervalo de IP. O Tailscale mantém um arquivo de política separado, no qual as regras identificam usuários, grupos e tags. Uma regra pode dizer que tag:laptop pode acessar tag:db na porta 5432 e nada mais. Essa regra continua válida mesmo que uma máquina receba um novo endereço.

Quanto o plano de controle custa para você

O servidor de coordenação conhece sua rede. Ele armazena a chave pública de cada nó, o nome de cada nó, os endereços distribuídos e a política. Com o Tailscale hospedado, esse servidor pertence a uma empresa fora do seu controle. Essa empresa não consegue ler seus pacotes, porque as chaves privadas do WireGuard permanecem nas suas máquinas. Porém, ela consegue ver a estrutura da sua rede, e sua capacidade de conexão depende de o serviço estar disponível e de sua conta estar em situação regular.

Há um segundo custo que é fácil ignorar. O Tailscale é um daemon em cada máquina. Portanto, você precisa mantê-lo atualizado e corrigido em todas as máquinas. O WireGuard simples no Ubuntu 24.04 é um módulo do kernel fornecido pela distribuição e atualizado junto com o kernel.

O terceiro custo é a cobrança. Em julho de 2026, o plano Personal é gratuito, com dispositivos ilimitados para até 6 usuários; o Standard custa $8 por usuário por mês; e o Premium custa $18 por usuário por mês. Uma família continua no plano gratuito. Uma equipe de dez pessoas, não.

Quando o WireGuard simples é a escolha certa

Escolha o WireGuard simples quando a topologia for realmente de hub e spoke. Um VPS com um IP público, três ou quatro dispositivos que se conectam a ele e nenhum requisito de que esses dispositivos alcancem uns aos outros. A configuração cabe em uma tela, não há daemon para atualizar, nenhuma conta para perder e nenhum serviço externo entre você e o servidor.

Ele também é a escolha certa quando você quer entender a camada sobre a qual todo o restante é construído. Hospedando seu próprio WireGuard em um VPS explica a geração de chaves, wg0.conf, o encaminhamento de IP, o NAT e as falhas do handshake. Todos esses mecanismos continuam funcionando por baixo de uma tailnet. Se você ainda estiver avaliando a opção mais antiga, WireGuard vs OpenVPN aborda os quatro casos em que o OpenVPN mantém uma vantagem.

A instalação é curta:

sudo apt update && sudo apt install -y wireguard
sudo modprobe wireguard && echo ok

O WireGuard simples deixa de ser prático no momento em que cada dispositivo precisa alcançar todos os outros. Uma malha completa de N nós precisa de N vezes N menos um blocos de peer. Com seis dispositivos, são trinta blocos mantidos manualmente em sincronia, e uma entrada AllowedIPs duplicada desvia silenciosamente o tráfego do peer que a tinha primeiro, sem exibir nenhum erro.

Quando Tailscale é a escolha certa

Escolha Tailscale quando as máquinas mudam de rede. Laptops em redes de hotéis, um telefone usando dados móveis e um servidor doméstico atrás de um roteador que você não controla. Esses são exatamente os casos que o WireGuard puro trata mal, porque nenhum dos lados tem um endpoint público estável para configurar em Endpoint.

A instalação do cliente exige um comando do instalador oficial:

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up
tailscale status

tailscale up exibe uma URL. Abra a URL, faça login e a máquina será adicionada. Não é necessário copiar uma chave nem abrir uma porta de entrada, porque o daemon inicia uma conexão de saída com o servidor de coordenação e a mantém aberta. Por isso, um nó Tailscale também funciona em uma rede na qual você não controla nenhum firewall.

Duas configurações fazem a maior parte do trabalho útil depois disso. Um roteador de sub-rede anuncia uma LAN inteira na rede, para que você não precise instalar o cliente em todos os dispositivos:

echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
sudo sysctl -p /etc/sysctl.d/99-tailscale.conf
sudo tailscale set --advertise-routes=192.0.2.0/24

A rota permanece inativa até que você a aprove no console de administração. Isso é intencional: um nó não pode inserir uma rota na sua rede por conta própria. Os clientes Linux também precisam de sudo tailscale set --accept-routes, porque o Linux não aceita rotas anunciadas por padrão. Portanto, uma rota que parece aprovada no lado do servidor ainda não faz nada em um laptop Linux até que você configure isso.

Um nó de saída envia todo o tráfego de um cliente por uma máquina. Esse é o comportamento de túnel completo que as pessoas geralmente querem dizer com "uma VPN":

sudo tailscale set --advertise-exit-node

Quando o Headscale é a escolha certa

O Headscale é uma implementação de código aberto do servidor de coordenação e é executado em um VPS que você controla. Os clientes oficiais do Tailscale apontam para ele, em vez de usar o serviço hospedado:

sudo tailscale up --login-server https://headscale.example.com

Tudo no caminho de dados permanece igual. O protocolo continua sendo WireGuard, com conexão direta entre os peers quando a rede permite. O que muda é que a lista de nodes, as chaves e a política ficam em um arquivo SQLite armazenado em um disco que você controla. Ninguém de fora pode ver a topologia da sua rede, desativar sua conta ou cobrar por usuário.

A contrapartida exige trabalho. Você passa a executar um serviço HTTPS público, o que requer um nome DNS, um certificado e um reverse proxy que encaminhe corretamente as atualizações de WebSocket. Você é responsável pela disponibilidade do serviço. Se o servidor de coordenação ficar indisponível, novos nodes não poderão se registrar e os nodes existentes não poderão receber alterações. O Headscale também está abaixo da versão 1.0, e suas versões minor carregaram alterações incompatíveis. Por isso, leia o changelog antes de cada upgrade. Executando o Headscale como seu próprio servidor de controle do Tailscale aborda a instalação, config.yaml, as chaves preauth e as portas que devem ser abertas.

Há uma limitação que costuma ser percebida tarde. O Headscale não inclui a rede global de relay do Tailscale. Quando dois peers não conseguem se conectar diretamente, você precisa ativar o relay integrado no seu próprio servidor ou apontar a configuração para outro relay. Nesse caso, o relay fica em uma única máquina e em uma única região, em vez de fazer parte de uma frota mundial. Peers do outro lado do planeta sofrem com essa diferença.

Como decidir em uma única etapa

Pergunte quantas máquinas precisam se comunicar. Se a resposta for que todas apenas se comunicam com o servidor, o WireGuard simples exige menos software para obter o mesmo resultado.

Pergunte se as máquinas têm endereços públicos estáveis. Se a maioria estiver atrás de NAT que você não controla, você precisará de um plano de controle, porque a perfuração de NAT é a parte difícil e não vale a pena recriá-la.

Pergunte quem pode conhecer a topologia da sua rede. Se a resposta excluir empresas externas, ou se o número de usuários tornar a cobrança por usuário inviável, execute o Headscale e aceite que você passará a operar o servidor de controle.

Você pode mudar de decisão com baixo custo. Como o plano de dados usa o mesmo protocolo nas três opções, passar do WireGuard simples para uma malha coordenada exige apenas instalar o cliente, não redesenhar a solução. Passar do Tailscale para o Headscale exige registrar novamente cada nó em um servidor de login diferente.

O que nenhum dos três oferece

Nenhum deles é um firewall. Um túnel decide quais pacotes são transportados, não quais serviços ficam escutando. Um servidor acessível pelo túnel continua acessível pela internet em qualquer porta que você tenha deixado aberta. Portanto, mantenha as regras do firewall UFW no VPS funcionando. O arquivo de políticas do Tailscale restringe o que outros nós podem acessar. Ele não faz nada na interface pública.

Nenhum deles fornece autenticação por serviço. Nenhum deles registra em uma trilha de auditoria o que um usuário fez depois de se conectar. Trate os três como transporte e implemente as verificações de login na aplicação.

FAQ

Tailscale é apenas WireGuard com etapas adicionais?

Tailscale usa o protocolo WireGuard no caminho de dados, portanto a criptografia e o túnel são os mesmos. O que ele adiciona é a coordenação: troca de chaves, atribuição de endereços, travessia de NAT com relays STUN e DERP, expiração de chaves e um arquivo de política que identifica usuários em vez de intervalos de IP. No WireGuard puro, essas tarefas ficam sob sua responsabilidade. Elas se tornam complexas quando as máquinas mudam de rede.

Meu tráfego passa pelos servidores do Tailscale?

Normalmente, não. Os peers se conectam diretamente depois que o servidor de coordenação os apresenta, e tailscale status mostra direct nessas linhas de peers. Quando não é possível estabelecer um caminho direto, o tráfego usa um relay DERP, e a linha exibe relay. Mesmo nesse caso, o relay transporta pacotes criptografados e não armazena suas chaves privadas do WireGuard. Portanto, ele não pode ler o conteúdo. Execute tailscale netcheck para verificar se sua rede está bloqueando o UDP necessário para conexões diretas.

Posso usar o Headscale com os aplicativos oficiais do Tailscale?

Sim. O Headscale usa o mesmo protocolo de controle, portanto os clientes oficiais ingressam com sudo tailscale up --login-server https://headscale.example.com. Também é possível configurar os aplicativos para desktop e dispositivos móveis para usar um servidor de login personalizado. A configuração fica em um local diferente em cada plataforma, e os aplicativos móveis são os mais propensos a exigir uma versão específica. Teste um telefone antes de migrar toda a rede.

Ainda preciso abrir portas para o Tailscale ou o Headscale?

Um cliente Tailscale não precisa de uma porta de entrada, porque inicia a conexão com o servidor de coordenação e mantém essa conexão aberta. Um servidor Headscale auto-hospedado precisa de portas de entrada: 443 para o protocolo de controle, 80 se você usar um desafio de certificado HTTP-01 e 3478/udp somente quando habilitar o relay integrado. O WireGuard puro precisa que sua porta UDP de escuta, normalmente 51820, esteja aberta no servidor e em qualquer firewall de rede separado fornecido pelo seu provedor.

Qual dos três é mais rápido?

A taxa de transferência é a mesma, porque os três transportam pacotes com WireGuard. A diferença aparece na configuração da conexão e na qualidade do caminho. O WireGuard puro, com um Endpoint correto, conecta-se diretamente todas as vezes. Tailscale e Headscale conectam-se diretamente na maior parte do tempo e usam um relay quando a rede bloqueia a perfuração de NAT. Um caminho por relay adiciona latência. Meça seu próprio caminho com tailscale ping <node>, que informa se a rota é direta ou usa relay, ou com iperf3 através do túnel.