SSD Nodes Learn 🎉 VPS desde $5.50/mês
Guias Matt ConnorPor Matt Connor

Tailscale Serve ou Funnel: qual usar?

Serve mantém o HTTPS restrito à tailnet; Funnel expõe a porta à Internet. Veja a política que bloqueia Funnel e escolha o comando correto.

tailscale serve vs funnel: quem pode aceder ao URL

A diferença entre tailscale serve e tailscale funnel é o público, e nada mais. serve coloca uma interface HTTPS (hypertext transfer protocol secure) à frente de uma 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 em todo o mundo.

Ambos fornecem um certificado que os browsers já consideram fidedigno, num nome terminado em ts.net, e nenhum deles requer 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, pelo que o tráfego chega através dela. 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 é o objetivo desta tarefa.

O que é necessário para qualquer um dos dois comandos funcionar

  • Tailscale 1.38.3 ou posterior no VPS, com sessão iniciada na sua tailnet. Verifique com tailscale version e tailscale status.
  • MagicDNS ativado. O MagicDNS é o DNS (sistema de nomes de domínio) integrado do Tailscale. É ele que 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 a tailnet, na página DNS do console 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 da tailnet. É neste ponto que a maioria das primeiras tentativas falha. Isto é 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 escrever. 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 3000 simples é 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 sua aplicação nunca precisa de saber que existe um certificado. Essa é a principal razão para usar esta opção à frente de um painel de administração que, de outro modo, ficaria exposto apenas em HTTP.

Agora leia a última linha: Press Ctrl+C to exit. O comando é executado em primeiro plano e o mapeamento existe dentro desse processo. Feche o terminal e o URL deixa de funcionar, porque nada foi gravado no disco. Adicione --bg e o mapeamento será guardado 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 monta um serviço num subcaminho, para que várias aplicações possam partilhar um 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á utiliza TLS com um certificado que não pretende validar:

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

A utilização não se limita 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, pode colocar 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 está desativado por padrão em toda a tailnet. A primeira execução apresenta esta mensagem e é interrompida:

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

O comando estava correto. A política da 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 da 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 da 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 da tailnet, os clientes recentes oferecem um atalho: a CLI apresenta um URL de consentimento em login.tailscale.com. Ao seguir esse URL, ativa os certificados HTTPS e adiciona o atributo automaticamente. Se não for administrador, esse URL não será suficiente. 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 é o que já conhece, mas 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 numa palavra.

Em agosto de 2026, o Funnel escuta na porta 443, 8443 ou 10000, e em nenhuma outra. A predefiniçã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 que um URL do Funnel é sempre o hostname sem alterações ou o hostname com :8443 acrescentado no fim.

Como vejo o que está publicado neste momento?

Adivinhar é a forma de deixar um dashboard público durante um mês. Consulte o node.

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

Ambos os comandos de estado leem a mesma configuração, por isso qualquer um mostra a situação completa. Use a forma --json dentro de um script ou de uma verificação agendada, porque o output simples foi feito para pessoas. Quando não há nada configurado, é apresentada uma linha:

No serve config

Ver esta saída depois de uma configuração que funcionava significa que o mapping foi criado em primeiro plano e o processo terminou. Recrie-o com --bg.

Para remover um mapping, repita o comando que o criou e acrescente off no final. Para remover todos os mappings de serve e funnel no node, 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 leia o que ficou, em vez de presumir que o resultado foi o pretendido.

O que você obtém e do que abre mão

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

  • Um certificado reconhecido pelos navegadores, renovado automaticamente. Não é necessário instalar um cliente ACME (automatic certificate management environment) nem configurar um job de renovação que possa ser esquecido.
  • Nenhuma porta de entrada no firewall do VPS. tailscaled inicia a ligação de saída, por isso um firewall ufw com política padrão de negar no VPS pode continuar exatamente tão restritivo como antes.
  • Nenhum registo DNS para comprar, apontar ou aguardar.
  • Nenhum encaminhamento de portas. Este é o ponto principal 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 implica todos eles.

  • O nome não é seu. Os visitantes públicos veem host.your-tailnet.ts.net. O funnel não oferece suporte a domínios personalizados, portanto não é possível colocar app.example.com à frente dele.
  • O caminho não é seu. O tráfego chega primeiro a um relay da Tailscale, e o relay encaminha o fluxo para o seu nó através da tailnet. A Tailscale informa 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.
  • Os controlos não estão disponíveis. Um reverse proxy que você administra fornece logs de acesso, limites de taxa, limites para o tamanho dos pedidos e um local para configurar a autenticação. O funnel fornece uma URL. Todo o resto tem de ficar dentro da sua aplicação.
  • A lista de portas é fixa, conforme indicado acima.

Ambas as funcionalidades também dependem da infraestrutura operada pela Tailscale: a emissão de certificados para o nome ts.net e os próprios relays do funnel. Se estiver a ponderar um servidor de controlo Headscale autoalojado, não assuma que nenhuma delas estará disponível nesse ambiente. Consulte as notas da versão da versão do Headscale que pretende executar.

Qual devo usar?

A regra é simples.

Use serve para tudo o que for interno: interfaces de administração, dashboards, uma interface de métricas que não queira indexada e uma cópia de staging de um site. A pertença ao tailnet é o controlo de acesso, e é um bom controlo. Um dispositivo que não esteja no tailnet nem sequer consegue resolver o nome.

Use funnel para um link de demonstração, um recetor de webhook ao 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 por trás dele tem de autenticar os seus próprios pedidos, com o mesmo cuidado que exige um endpoint de API do Ollama exposto.

Use um reverse proxy real para tudo o que consideraria 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 da tailnet, guarde-o e tente novamente.

Funcionou, mas agora tailscale serve status indica 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 não há resposta. O Serve faz proxy para o destino indicado. Se não houver nada 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 serviço a escutar no local esperado. Como funciona a rede do Docker Compose mostra onde uma porta publicada é efetivamente disponibilizada.

Erros de certificado no nome ts.net. É provável que os certificados HTTPS não estejam ativados para a tailnet. Ative-os na consola de administração. Em seguida, execute isoladamente o passo de criação do certificado, 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 de dados móveis, mas comporta-se de forma diferente no portátil. O portátil está na tailnet. Por isso, o MagicDNS resolve o nome para o endereço 100.x e acede diretamente ao serviço, sem passar por um relay. Esse comportamento é correto e significa que o portátil não pode testar a acessibilidade pública. Use curl numa máquina que não esteja na tailnet.

FAQ

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

Quem pode alcançar o resultado. tailscale serve publica uma porta local num URL HTTPS que apenas os dispositivos da sua tailnet podem alcançar. tailscale funnel publica a mesma porta num URL que qualquer pessoa na internet pode alcançar, encaminhado através dos servidores relay operados pela Tailscale. As flags e os destinos são partilhados entre ambos. A primeira linha da saída informa qual deles 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 fica 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. A predefinição é 443, e pode escolher outra 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 esta restrição, porque nunca sai da sua tailnet.

Um URL de serve ou funnel sobrevive a 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. Quando nada está definido, este comando apresenta No serve config.

É seguro deixar um funnel em execução?

É seguro do ponto de vista do transporte: a ligação utiliza HTTPS e nenhuma porta fica aberta na firewall. Não é seguro no sentido normalmente atribuído à expressão, 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 seus 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 do comportamento dos comandos acima: a documentação e a referência da CLI do Tailscale Serve e Funnel em tailscale.com/docs.