Tailscale Funnel ou Serve (2026): comandos, 3 portas, domínio próprio

Dois comandos da Tailscale diferem numa palavra. tailscale serve partilha um serviço local com os dispositivos da tua própria tailnet. tailscale funnel encaminha tráfego da internet em sentido lato para esse mesmo serviço, ao alcance de qualquer pessoa que tenha o URL.

Mesma sintaxe, exposição oposta. É o artigo inteiro em duas frases, mas trocar o sentido deixa na internet aberta um serviço que julgavas privado, por isso vale a pena ser preciso sobre o que o Funnel faz e não faz.

Em resumo (o detalhe, os comandos e a configuração com o teu domínio estão mais abaixo):

tailscale funnel 3000

https://<machine>.<tailnet-name>.ts.net

tailscale funnel status
tailscale funnel reset

Se precisas de um domínio teu, qualquer porta e nenhum limite de largura de banda do Funnel, a coluna da direita é a solução: um VPS pequeno com IPv4 público (Contabo, 5,50 € por mês) mais Caddy, configurado passo a passo mais abaixo.

O que o Funnel é, na realidade

A descrição da Tailscale é direta: o Funnel «permite encaminhar tráfego da internet em sentido lato para um serviço local em execução num dispositivo da tua rede Tailscale». O objetivo é partilhar com pessoas que não estão na tua tailnet e não têm conta Tailscale.

O Serve é o caso inverso, e a documentação di-lo sem rodeios: se queres partilhar serviços locais apenas com os outros dispositivos da tailnet, usa o Serve.

A decisão não é, portanto, uma preferência técnica, é uma pergunta sobre o teu público:

• Apenas as tuas máquinas e as pessoas convidadas para a tailnet → Serve.
• Qualquer pessoa com a ligação, incluindo desconhecidos → Funnel.

Se não souberes responder a essa pergunta para um dado serviço, não corras ainda nenhum dos dois comandos.

As três restrições que decidem se o Funnel serve

O Funnel é deliberadamente estreito, e os seus limites estão documentados em vez de serem descobertos pelo caminho. Três deles resolvem a maioria dos casos antes de escreveres uma linha de configuração.

As portas: 443, 8443, 10000. É a lista completa. O Funnel só pode escutar nessas três. Não é um valor por omissão a sobrepor, se o teu serviço tiver de estar acessível publicamente noutra porta, o Funnel não é a ferramenta.

O nome de anfitrião pertence à Tailscale. O Funnel só pode usar nomes DNS do domínio da tua tailnet, na forma tailnet-name.ts.net. Se pensavas colocar um produto, uma demonstração para clientes ou algo com a tua marca num domínio teu, não é isso que ele faz.

A largura de banda tem teto, e o teto não é teu. A Tailscale afirma que o tráfego enviado através do Funnel está sujeito a limites não configuráveis. Para uma página de configuração ou uma ferramenta interna pequena, é irrelevante. Para transmitir uma mediateca a familiares, esse teto será provavelmente o constrangimento, antes da tua velocidade de envio.

A parte que se salta: não há qualquer início de sessão à frente

É a razão pela qual a confusão entre Serve e Funnel pesa mais do que uma gralha vulgar.

A documentação da Tailscale não descreve qualquer camada de autenticação à frente de um ponto de entrada Funnel, e é intencional, porque toda a sua finalidade é servir pessoas que não estão na tailnet e que, por isso, não podem ser autenticadas por ela. O Funnel dá-te uma entrada HTTPS pública; não te dá uma porta.

Consequência prática: a autenticação da tua aplicação é a única coisa entre a internet e os teus dados. Um painel sem palavra-passe, um explorador de ficheiros que confia na rede local, um painel de administração que só era acessível a partir da LAN, todos ficam abertos no momento em que são «funnelados» em vez de servidos.

Antes de ativar isto sobre o que quer que seja, o teste honesto cabe numa pergunta: publicaria este URL abertamente sem desconforto? Se a resposta for não, o serviço precisa da sua própria autenticação, ou precisa do Serve em vez do Funnel.

Ativá-lo: primeiro o ficheiro de políticas

O Funnel não está ativo por omissão num nó. Exige um atributo de nó funnel no ficheiro de políticas da tua tailnet, que indica à Tailscale que utilizadores o podem usar. Por omissão, esse direito vai para autogroup:member.

Essa mediação merece ser compreendida em vez de ignorada: significa que o Funnel é uma decisão administrativa ao nível da tailnet, não apenas um comando que alguém corre no portátil. Numa tailnet partilhada, quem controla o ficheiro de políticas controla a própria possibilidade de expor serviços publicamente.

Os comandos, lado a lado

Os dois comandos aceitam o mesmo alvo: uma porta, um endereço localhost:porta ou o URL completo de um serviço a correr na máquina. Estas são as formas listadas por tailscale funnel --help no Tailscale 1.104.1 (18 de outubro de 2026). Nada muda na 1.104.2, versão estável de 21 de outubro de 2026: o seu changelog lista apenas a compilação com Go 1.27.3, que retira a confiança aos certificados intermediários TLS da eMudhra comprometidos (boletim de segurança Tailscale TS-2026-013), e duas correções do cliente Windows. Atualize o cliente, os comandos abaixo continuam iguais:

# Só dentro da tailnet: https://<maquina>.<nome-tailnet>.ts.net
tailscale serve --bg 3000

# Na internet pública, mesmo URL, ao alcance de qualquer pessoa
tailscale funnel --bg 3000

# Público, numa das outras duas portas permitidas
tailscale funnel --bg --https=8443 3000

# Ver o que está exposto e depois retirar tudo
tailscale funnel status
tailscale funnel reset

Sem --bg, a partilha corre em primeiro plano e termina quando fechas o terminal, a opção mais prudente para um teste rápido. Com --bg sobrevive a fins de sessão e reinícios até correres reset, por isso habitua-te a lançar tailscale funnel status em qualquer máquina onde o tenhas usado. Antes da primeira execução, o MagicDNS e os certificados HTTPS da tailnet têm de estar ativos na consola de administração, porque o Funnel serve um certificado real para o nome ts.net.

Tailscale Funnel com o teu próprio domínio: o proxy inverso num VPS

O Funnel não responde em app.exemplo.pt, e um CNAME para o teu nome ts.net não resolve: o certificado é emitido para o nome ts.net, por isso o navegador rejeita o domínio personalizado. A montagem que te dá um domínio teu, qualquer porta, nenhum limite de largura de banda do Funnel e um início de sessão que controlas é um pequeno servidor público que entra na tua tailnet e reencaminha o tráfego para a máquina de casa através dela.

1. Aluga um VPS pequeno com IPv4 pública e instala o Tailscale (curl -fsSL https://tailscale.com/install.sh | sh e depois sudo tailscale up). Passa a alcançar a tua máquina de casa no endereço tailnet 100.x.y.z.
2. Aponta um registo A de app.exemplo.pt para o IP público do VPS e abre as portas 80 e 443 na firewall dele, mais nenhuma.
3. Instala o Caddy no VPS com este Caddyfile (validado com caddy validate no Caddy 2.11.7):

app.exemplo.pt {
	basic_auth {
		# gera o hash com: caddy hash-password
		alice $2a$14$Zkx19XLiW6VYouLHR5NmfOFU0z2GTNmpkT/5qqR7hx4IjWJPDhjvG
	}
	reverse_proxy 100.101.102.103:3000
}

O Caddy obtém sozinho o certificado Let's Encrypt do teu domínio, e o bloco basic_auth põe à frente do serviço a barreira que o Funnel nunca teve. Substitui 100.101.102.103 pelo IP tailnet que tailscale ip -4 mostra na máquina de casa e confirma que o serviço escuta nessa interface, não apenas em 127.0.0.1. A rede de casa continua sem abrir nenhuma porta: o VPS é a única face pública e o tráfego entre os dois viaja dentro do WireGuard.

O custo honesto: alguns euros por mês e mais uma máquina para manter atualizada. Um VPS de 1 vCPU e 1 GB chega bem para um proxy inverso; o limite passa a ser a velocidade da porta do VPS, não um teto definido por outra pessoa. Se preferires não manter nenhum servidor público, a alternativa é um produto de túnel pensado para domínios próprios, comparado mais abaixo.

Se preferir um fornecedor dos EUA com 30 dias de reembolso, o VPS Basic da Ultahost custa 5,52 $ por mês em 24 meses (1 GB de RAM, IPv4 dedicado, lido a 21 de outubro de 2026), suficiente para o proxy reverso Caddy descrito acima.

Quando o Funnel é a resposta certa e quando não é

O Funnel encaixa quando queres dar a alguém de fora da tua tailnet um URL HTTPS que funcione com o mínimo de cerimónia: um ponto de entrada de webhook que um serviço terceiro tem de alcançar, uma pré-visualização do que estás a construir, uma partilha temporária. Os certificados e a entrada pública são tratados por ti, e funciona em todos os planos.

O Funnel não encaixa quando precisas de um domínio teu, de uma porta fora das três permitidas, de débito sustentado ou de uma camada de autenticação que controles. Esses requisitos apontam para outro lado: um proxy inverso numa máquina com IP público próprio, ou um produto de túnel construído em torno de domínios personalizados.

E para o caso em que as pessoas mais frequentemente pensam ao recorrer ao Funnel, quero que os meus dispositivos alcancem este serviço a partir de qualquer lugar, nem o Funnel nem um túnel público são a resposta. É o que a tailnet já faz, e o que um nó de saída ou um servidor WireGuard auto-hospedado fazem sem expor seja o que for publicamente.

Para ter os comandos à mão: a nossa Tailscale & Headscale Cheat Sheet gratuita (PDF de 4 páginas em inglês, download direto, sem registo) reúne status e ping, exit node, subnet router, Serve e Funnel, a configuração do Headscale, utilizadores, chaves e ACL, e as causas de falha habituais. Descarregar a ficha.

O essencial

serve e funnel estão a uma palavra de distância no terminal e são opostos naquilo que publicam. O Serve mantém um serviço dentro da tailnet; o Funnel põe-no na internet, numa de três portas, sob um nome ts.net, com teto de largura de banda e sem nada que autentique os visitantes.

Decide antes de escrever qual é o público que realmente pretendes. Se a resposta for «as minhas máquinas», nunca precisaste de uma entrada pública, e a exposição mais segura continua a ser a que nunca se abriu.