Tailscale Serve o Funnel: cuál usar y cuándo

tailscale serve frente a funnel: quién puede acceder a la URL

La diferencia entre tailscale serve y tailscale funnel es la audiencia, y nada más. serve coloca un frontend HTTPS (hypertext transfer protocol secure) delante de un puerto local y lo publica sólo en tu tailnet. funnel publica ese mismo puerto local en todo Internet público mediante los servidores de retransmisión que gestiona Tailscale. Ambos comandos aceptan los mismos flags y los mismos destinos. Una palabra separa un dashboard privado de uno accesible desde todo Internet.

Ambos te proporcionan un certificado que los navegadores ya consideran de confianza, en un nombre que termina en ts.net, y ninguno necesita que haya un puerto entrante abierto en el firewall de tu VPS. Tu daemon tailscaled ya mantiene una conexión saliente con la tailnet, por lo que el tráfico llega a través de ella. Incorporar un servidor a la tailnet es una tarea, y usar un VPS como nodo de salida de Tailscale o anunciar un router de subred para una red privada cubre esa parte. Publicar un servicio que ya está en la tailnet es esta otra.

Lo que necesita antes de que funcione cualquiera de los dos comandos

• Tailscale 1.38.3 o posterior en el VPS, con la sesión iniciada en su tailnet. Compruébelo con tailscale version y tailscale status.
• MagicDNS habilitado. MagicDNS es el DNS integrado de Tailscale y proporciona a la máquina un nombre como blog-vps.your-tailnet.ts.net, en lugar de sólo una dirección 100.x.
• Certificados HTTPS habilitados para la tailnet, en la página DNS de la consola de administración. Sin esta configuración, no hay ningún certificado que pueda colocarse delante de su puerto.
• Sólo para funnel, el atributo de nodo funnel en el archivo de políticas de la tailnet. Aquí es donde se detienen la mayoría de los primeros intentos. Se explica más abajo.

Todos los comandos de esta sección comienzan con sudo porque la CLI se comunica con tailscaled mediante un socket en el que sólo root puede escribir. Conceda a un usuario el permiso para omitirlo:

sudo tailscale set --operator=$USER

Publicar en la tailnet con tailscale serve

Apunte serve a un puerto local y tailscale serve se encargará del 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.

El comando 3000 sin argumentos es una forma abreviada de http://127.0.0.1:3000. Tailscale escucha en el puerto 443 de la dirección de la máquina en la tailnet, termina TLS (seguridad de la capa de transporte) con el certificado ts.net y reenvía HTTP sin cifrar al puerto local. Su aplicación no necesita saber que existe un certificado. Esta es la razón principal para usarlo delante de un panel de administración que, de otro modo, tendría que dejar expuesto mediante HTTP sin cifrar.

Ahora revise la última línea: Press Ctrl+C to exit. El comando se ejecuta en primer plano y la asignación existe dentro de ese proceso. Si cierra el terminal, la URL deja de funcionar porque no se escribió nada en el disco. Añada --bg para guardar la asignación en la configuración de serve del nodo. Así seguirá activa después de cerrar el terminal y de reiniciar el sistema.

sudo tailscale serve --bg 3000

Serve admite más que un número de puerto. --set-path monta un servicio bajo una subruta, de modo que varias aplicaciones pueden compartir un nombre de host:

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

El destino también puede ser un directorio de archivos estáticos o un backend que ya use TLS con un certificado cuya validación no quiera realizar:

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

Tampoco está limitado a HTTP. --tcp=<port> reenvía un flujo TCP (protocolo de control de transmisión) sin modificar, y --tls-terminated-tcp=<port> termina TLS en el nodo y reenvía el contenido sin cifrar. Esto permite colocar un certificado de confianza delante de un servicio que no usa HTTP:

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

¿Por qué Funnel indica que el atributo del nodo no está configurado?

Funnel está desactivado para todo el tailnet de forma predeterminada. La primera ejecución muestra este mensaje y se detiene:

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

El comando era correcto. La política del tailnet no ha concedido a este nodo permiso para publicar, por lo que el cliente rechaza la operación antes de contactar con un relay. Edite el archivo de política del tailnet en la consola de administración, en Access Controls, y añada el atributo:

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

autogroup:member lo concede a todos los miembros del tailnet. Si sólo una máquina debe publicar, asígnele una etiqueta y dirija el permiso a esa etiqueta, por ejemplo tag:public. Guarde la política y vuelva a ejecutar el comando de Funnel.

Si su cuenta es administradora del tailnet, las versiones recientes del cliente ofrecen un acceso directo: la CLI imprime una URL de consentimiento en login.tailscale.com. Al abrirla, se habilitan los certificados HTTPS y se añade el atributo automáticamente. Si no es administrador, esa URL no le servirá. Alguien con acceso a la política debe realizar la modificación.

Publicar en Internet con tailscale funnel

Una vez establecido el atributo, el comando es el que ya conoce, pero con un 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.

Lea siempre esa primera línea. Available within your tailnet y Available on the internet son la única diferencia visible entre un servicio privado y uno público, y los comandos que los generan sólo se diferencian en una palabra.

En agosto de 2026, funnel escucha en los puertos 443, 8443 o 10000, y en ningún otro. El valor predeterminado es 443, y --https=8443 o --https=10000 son las alternativas. Cualquier otro puerto se rechaza, porque los relays de funnel sólo aceptan conexiones en esos puertos. Por eso, una URL de funnel siempre es el nombre de host sin modificaciones o el nombre de host con :8443 añadido al final.

¿Cómo puedo ver lo que está publicado ahora?

Adivinar es la forma de dejar un panel expuesto durante un mes. Consulte el nodo directamente.

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

Ambos comandos de estado leen la misma configuración, por lo que cualquiera de ellos muestra la situación completa. Use la forma --json dentro de un script o una comprobación programada, porque la salida normal está pensada para las personas. Cuando no hay nada configurado, aparece una sola línea:

No serve config

Si aparece después de una configuración que sabe que funcionaba, significa que la asignación se creó en primer plano y que el proceso ya terminó. Vuelva a crearla con --bg.

Para eliminar una asignación, repita el comando que la creó y añada off al final. Para eliminar todas las asignaciones de serve y funnel del nodo, use reset.

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

Vuelva a ejecutar tailscale serve status después de cualquiera de esas acciones y compruebe lo que queda, en lugar de asumir que hizo lo que quería.

Qué se obtiene y qué se sacrifica

Las ventajas son reales y explican por qué algunas personas eligen esta opción en lugar de un reverse proxy.

• Un certificado de confianza para los navegadores, renovado automáticamente. No es necesario instalar un cliente ACME (automatic certificate management environment) ni recordar una tarea de renovación.
• Ningún puerto entrante en el firewall del VPS. tailscaled establece la conexión saliente, por lo que un firewall ufw con denegación predeterminada en el VPS puede seguir siendo igual de restrictivo.
• No es necesario comprar, configurar ni esperar un registro DNS.
• No hay reenvío de puertos. Esto es lo importante en una máquina detrás de NAT (network address translation), en lugar de un VPS con una IP pública.

Los costes son igual de reales, y funnel los concentra todos.

• El nombre no es suyo. Los visitantes públicos ven host.your-tailnet.ts.net. Funnel no admite dominios personalizados, por lo que no puede colocar app.example.com delante.
• La ruta no es suya. El tráfico llega primero a un relay de Tailscale, que luego hace proxy del flujo hacia su nodo a través de la tailnet. Tailscale indica que el tráfico de funnel está sujeto a límites de ancho de banda que no se publican y no se pueden configurar. Mida su propio rendimiento antes de depender de una cifra.
• Faltan controles. Un reverse proxy que usted administra proporciona registros de acceso, límites de tasa, límites de tamaño de las solicitudes y un lugar donde implementar la autenticación. Funnel proporciona una URL. Todo lo demás debe residir dentro de su aplicación.
• La lista de puertos es fija, como se indicó antes.

Ambas funciones también dependen de la infraestructura que opera Tailscale: la emisión de certificados para el nombre ts.net y los propios relays de funnel. Si está evaluando un servidor de control Headscale autohospedado, no dé por hecho que ninguna de las dos funciones se trasladará con usted. Consulte las notas de la versión de la versión de Headscale que planea ejecutar.

¿Cuál debería usar?

La regla es sencilla.

Use serve para cualquier servicio interno: interfaces de administración, paneles, una interfaz de métricas que no quiera indexar o una copia de staging de un sitio. La pertenencia al tailnet controla el acceso, y es un buen control. Un dispositivo que no está en el tailnet ni siquiera puede resolver el nombre.

Use funnel para un enlace de demostración, un receptor de webhook al que un tercero deba enviar solicitudes POST o una devolución de llamada OAuth durante el desarrollo. Es la forma más rápida de obtener una URL HTTPS pública, y un comando off la desactiva. Pero público significa público: el nombre de host no es un secreto, y un funnel delante de una aplicación sin inicio de sesión es un servicio abierto. Lo que haya detrás debe autenticar sus propias solicitudes, con el mismo cuidado que necesita un endpoint de API de Ollama expuesto.

Use un reverse proxy real para cualquier servicio que considere de producción. Su dominio, su certificado, sus registros, sus límites de tasa y ningún tercero en la ruta de la solicitud. Comparación de nginx, Caddy y Traefik como reverse proxy explica cómo elegir uno.

Modos de fallo y mensajes que verá

Funnel no se inicia. Funnel not available; "funnel" node attribute not set. es un problema de política, no de comandos. Añada el atributo funnel al archivo de política de tailnet, guárdelo y vuelva a intentarlo.

Funcionaba y ahora tailscale serve status muestra No serve config. La asignación se creó en primer plano y el proceso terminó. Vuelva a ejecutar el mismo comando con --bg.

El nombre se resuelve, pero no responde nada. Serve redirige al destino que indicó. Si no hay ningún proceso escuchando allí, no hay nada que redirigir. Confírmelo con ss -ltnp | grep 3000 en el mismo equipo que ejecuta tailscaled. La causa habitual es que un contenedor publique su puerto en una dirección de puente de Docker en lugar de 127.0.0.1. Por eso, el host no encuentra ningún proceso escuchando donde esperaba. Cómo funciona la red de Docker Compose muestra dónde termina realmente un puerto publicado.

Errores de certificado en el nombre ts.net. Lo más probable es que los certificados HTTPS no estén habilitados para la tailnet. Actívelos en la consola de administración y ejecute después el paso de obtención del certificado por separado. Así, sus errores no se mezclan con la salida de Serve:

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

Funnel se carga con datos móviles, pero se comporta de forma distinta desde el portátil. El portátil está conectado a la tailnet, por lo que MagicDNS resuelve el nombre a la dirección 100.x y accede directamente al servicio, sin pasar por un relay. Este comportamiento es correcto, pero significa que el portátil no puede probar la accesibilidad pública. Use curl desde un equipo que no esté conectado a la tailnet.

FAQ

¿Cuál es la diferencia entre tailscale serve y tailscale funnel?

Quién puede acceder al resultado. tailscale serve publica un puerto local en una URL HTTPS a la que sólo pueden acceder los dispositivos de tu tailnet. tailscale funnel publica el mismo puerto en una URL a la que puede acceder cualquier persona en Internet, mediante servidores de retransmisión operados por Tailscale. Los indicadores y los destinos son los mismos en ambos casos. La primera línea de salida indica cuál de los dos se ha aplicado: Available within your tailnet o Available on the internet.

¿Por qué tailscale funnel indica que el atributo del nodo no está establecido?

Porque funnel está deshabilitado para una tailnet hasta que alguien lo habilita. El mensaje es Funnel not available; "funnel" node attribute not set. y procede de tu propio cliente, antes de contactar con cualquier retransmisor. Añade una entrada nodeAttrs que conceda el atributo funnel a autogroup:member, o a una etiqueta si sólo debe publicar una máquina, en el archivo de políticas de la tailnet, en Access Controls. Un administrador de la tailnet también puede seguir la URL de consentimiento que muestra la CLI.

¿Qué puertos puede usar Tailscale Funnel?

Sólo 443, 8443 y 10000. El valor predeterminado es 443, y puedes elegir otro con --https=8443 o --https=10000. Es un límite de los retransmisores de funnel, no de tu servidor, por lo que ningún cambio en el firewall o en la configuración de la VPS puede eliminarlo. tailscale serve no tiene esta restricción porque nunca sale de tu tailnet.

¿Una URL de serve o funnel sobrevive a un reinicio?

Sólo si usaste --bg. Sin esta opción, el comando se ejecuta en primer plano, muestra Press Ctrl+C to exit. y la asignación desaparece junto con el proceso. Con --bg, la asignación se escribe en la configuración de serve del nodo y vuelve a estar disponible con tailscaled después de un reinicio. Compruébalo con tailscale serve status, que muestra No serve config cuando no hay nada configurado.

¿Es seguro dejar un funnel activo?

Es seguro desde el punto de vista del transporte: la conexión usa HTTPS y no hay ningún puerto abierto en el firewall. No es seguro en el sentido habitual, porque la URL es pública y, por tanto, la aplicación que hay detrás también lo es. Deja un funnel activo sólo delante de algo que autentique sus propias solicitudes y desactívalo cuando termine la demostración o la prueba del webhook, usando el comando que lo creó y añadiendo off al final.

Fuentes sobre el comportamiento de los comandos anterior: la documentación de Tailscale Serve y Funnel y la referencia de la CLI en tailscale.com/docs.