Como hospedar seu próprio servidor Tailscale com headscale

O que é o headscale

O headscale é uma implementação autoalojada do servidor de controlo do Tailscale. Assim, a máquina que coordena a sua rede privada é um VPS que lhe pertence. É um projeto comunitário e não é operado pela Tailscale Inc. Cada máquina continua a executar o cliente oficial tailscale, apontado para o seu servidor com uma única flag, --login-server.

O servidor de controlo é o componente que sabe quem pertence à rede. Atribui a cada nó um endereço de 100.64.0.0/10, distribui chaves públicas e informa os nós sobre como se podem encontrar. Os túneis continuam a usar WireGuard e são estabelecidos diretamente entre os nós. O tráfego entre duas das suas máquinas não passa pelo servidor headscale, exceto quando não é possível criar um caminho direto e os nós recorrem a um relay. Ao assumir essa função de coordenação, passa a controlar quem a desempenha, mas não altera o que ela pode fazer. Por isso, antes de considerar esta mudança uma melhoria de segurança por si só, é importante compreender a que um servidor de controlo pode e não pode aceder neste modelo.

O Headscale disponibiliza uma tailnet (uma rede Tailscale) por instância. O projeto considera este modelo adequado para uso pessoal ou para uma organização pequena. Com três ou quatro máquinas, uma VPN WireGuard simples num VPS que lhe pertença exige menos software para manter e oferece menos componentes que possam falhar. O Headscale torna-se vantajoso quando já não quer escrever manualmente um bloco [Peer] para cada portátil novo. O custo é muitas vezes o motivo que leva as pessoas a pesquisar estas opções. Por isso, vale a pena ler o que o plano gratuito alojado inclui realmente antes de assumir a gestão de um servidor, porque um pequeno conjunto de máquinas pessoais normalmente cabe nesse plano. Se já ultrapassou esse limite, faça as contas com base em quanto custam os planos pagos por utilizador e por recurso etiquetado, porque os dispositivos dos utilizadores são ilimitados, enquanto os recursos etiquetados têm limites e custos próprios. Se pretende um plano de controlo autoalojado, mas prefere ter o seu próprio cliente e uma interface web para gerir os peers, em vez de uma substituição direta do Tailscale, o NetBird num único VPS é a alternativa que vale a pena considerar. Ambos transportam o tráfego através do WireGuard. Por isso, a escolha depende da forma como define as regras de acesso e do comportamento dos relays. Vale a pena comparar o NetBird com o Tailscale nesses aspetos antes de instalar qualquer um dos dois. Para uma comparação mais ampla dos dois modelos, consulte as diferenças entre WireGuard e Tailscale.

O que é necessário antes da instalação

• Uma VPS com Ubuntu 24.04, um endereço IPv4 público e acesso sudo. Se o servidor for novo, siga primeiro os primeiros dez minutos numa VPS nova.
• Um registo DNS A que aponte para esse endereço. Este guia usa headscale.example.com.
• Um segundo domínio ou subdomínio para o MagicDNS. Este guia usa tailnet.example.net. Não pode ser o mesmo domínio usado em server_url.
• Uma máquina cliente para aderir, com Linux, macOS, Windows, Android ou iOS. O Headscale 0.29.6 requer a versão 1.80.0 ou posterior do cliente Tailscale.

Instalar o headscale a partir do .deb oficial

O projeto publica pacotes .deb na página de releases do GitHub. Em 27 de outubro de 2026, a versão estável mais recente é a 0.29.6, lançada em 24 de outubro de 2026. Verifique primeiro sua arquitetura, porque o nome do arquivo inclui essa informação.

sudo apt update
sudo apt install -y wget
dpkg --print-architecture

Isso exibe amd64 em uma VPS x86 comum e arm64 em um plano no estilo Ampere ou Graviton. Coloque a resposta na variável abaixo.

HEADSCALE_VERSION="0.29.6"
HEADSCALE_ARCH="amd64"
wget --output-document=headscale.deb \\
  "https://github.com/juanfont/headscale/releases/download/v${HEADSCALE_VERSION}/headscale_${HEADSCALE_VERSION}_linux_${HEADSCALE_ARCH}.deb"
sudo apt install -y ./headscale.deb
headscale version

O ./ antes do nome do arquivo é obrigatório. Sem ele, apt procura um pacote chamado headscale.deb nos seus repositórios e falha.

O pacote cria um usuário de sistema headscale, grava um /etc/headscale/config.yaml padrão, instala uma unidade do systemd e inicia o serviço. Portanto, o headscale já está em execução quando apt retorna, e sudo systemctl is-active headscale exibe active. Em uma instalação nova, o pacote não habilita a unidade, porém. O serviço não voltará após uma reinicialização até que você o habilite, e a etapa de reinicialização abaixo faz isso. Ele também está em execução com a configuração fornecida pelo pacote, que aponta server_url para http://127.0.0.1:8080. Esse não é um endereço que nenhum dos seus clientes possa alcançar. Nada está exposto ainda, porque o listen_addr fornecido pelo pacote também está na interface de loopback. Ainda assim, não conecte nenhum cliente até definir server_url e reiniciar o serviço. As próximas duas etapas fazem isso.

Configure server_url antes de qualquer cliente aderir

Edite /etc/headscale/config.yaml com sudo nano /etc/headscale/config.yaml ou aplique as mesmas três alterações com sed. Guarde uma cópia do original, porque o ficheiro é longo e tem muitos comentários. É a melhor referência para o resto das definições.

sudo cp /etc/headscale/config.yaml /etc/headscale/config.yaml.orig
sudo sed -i 's|^server_url:.*|server_url: https://headscale.example.com|' /etc/headscale/config.yaml
sudo sed -i 's|^listen_addr:.*|listen_addr: 127.0.0.1:8080|' /etc/headscale/config.yaml
sudo sed -i 's|^  base_domain:.*|  base_domain: tailnet.example.net|' /etc/headscale/config.yaml
sudo grep -E '^(server_url|listen_addr):|^  base_domain:' /etc/headscale/config.yaml

server_url é o endereço público que o Headscale utiliza ao criar URLs de registo. Os clientes utilizam o endereço de controlo configurado com --login-server. Por isso, use o mesmo nome público com https:// nos dois locais, nunca 127.0.0.1. A documentação do Headscale indica que é possível usar HTTP simples ou HTTPS numa porta diferente de 443, mas recomenda vivamente HTTPS na porta 443 em produção. O resto deste guia assume essa configuração.

listen_addr é o endereço onde o processo fica à escuta. Mantenha-o na interface de loopback. Um reverse proxy no mesmo servidor termina o TLS (transport layer security) e encaminha os pedidos para esse endereço. Assim, nada fora do servidor precisa de aceder à porta 8080.

base_domain é o sufixo do MagicDNS, o domínio sob o qual os nós recebem nomes. Tem de ser um nome de domínio totalmente qualificado, sem ponto final. Também tem de ser diferente do domínio definido em server_url, porque, caso contrário, os dois espaços de nomes entram em conflito.

Não altere a secção da base de dados. A predefinição é SQLite em /var/lib/headscale/db.sqlite, num diretório criado e pertencente ao pacote. SQLite é suficiente para uma tailnet deste tamanho.

Reinicie o headscale e confirme que está em execução

sudo systemctl restart headscale
sudo systemctl enable headscale
sudo systemctl is-active headscale
sudo systemctl is-enabled headscale
curl -sS -o /dev/null -w '%{http_code}\\n' http://127.0.0.1:8080/health

is-active imprime active, is-enabled imprime enabled e curl imprime 200. O reinício é o passo que carrega as suas alterações. O headscale lê a configuração uma vez, quando inicia, por isso o processo iniciado pelo pacote continua a usar o server_url fornecido pelo pacote até ser reiniciado. sudo systemctl enable --now headscale não faz este trabalho: o serviço já está em execução, por isso o --now não altera nada e o valor antigo continua ativo. Iniciar no boot é a função de enable, e isso não é feito automaticamente: numa instalação nova, o pacote inicia o serviço sem o ativar, por isso execute sudo systemctl enable headscale uma vez, como acima.

Se is-active imprimir algo diferente de active, ou se curl não imprimir 200, consulte o journal com sudo journalctl -u headscale -n 50 --no-pager. Uma falha nesta fase é quase sempre causada pelo ficheiro de configuração, porque o headscale analisa o ficheiro inteiro antes de abrir um socket. Por isso, uma indentação incorreta ou uma definição obrigatória inválida interrompe o processo antes de qualquer serviço ficar à escuta. Corrija o ficheiro e depois execute sudo systemctl restart headscale. Todas as alterações posteriores à configuração precisam do mesmo reinício. Os clientes voltam a ligar-se automaticamente depois. Se as unidades systemd forem uma novidade para si, executar os seus próprios serviços e temporizadores com systemd explica os comandos usados aqui.

Verifique os ficheiros de estado enquanto estiver na shell:

stat -c '%U %n' /var/lib/headscale/db.sqlite /var/lib/headscale/noise_private.key

As duas linhas começam por headscale, o utilizador sem privilégios criado pelo pacote. noise_private.key é a identidade do servidor perante os clientes. Mantenha-o. Se o eliminar, o headscale gera uma nova identidade e os clientes têm de obter a nova chave do servidor antes de voltarem a ligar-se; os registos existentes permanecem na base de dados.

Coloque TLS na frente do headscale

Os clientes devem aceder a server_url por HTTPS. Caddy é o caminho mais curto, porque solicita e renova o certificado automaticamente.

sudo apt install -y caddy

Substitua /etc/caddy/Caddyfile pelo bloco da documentação do headscale:

headscale.example.com {
    reverse_proxy 127.0.0.1:8080 {
        header_up True-Client-IP {remote_host}
        header_up X-Real-IP {remote_host}
    }
}

sudo caddy validate --adapter caddyfile --config /etc/caddy/Caddyfile
sudo systemctl restart caddy
sudo systemctl is-active caddy

validate imprime adapted config to JSON quando o ficheiro é analisado. Um aviso a indicar que o ficheiro não está formatado é apenas cosmético. A partir do seu portátil, curl -sS -o /dev/null -w '%{http_code}\\n' https://headscale.example.com/health também deve imprimir 200. Essa verificação única confirma que o DNS, a firewall, o certificado e o proxy estão a funcionar em conjunto.

Este é o detalhe do proxy que pode consumir uma noite inteira. A ligação de controlo do Tailscale é uma atualização HTTP, é iniciada com POST em vez de GET, e o valor do cabeçalho Upgrade é tailscale-control-protocol. Caddy encaminha isso sem configuração adicional. nginx não o faz, por isso um frontend nginx tem de encaminhar explicitamente os cabeçalhos Upgrade e Connection. A documentação do headscale faz isso com um mapa de atualização:

map $http_upgrade $connection_upgrade {
    default keep-alive;
    ''      close;
}

server {
    listen 443 ssl;
    server_name headscale.example.com;
    location / {
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
        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_buffering off;
        proxy_pass http://127.0.0.1:8080;
    }
}

Se deixar essas linhas de fora, os pedidos normais continuam a funcionar. Por isso, /health devolve 200 e tudo parece correto, mas a ligação de controlo nunca é estabelecida: os nós novos não conseguem registar-se, e os nós existentes não conseguem voltar a ligar-se nem indicar que estão online. Se optar por nginx, Certbot no Ubuntu 24.04 com nginx explica a parte do certificado.

Quais portas abrir no UFW

sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

A porta 443 transporta a ligação de controlo de todos os clientes para o headscale. Se ativar posteriormente o relay DERP incorporado, também precisará de 3478/udp, abordada abaixo. A porta 80 é usada pelo desafio HTTP do ACME (ambiente de gestão automática de certificados) e pelo redirecionamento para HTTPS. O Caddy ainda pode obter um certificado com a porta 80 fechada, porque pode usar o desafio TLS-ALPN na porta 443. No entanto, com a porta 80 aberta, ambos os desafios ficam disponíveis e os pedidos http:// simples são redirecionados.

A porta 8080 permanece fechada. listen_addr é 127.0.0.1:8080, portanto o proxy chega ao headscale através da interface de loopback e não é necessária nenhuma regra de firewall. Abrir a porta 8080 no UFW não exporia nada, porque nenhum serviço escuta nela a partir do exterior, e também não oferece qualquer benefício. Tenha em atenção que a maioria dos fornecedores executa uma segunda firewall no respetivo painel de controlo, separada do UFW. Por isso, uma porta pode estar aberta no servidor e continuar fechada na periferia da rede. Noções básicas da firewall UFW num VPS explica a sintaxe das regras com mais detalhe.

Crie um utilizador e uma chave preauth

sudo headscale users create alice
sudo headscale users list

O comando headscale é um cliente. Comunica com o daemon em execução através do socket Unix em /var/run/headscale/headscale.sock, que tem o modo 0770 e pertence ao grupo headscale. Há duas consequências. O comando falha enquanto o serviço estiver parado, que é outro motivo para a ordem deste guia ser importante, e requer sudo, a menos que adicione a sua própria conta ao grupo headscale.

users list apresenta um ID junto a cada nome. Precisa desse número porque o comando de criação da chave aceita um ID numérico de utilizador, não um nome.

sudo headscale preauthkeys create --user 1 --expiration 24h

A chave é apresentada uma única vez. Copie-a agora. Uma chave preauth só pode ser usada uma vez e é válida durante uma hora, salvo indicação em contrário. Por isso, vale a pena definir --expiration 24h enquanto ainda está a testar. Adicione --reusable para criar uma chave que inscreva várias máquinas e trate-a como uma palavra-passe, porque qualquer pessoa que a tenha pode aderir à sua rede.

Ligue o primeiro cliente com --login-server

Na máquina que pretende adicionar:

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up --login-server https://headscale.example.com --auth-key 'hskey-auth-PASTE-YOUR-KEY-HERE'
tailscale status
tailscale ip -4

tailscale ip -4 mostra o endereço atribuído pelo headscale, semelhante a 100.64.0.1. No servidor, sudo headscale nodes list mostra o nó com o respetivo ID, utilizador e estado online.

Use o endereço HTTPS público de server_url em --login-server. O cliente remove as barras finais do URL de controlo. Não existe uma comparação exata de strings que exija omitir uma barra.

Uma máquina que tenha iniciado sessão anteriormente no serviço alojado do Tailscale mantém essa sessão. Execute primeiro sudo tailscale logout nessa máquina e, em seguida, execute tailscale up com --login-server.

Se omitir --auth-key, o cliente mostra um URL. Abra-o. A página mostra o identificador dessa tentativa de registo, que deve aprovar no servidor:

sudo headscale auth register --user alice --auth-id PASTE-THE-ID-FROM-THE-PAGE

Este formulário é mais prático no seu próprio portátil. As chaves de pré-autenticação são melhores para tarefas automatizadas, porque não é necessário que uma pessoa esteja a acompanhar o processo. Depois de o próprio VPS ser um nó, também pode encaminhar o tráfego de internet das outras máquinas, através de da configuração do nó de saída. A única diferença é que deve aprovar a rota anunciada no servidor com o comando headscale, em vez de a aprovar numa consola de administração alojada. Se pretende aceder a uma rede privada localizada atrás desse VPS, e não criar uma saída para a internet, o mesmo passo de aprovação abrange o anúncio dessa sub-rede para o resto do seu tailnet. Publicar uma aplicação a partir de um nó, em vez de encaminhar redes inteiras através dele, é outra tarefa. Serve e funnel são as duas formas de o fazer, embora ambos dependam do sistema próprio de certificados e ingresso do Tailscale. Considere-os funcionalidades de um tailnet alojado, e não algo que o headscale forneça diretamente.

DERP e os relays que encaminham o tráfego quando um caminho direto falha

DERP (designated encrypted relay for packets) é o caminho de fallback. Quando dois nós não conseguem estabelecer uma ligação WireGuard direta, normalmente porque ambos estão atrás de NAT (network address translation) restrito, enviam os pacotes através de um relay. O relay não possui chaves, por isso não consegue ler o seu tráfego. No entanto, consegue ver quais nós comunicam entre si e a quantidade de dados transferida.

É importante compreender o que a configuração predefinida faz. O Headscale é fornecido apontado para https://controlplane.tailscale.com/derpmap/default com auto_update_enabled: true e update_frequency: 3h, por isso o seu plano de controlo é seu, mas os relays pertencem à Tailscale. Para a maioria das pessoas, esta é uma troca aceitável. Se não for para si, execute o seu próprio relay.

Para executar o seu próprio relay, defina enabled: true em derp.server dentro de config.yaml, substitua ipv4: 198.51.100.1 e ipv6: 2001:db8::1 fornecidos pelos endereços públicos do seu relay ou remova ambas as definições para usar DNS. Depois, reinicie o Headscale e abra a porta STUN (session traversal utilities for NAT) com sudo ufw allow 3478/udp. Essas definições de endereço substituem o DNS. Por isso, deixar qualquer marcador de posição no ficheiro envia os clientes para um endereço inacessível. O ficheiro de configuração indica claramente este requisito: server_url deve usar https, porque o DERP requer TLS. Esvaziar a lista derp.urls remove os relays da Tailscale do mapa. Mantenha um relay incorporado ou personalizado funcional antes de fazer isso. O Headscale recusa iniciar com um mapa de relays vazio. Um mapa que contenha apenas um relay inacessível deixa os nós que não conseguem ligar-se diretamente sem capacidade de comunicação.

Num cliente, tailscale netcheck mostra a latência para cada região de relay conhecida, e tailscale status mostra direct com um endereço ou relay com um código de região para as ligações de pares ativas. Um par preso em relay precisa que o caminho direto seja verificado, incluindo as regras de NAT e da firewall. Um par que esteja direct e continue lento é outra questão, e a resposta habitual nesse caso é MTU, não o túnel em si.

Por que um node aparece como offline?

O proxy está a descartar o upgrade. O indicador é que /health devolve 200, enquanto os novos registos falham ou os nodes existentes não conseguem voltar a ligar-se. A ligação de controlo é um POST que transporta Upgrade: tailscale-control-protocol. Um proxy que não o encaminha bloqueia tanto o registo como o canal que comunica o estado do node. Compare a configuração do nginx com as linhas de upgrade acima ou mude para Caddy para excluir o proxy como causa.

O endereço público de controlo mudou. Os nodes continuam a ligar-se ao endereço configurado com --login-server. Alterar server_url não atualiza essa definição no cliente. Se o endereço antigo já não chegar ao seu servidor, execute sudo tailscale up --login-server https://headscale.example.com --force-reauth em cada node.

O cliente não está em execução. No node, execute sudo systemctl is-active tailscaled e sudo journalctl -u tailscaled -n 50 --no-pager. Um cliente que não consiga resolver ou alcançar o seu domínio regista aí as tentativas de ligação.

A chave expirou. Este caso é explicado na secção seguinte.

Para monitorizar o lado do servidor durante o teste, execute sudo journalctl -u headscale -f na VPS e reinicie tailscaled no cliente. Consulte também o journal do cliente: uma ligação que chega ao headscale não garante a criação de uma linha no nível de log predefinido. Por isso, o silêncio no log do servidor, por si só, não prova uma falha de DNS, firewall ou proxy.

Expiração das chaves e o nó que deixa de funcionar semanas depois

Existem duas expirações distintas. Confundi-las faz perder tempo.

As chaves de preautenticação expiram rapidamente por design. O valor predefinido é uma hora e uma utilização. Se tailscale up recusar a chave, gere uma nova no servidor em vez de editar algo no cliente.

As chaves dos nós são a parte de longa duração. A secção node de config.yaml define expiry: 0, e 0 significa que não existe expiração predefinida; uma expiração explícita do cliente ou uma expiração OIDC ainda pode aplicar-se. Os nós com tags estão isentos da expiração automática, embora um administrador possa expir
á-los explicitamente. Defina expiry: 180d se quiser uma predefinição de 180 dias para registos sem tags, mas uma expiração solicitada pelo cliente tem precedência e o OIDC pode substituir a predefinição. Alterar esta definição não altera retroativamente os registos existentes. Um nó com expiração precisa de se autenticar novamente antes desse prazo, usando sudo tailscale up --login-server https://headscale.example.com --force-reauth. Um servidor sem interface, no qual ninguém faça nova autenticação, será removido da rede quando o registo expirar.

Faça isto manualmente quando alguém perder um portátil. sudo headscale nodes list apresenta o ID, sudo headscale nodes expire -i 3 termina a sessão desse nó e sudo headscale nodes delete -i 3 remove-o completamente da rede.

Backups e upgrades

/var/lib/headscale e /etc/headscale juntos formam o servidor inteiro. Pare o serviço antes de os copiar, porque o SQLite pode ter escritas em curso e uma base de dados copiada sob carga pode ficar inconsistente.

sudo systemctl stop headscale
sudo tar czf /root/headscale-state.tgz -C /var/lib headscale
sudo tar czf /root/headscale-config.tgz -C /etc headscale
sudo systemctl start headscale
sudo chmod 600 /root/headscale-*.tgz

Transfira ambos os ficheiros para fora do servidor. Contêm as chaves privadas e todos os registos, pelo que exigem o mesmo cuidado que o próprio servidor. backups restic a partir de uma VPS explica como fazer isto de forma agendada e encriptada.

Os upgrades repetem a instalação: transfira o novo .deb e sudo apt install ./headscale.deb, reinicie e volte a executar as verificações is-active e /health. Desde a versão 0.29, o caminho de upgrade é estrito. Não é possível saltar uma versão minor, nem fazer downgrade para uma versão minor mais antiga. Avance uma versão minor de cada vez, faça um backup antes de cada passo e leia primeiro as notas de release dessa versão, porque essa mesma release alterou o comportamento das políticas de ACL e mudou várias chaves de configuração. A versão 0.29.6 também inclui atualizações de segurança na validação de certificados e nas dependências, pelo que as instalações existentes da versão 0.29 devem aplicar esta patch release.

FAQ

O headscale já está em execução logo depois de eu instalar o .deb?

Sim. O pacote inicia o serviço assim que é instalado, no /etc/headscale/config.yaml fornecido, que escuta apenas no loopback e define server_url como http://127.0.0.1:8080. Em uma instalação nova, ele não habilita o serviço, portanto não será iniciado no boot até você executar sudo systemctl enable headscale. O endereço fornecido não é útil para os clientes, então edite server_url, listen_addr e base_domain, depois execute sudo systemctl restart headscale e confirme com sudo systemctl is-active headscale. Ele precisa ser restart: o headscale lê o arquivo somente quando inicia, e executar enable --now em um serviço que já está em execução o habilita para o boot, mas não o reinicia, portanto os valores antigos continuam ativos. Se ele falhar depois do reinício, sudo journalctl -u headscale -n 50 --no-pager identifica o problema. Neste estágio, quase sempre é um erro de YAML, pois o headscale analisa o arquivo inteiro antes de associar uma porta.

Ainda preciso instalar o cliente Tailscale normal nas minhas máquinas?

Sim. O Headscale substitui apenas o servidor de controle. Cada nó executa o cliente oficial do Tailscale, e você aponta o cliente para o seu servidor com sudo tailscale up --login-server https://headscale.example.com. Essa flag existe no cliente padrão, portanto não é necessário aplicar patches nem recompilar nada.

Meu tráfego passa pelo servidor headscale?

Normalmente, não. O Headscale coordena a rede e distribui chaves e endereços, enquanto o caminho de dados usa WireGuard diretamente entre os seus nós. O tráfego só faz um desvio quando dois nós não conseguem alcançar um ao outro diretamente e usam um relay DERP como fallback. Com a configuração fornecida, esses relays são os públicos do Tailscale. Execute tailscale status em um nó para verificar se determinado peer está direct ou em um relay.

Por que meu nó continua offline depois de ser registrado?

Um nó que aparece em headscale nodes list, mas nunca fica online, precisa ter sua conexão de controle verificada, incluindo o reverse proxy. Essa conexão é uma atualização HTTP enviada como POST com o cabeçalho Upgrade: tailscale-control-protocol. O nginx a descarta, a menos que você encaminhe explicitamente os cabeçalhos Upgrade e Connection usando proxy_set_header, o que a configuração acima faz por meio do bloco map $http_upgrade $connection_upgrade. O descarte desses cabeçalhos também impede o registro de novos nós. O Caddy faz esse encaminhamento sem configuração adicional, o que o torna uma forma rápida de testar se o problema está no proxy.

Preciso de um nome de domínio e TLS para o headscale?

Para esta configuração, sim: use um nome de domínio e HTTPS. Os certificados também podem abranger endereços IP simples, mas o arquivo de configuração informa que o DERP exige TLS. Um domínio com Caddy leva cerca de cinco minutos para configurar e fornece um endpoint HTTPS que renova o certificado automaticamente. HTTP simples é possível, mas a documentação do headscale recomenda fortemente HTTPS na porta 443 em produção e observa que o cliente Tailscale pressupõe HTTPS na porta 443 em determinadas situações.