Tailscale Serve ou Funnel: qual usar?

tailscale serve versus funnel: quem pode aceder ao URL

A diferença entre tailscale serve e tailscale funnel é o público-alvo, e nada mais. serve coloca uma interface HTTPS (hypertext transfer protocol secure) numa porta local e publica-a apenas na sua tailnet. funnel publica essa mesma porta local em toda a Internet pública, através dos servidores de relay operados pela Tailscale. Os dois comandos aceitam as mesmas flags e os mesmos destinos. Uma palavra separa um dashboard privado de um dashboard acessível a qualquer pessoa na Internet.

Ambos fornecem um certificado que os browsers já consideram fidedigno, num nome terminado em ts.net, e nenhum deles precisa de uma porta de entrada aberta na firewall do seu VPS. O daemon tailscaled já mantém uma ligação de saída para a tailnet, por isso o tráfego chega através dessa ligação. Colocar um servidor na tailnet é uma tarefa, e executar um VPS como nó de saída Tailscale ou anunciar um router de sub-rede para uma rede privada trata dessa parte. Publicar um serviço que já está na tailnet é outra.

O que é necessário antes de qualquer comando funcionar

• Tailscale 1.38.3 ou mais recente no VPS, com sessão iniciada no seu tailnet. Verifique com tailscale version e tailscale status.
• MagicDNS ativado. O MagicDNS é o DNS integrado do Tailscale e atribui à máquina um nome como blog-vps.your-tailnet.ts.net, em vez de apenas um endereço 100.x.
• Certificados HTTPS ativados para o tailnet, na página DNS da consola de administração. Sem isso, não existe certificado para colocar à frente da sua porta.
• Apenas para funnel, o atributo de nó funnel no ficheiro de política do tailnet. É nesta etapa que a maioria das primeiras tentativas falha, conforme explicado abaixo.

Todos os comandos deste tutorial começam com sudo, porque a CLI comunica com tailscaled através de um socket que apenas root pode modificar. Conceda a um utilizador o direito de omitir esse prefixo:

sudo tailscale set --operator=$USER

Publique na sua tailnet com tailscale serve

Aponte serve para uma porta local e ele trata do resto.

sudo tailscale serve 3000

Available within your tailnet:
https://amelie-workstation.pango-lin.ts.net

 |-- / proxy http://127.0.0.1:3000

Press Ctrl+C to exit.

O comando simples 3000 é uma abreviatura de http://127.0.0.1:3000. O Tailscale escuta na porta 443 do endereço da máquina na tailnet, termina o TLS (transport layer security) com o certificado ts.net e encaminha HTTP simples para a sua porta local. A aplicação nunca precisa de saber que existe um certificado. Essa é a principal razão para usar este recurso à frente de um painel de administração que, de outra forma, ficaria exposto apenas em HTTP simples. Uma interface Web que escuta apenas em 127.0.0.1 é a candidata óbvia. A interface Web do dsh na porta 3080 é um bom exemplo: em vez de abrir um túnel SSH sempre que precisar de a utilizar, aponte serve para 3080 uma vez e aceda-lhe a partir de qualquer dispositivo na tailnet.

Agora leia a última linha: Press Ctrl+C to exit. O comando é executado em primeiro plano e o mapeamento fica dentro desse processo. Se fechar o terminal, o URL deixa de funcionar, porque nada foi gravado no disco. Adicione --bg para guardar o mapeamento na configuração serve do nó. Essa configuração sobrevive ao terminal e a um reboot.

sudo tailscale serve --bg 3000

O Serve aceita mais do que um número de porta. --set-path publica um serviço num subcaminho, para que várias aplicações possam partilhar o mesmo hostname:

sudo tailscale serve --bg --set-path=/grafana 3000
sudo tailscale serve --bg --set-path=/metrics 9090

O destino também pode ser um diretório com ficheiros estáticos ou um backend que já utilize TLS com um certificado que não queira validar:

sudo tailscale serve --bg /srv/reports
sudo tailscale serve --bg https+insecure://localhost:8443

Não está limitado a HTTP. --tcp=<port> encaminha um fluxo TCP (transmission control protocol) bruto, e --tls-terminated-tcp=<port> termina o TLS no seu nó e encaminha o conteúdo em texto simples. Assim, coloca um certificado confiável à frente de um serviço que não utiliza HTTP:

sudo tailscale serve --bg --tls-terminated-tcp=443 tcp://127.0.0.1:9899

Por que o funnel informa que o atributo do nó não está definido?

O Funnel fica desativado por padrão para todo o tailnet. A primeira execução exibe esta mensagem e é interrompida:

Funnel not available; "funnel" node attribute not set. See https://tailscale.com/kb/1223/tailscale-funnel/.

O comando está correto. A política do tailnet não concedeu a este nó permissão para publicar, por isso o cliente recusa a operação antes de contactar qualquer relay. Edite o ficheiro de política do tailnet na consola de administração, em Access Controls, e adicione o atributo:

"nodeAttrs": [
  {
    "target": ["autogroup:member"],
    "attr":   ["funnel"],
  },
],

autogroup:member concede essa permissão a todos os membros do tailnet. Se apenas uma máquina deve publicar, atribua uma tag a essa máquina e use a tag como destino, por exemplo tag:public. Guarde a política e execute novamente o comando do funnel.

Se a sua conta for administradora do tailnet, os clientes recentes oferecem um atalho: a CLI imprime um URL de consentimento em login.tailscale.com. Ao aceder a esse URL, o cliente ativa os certificados HTTPS e adiciona o atributo automaticamente. Se não for administrador, esse URL não será útil. Alguém com acesso à política terá de fazer a alteração.

Publicar na internet com o Tailscale Funnel

Depois de definir o atributo, o comando é aquele que já conhece, com um verbo diferente.

sudo tailscale funnel --bg 3000

Available on the internet:
https://amelie-workstation.pango-lin.ts.net

 |-- / proxy http://127.0.0.1:3000

Press Ctrl+C to exit.

Leia sempre essa primeira linha. Available within your tailnet e Available on the internet são a única diferença visível entre um serviço privado e um público, e os comandos que os produzem diferem por uma palavra.

Em agosto de 2026, o Funnel escuta na porta 443, 8443 ou 10000, e em nenhuma outra. O padrão é 443, e --https=8443 ou --https=10000 são as alternativas. Qualquer outra porta é recusada, porque os relays do Funnel aceitam ligações apenas nessas portas. Por isso, um URL do Funnel é sempre o nome do host simples ou o nome do host com :8443 acrescentado no fim.

Como vejo o que está publicado neste momento?

Adivinhar é a forma de manter um dashboard público durante um mês. Consulte o nó diretamente.

tailscale serve status
tailscale funnel status
tailscale serve status --json

Ambos os comandos de estado leem a mesma configuração, por isso qualquer um deles mostra o panorama completo. Use a forma --json num script ou numa verificação agendada, porque a saída normal foi feita para leitura humana. Quando não há nada configurado, é apresentada uma linha:

No serve config

Se vir isto depois de uma configuração que sabe que funcionou, o mapeamento foi criado em primeiro plano e o processo terminou. Crie-o novamente com --bg.

Para remover um mapeamento, repita o comando que o criou e acrescente off no fim. Para eliminar todos os mapeamentos de serve e funnel no nó, use reset.

sudo tailscale funnel --https=443 3000 off
sudo tailscale serve reset

Execute tailscale serve status novamente depois de qualquer uma das operações e veja o que permaneceu, em vez de assumir que o resultado foi o pretendido.

O que obtém e o que abdica

As vantagens são reais e explicam por que razão algumas pessoas escolhem esta opção em vez de um reverse proxy.

• Um certificado aceite pelos browsers, renovado automaticamente. Não é necessário instalar um cliente ACME (automatic certificate management environment), nem configurar uma tarefa de renovação que possa ser esquecida.
• Nenhuma porta de entrada na firewall do VPS. tailscaled estabelece ligações de saída, portanto uma firewall ufw com política de negar por omissão no seu VPS pode continuar exatamente tão restritiva como antes.
• Nenhum registo DNS para comprar, apontar ou aguardar.
• Nenhum encaminhamento de portas, que é a principal questão numa máquina atrás de NAT (network address translation), em vez de um VPS com um IP público.

Os custos são igualmente reais, e o funnel inclui todos eles.

• O nome não é seu. Os visitantes públicos veem host.your-tailnet.ts.net. O Funnel não suporta domínios personalizados, portanto não pode colocar app.example.com à frente dele.
• O caminho não é seu. O tráfego chega primeiro a um relay da Tailscale, que encaminha o stream para o seu nó através da tailnet. A Tailscale indica que o tráfego do funnel está sujeito a limites de largura de banda que não são publicados nem configuráveis. Por isso, meça o seu próprio throughput antes de depender de um valor.
• Faltam os controlos. Um reverse proxy que execute dá-lhe acesso a logs de acesso, limites de taxa, limites de tamanho dos pedidos e um local para configurar autenticação. O Funnel fornece-lhe um URL. Tudo o resto tem de existir dentro da sua aplicação.
• A lista de portas é fixa, conforme indicado acima.

Ambas as funcionalidades também dependem de infraestrutura operada pela Tailscale: a emissão do certificado para o nome ts.net e os próprios relays do funnel. A importância dessa dependência depende do que esses servidores podem ou não fazer com o seu tráfego, que é precisamente o que o modelo de confiança da Tailscale define. Nenhuma das duas funcionalidades tem custo de utilização, porque o plano gratuito inclui até seis utilizadores, cada um com dispositivos ilimitados, e é o número de utilizadores, não a lista de funcionalidades, que acaba por levar um tailnet para um plano pago. A partir desse ponto, a fatura é calculada com base nos utilizadores, não nas máquinas. Por isso, vale a pena verificar quanto custa efetivamente um tailnet num plano pago antes de o serve ou o funnel se tornarem componentes essenciais. Se estiver a considerar um servidor de controlo Headscale autoalojado, não presuma que nenhuma das duas funcionalidades será transferida consigo. Consulte as notas da versão do Headscale que pretende executar.

Qual devo usar?

A regra é simples.

Use serve para qualquer serviço interno: interfaces de administração, dashboards, uma interface de métricas que não quer indexada ou uma cópia de staging de um site. A participação na tailnet é o controlo de acesso, e é um bom controlo. Um dispositivo que não esteja na tailnet nem sequer consegue resolver o nome.

Use funnel para um link de demonstração, um recetor de webhook para o qual um terceiro tenha de fazer POST ou um callback OAuth durante o desenvolvimento. É a forma mais rápida de obter um URL HTTPS público, e um comando off termina a exposição. Público significa público: o hostname não é um segredo, e um funnel à frente de uma aplicação sem login é um serviço aberto. O que estiver atrás dele tem de autenticar os próprios pedidos, com o mesmo cuidado que um endpoint de API do Ollama exposto exige.

Use um reverse proxy real para qualquer serviço que considere de produção. O seu domínio, o seu certificado, os seus logs, os seus limites de pedidos e ninguém mais no caminho do pedido. Comparação entre nginx, Caddy e Traefik como reverse proxy explica como escolher um.

Modos de falha e as mensagens que verá

O Funnel recusa-se a iniciar. Funnel not available; "funnel" node attribute not set. é um problema de política, não um problema do comando. Adicione o atributo funnel ao ficheiro de política do tailnet, guarde-o e tente novamente.

Funcionou e agora tailscale serve status apresenta No serve config. O mapeamento foi criado em primeiro plano e esse processo terminou. Execute novamente o mesmo comando com --bg.

O nome é resolvido, mas nada responde. O Serve encaminha as ligações para o destino indicado. Se nada estiver a escutar nesse destino, não há nada para encaminhar. Confirme com ss -ltnp | grep 3000 na mesma máquina que executa tailscaled. A causa frequente é um contentor publicar a porta num endereço de bridge do Docker em vez de 127.0.0.1. Nesse caso, o host não encontra nenhum processo a escutar no local esperado. Como funciona a rede do Docker Compose mostra onde uma porta publicada fica efetivamente disponível.

Erros de certificado no nome ts.net. É provável que os certificados HTTPS não estejam ativados para o tailnet. Ative-os na consola de administração. Em seguida, execute a etapa do certificado isoladamente, para que os erros não se misturem com a saída do Serve:

sudo tailscale cert your-host.your-tailnet.ts.net

O Funnel carrega através dos dados móveis, mas comporta-se de forma diferente no portátil. O portátil está no tailnet. Por isso, o MagicDNS resolve o nome para o endereço 100.x e a ligação chega diretamente ao serviço, sem passar por um relay. Esse comportamento é correto. Também significa que o portátil não pode testar a acessibilidade pública. Use curl numa máquina que não esteja no tailnet.

FAQ

Qual é a diferença entre tailscale serve e tailscale funnel?

Quem pode aceder ao resultado. tailscale serve publica uma porta local num URL HTTPS que apenas os dispositivos da sua tailnet podem aceder. tailscale funnel publica a mesma porta num URL que qualquer pessoa na internet pode aceder, encaminhado através dos servidores de relay geridos pela Tailscale. As flags e os destinos são partilhados entre ambos. A primeira linha da saída indica qual dos dois foi obtido: Available within your tailnet ou Available on the internet.

Porque é que tailscale funnel indica que o atributo do nó não está definido?

Porque o funnel está desativado para uma tailnet até alguém o ativar. A mensagem é Funnel not available; "funnel" node attribute not set. e é gerada pelo seu próprio cliente, antes de qualquer relay ser contactado. Adicione uma entrada nodeAttrs que conceda o atributo funnel a autogroup:member, ou a uma tag se apenas uma máquina dever publicar, no ficheiro de política da tailnet, em Access Controls. Um administrador da tailnet pode, em alternativa, seguir o URL de consentimento apresentado pela CLI.

Que portas o Tailscale Funnel pode utilizar?

Apenas 443, 8443 e 10000. O valor predefinido é 443, e pode escolher outro com --https=8443 ou --https=10000. Este é um limite dos relays do funnel, não do seu servidor. Por isso, nenhuma alteração à firewall ou à configuração da VPS o elimina. tailscale serve não tem essa restrição, porque o tráfego nunca sai da sua tailnet.

Um URL de serve ou funnel mantém-se depois de um reboot?

Apenas se tiver utilizado --bg. Sem essa opção, o comando é executado em primeiro plano, apresenta Press Ctrl+C to exit. e o mapeamento desaparece juntamente com o processo. Com --bg, o mapeamento é escrito na configuração de serve do nó e regressa com tailscaled depois de um reboot. Verifique com tailscale serve status. O comando apresenta No serve config quando não existe nenhuma configuração.

É seguro deixar um funnel em execução?

É seguro do ponto de vista do transporte: a ligação utiliza HTTPS e nenhuma porta é aberta na firewall. Não é seguro no sentido habitual, porque o URL é público e, por isso, a aplicação por trás dele também é pública. Mantenha um funnel ativo apenas à frente de algo que autentique os próprios pedidos. Desative-o quando a demonstração ou o teste do webhook terminar, utilizando o comando que o criou com off no fim.

Fontes sobre o comportamento dos comandos acima: a documentação do Tailscale Serve e Funnel e a referência da CLI em tailscale.com/docs.