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 (protocolo seguro de transferencia de hipertexto) delante de un puerto local y lo publica sólo para tu tailnet. funnel publica ese mismo puerto local en toda Internet pública mediante los servidores de relay que ejecuta 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, con un nombre que termina en ts.net, y ninguno necesita que abras un puerto entrante en el firewall de tu VPS. Tu daemon de tailscaled ya mantiene una conexión saliente con la tailnet, así que el tráfico llega por ella. Incorporar un servidor a la tailnet es una tarea, y ejecutar un VPS como nodo de salida de Tailscale o anunciar un router de subred para una red privada cubren ese caso. Publicar un servicio que ya está en la tailnet es esta otra tarea.

Qué necesitas antes de que funcione cualquiera de los dos comandos

• Tailscale 1.38.3 o una versión posterior en el VPS, con sesión iniciada en tu tailnet. Compruébalo con tailscale version y tailscale status.
• MagicDNS habilitado. MagicDNS es el DNS (sistema de nombres de dominio) integrado de Tailscale. Es lo que asigna 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 opción, no hay ningún certificado que puedas colocar delante de tu puerto.
• Sólo para funnel, el atributo de nodo funnel en el archivo de políticas de la tailnet. Este es el punto en el que se detienen la mayoría de los primeros intentos. Se explica más adelante.

Todos los comandos de esta guía empiezan por sudo porque la CLI se comunica con tailscaled mediante un socket en el que sólo root puede escribir. Concede a un usuario el permiso para omitirlo:

sudo tailscale set --operator=$USER

Publica en tu tailnet con tailscale serve

Apunta serve a un puerto local y tailscale hace el 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 básico 3000 es una abreviatura 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. Tu aplicación no tiene que saber que existe un certificado. Esta es la razón principal para usarlo delante de un panel de administración que, de otro modo, dejarías en HTTP sin cifrar. Una interfaz web que sólo se enlaza a 127.0.0.1 es un candidato evidente. La interfaz web de dsh en el puerto 3080 es un buen ejemplo: en lugar de abrir un túnel SSH cada vez que quieras acceder, apunta serve a 3080 una vez y accede desde cualquier dispositivo de la tailnet.

Ahora lee 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 cierras el terminal, la URL deja de funcionar porque no se ha escrito nada en el disco. Añade --bg y la asignación se guarda en la configuración de serve del nodo. Así sobrevive tanto al cierre del terminal como a un reinicio.

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 quieras 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 procesar, y --tls-terminated-tcp=<port> termina TLS en tu nodo y reenvía el contenido sin cifrar. Esto coloca 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á establecido?

Funnel está desactivado de forma predeterminada para todo el tailnet. 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 permiso a este nodo 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 use esa etiqueta como destino, por ejemplo tag:public. Guarde la política y vuelva a ejecutar el comando de Funnel.

Si su cuenta es de administrador del tailnet, las versiones recientes del cliente ofrecen un acceso directo: la CLI muestra 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 mismo 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 producen 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; --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 seguido de :8443.

¿Cómo puedo ver qué está publicado ahora?

Hacer suposiciones es la forma de mantener un dashboard público 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 información completa. Use la forma --json dentro de un script o una comprobación programada, porque la salida normal está pensada para las personas. Si no hay nada configurado, verá una línea:

No serve config

Si aparece después de una configuración que sabe que funcionaba, significa que el mapping se creó en primer plano y que el proceso ya terminó. Créelo de nuevo con --bg.

Para eliminar un mapping, repita el comando que lo creó y añada off al final. Para eliminar todos los mappings 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 las dos operaciones y revise lo que queda. No dé por hecho que la operación hizo lo que pretendía.

Qué obtiene y a qué renuncia

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 de ACME (automatic certificate management environment) ni recordar una tarea de renovación.
• Ningún puerto de entrada 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 mantener exactamente el mismo nivel de restricción.
• No es necesario comprar, configurar ni esperar un registro DNS.
• No hay redirección de puertos. Esto es fundamental 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 implica 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 hace proxy del flujo hasta el 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 ni se pueden configurar. Por tanto, mida su propio rendimiento antes de depender de una cifra.
• Faltan controles. Un reverse proxy administrado por usted proporciona registros de acceso, límites de tasa, límites de tamaño de las solicitudes y un lugar donde configurar la autenticación. Funnel le proporciona una URL. Todo lo demás debe implementarse dentro de la aplicación.
• La lista de puertos es fija, como se indicó anteriormente.

Ambas funciones también dependen de la infraestructura que opera Tailscale: la emisión del certificado para el nombre ts.net y los propios relés de funnel. Que esta dependencia le preocupe o no depende de lo que esos servidores puedan hacer con su tráfico y de lo que no puedan hacer. Eso es precisamente lo que establece el modelo de confianza de Tailscale. Ninguna de las dos funciones tiene coste, porque el plan gratuito cubre hasta seis usuarios con dispositivos ilimitados para cada uno, y es el número de usuarios, no la lista de funciones, lo que acaba trasladando un tailnet a un plan de pago. A partir de ese punto, la factura depende de los usuarios y no de las máquinas. Por eso conviene comprobar cuánto cuesta realmente un tailnet con un plan de pago antes de que serve o funnel se conviertan en componentes necesarios. Si está evaluando un servidor de control Headscale autohospedado, no dé por hecho que ninguna de las dos funciones estará disponible con él. Consulte las notas de la versión de la versión de Headscale que vaya a 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 actúa como control de acceso y es eficaz. 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 un callback de 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 hostname no es un secreto, y un funnel delante de una aplicación sin inicio de sesión es un servicio abierto. Todo 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. Comparativa de nginx, Caddy y Traefik como reverse proxy explica cómo elegir uno.

Modos de fallo y los 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 ese proceso terminó. Vuelva a ejecutar el mismo comando con --bg.

El nombre se resuelve, pero no responde nada. Serve actúa como proxy hacia el destino indicado. Si no hay ningún proceso escuchando allí, no hay nada hacia lo que reenviar. 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 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 carga con datos móviles, pero se comporta de otra forma desde el portátil. El portátil está en la tailnet, por lo que MagicDNS resuelve el nombre a la dirección 100.x y accede directamente al servicio, sin usar un relay. Ese comportamiento es correcto. También significa que el portátil no puede probar la accesibilidad pública. Use curl desde un equipo que no esté en 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 cualquiera desde Internet, mediante servidores de relay operados por Tailscale. Los flags y los destinos son comunes a ambos. La primera línea de salida indica cuál has obtenido: 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 ningún relay. Añade una entrada nodeAttrs que conceda el atributo funnel a autogroup:member, o a un tag si sólo una máquina debe publicar, en el archivo de políticas de la tailnet, dentro de 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 relays de funnel, no de tu servidor, por lo que ningún cambio en el firewall o en la configuración del VPS lo elimina. 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 el mapeo desaparece junto con el proceso. Con --bg, el mapeo 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; muestra No serve config cuando no hay nada configurado.

¿Es seguro dejar un funnel en ejecución?

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 es pública. 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 y la referencia de la CLI de Tailscale Serve y Funnel en tailscale.com/docs.